--- title: What changes when your development team is an AI canonical: https://getcyril.com/blog/when-your-development-team-is-an-ai/ published: 2026-08-28 author: Sam Akbari language: en --- # What changes when your development team is an AI Almost everything written about AI development is about the first hour: the demo, the scaffold, the feature that appeared in ten minutes. Very little is about month nine, when the codebase is large, several changes are in flight at once, and the interesting failures are no longer syntax errors. This is a note from month nine. ## Written-down decisions became the actual constraint A human engineering team carries a large amount of shared context that is never written anywhere. Everyone knows the tenancy rule, the reason the old approach was abandoned, which module is a minefield. An AI team has none of that between sessions. So every decision that matters has to exist as a durable, retrievable document or it does not exist at all. In practice that means a strict layering. Each feature has a functional spec (what it does for the user), a technical design (schema, endpoints, architecture) and an epic file (stories and their status). Architectural decisions that cut across features get their own numbered records — why the platform is vertical-aware rather than templated, why the AI operating modes are shaped the way they are, why the marketing site is a static export. A bootstrap file at the repo root routes work types to their required reading, so a task touching authentication automatically pulls in the threat model. The point that surprised me: this is not overhead paid for the AI's benefit. It is the documentation discipline that every engineering team claims to want and few sustain, made non-optional because the alternative is immediately visible. When the docs drift, the next session builds the wrong thing that day — not in six months when a new hire joins. ## Recorded state is not evidence The failure mode I did not anticipate, and the one that has cost the most time, is trusting a status that turned out to be a description of intent. A closed issue means someone decided it was done. A green build means the jobs that ran, passed. Neither is proof that the thing works. Over one particularly educational day, five defects were found in features whose issues were closed and whose pipelines were green. In each case the record was accurate about what happened and silent about what did not. The specific traps recur and generalise well beyond AI development: - **A test suite that matches zero tests reports success.** So does a filter with a typo in the path. Green over an empty set looks identical to green over a passing set unless you check the count. - **A pipeline with path filters skips the suites your change did not touch.** A run reporting "success" across sixteen jobs can prove nothing about the change in front of you. - **A build can pass on a machine whose dependencies are stale**, then fail for everyone else. The correction is a rule rather than more vigilance: **verify against the artefact, not the record.** Read the code, count the assertions that ran, load the page. This is now the first instinct rather than the last resort, and it is the single practice I would transplant into any team, AI or otherwise. ## Parallelism needs isolation, not etiquette Several AI sessions run against this repository at once. They share one git directory, which means branch references, stashes and remote state are common to all of them — worktrees isolate files, never references. Without hard isolation, three things happen, and all three did: two sessions build the same thing independently, one session pushes onto another's branch, and one session tidies up work in progress that belonged to someone else. The rules that fixed it are unglamorous. Every session works in its own worktree created from the shared main branch. One branch has exactly one owner; you never push to a branch you did not create. You never touch shared state you did not create — someone else's stash is not yours to clean. And cleanup runs at the *start* of a session rather than the end, because a session cannot remove the worktree it is currently running inside; the instruction to tidy up afterwards was quietly impossible for a year, which is why nobody had ever done it. If that sounds like a description of a distributed system rather than a team, that is the point. Coordination between agents is an engineering problem with engineering solutions, not a communication problem with cultural ones. ## Tests changed job With human developers, tests catch regressions. With AI developers, tests are how intent is *transmitted*. A specification says what should happen; a test asserts it in a form that cannot be misread, cannot drift, and fails loudly when a later change contradicts it. That shifts what is worth testing. The highest-value tests here are not the ones covering the most lines — they are the ones encoding a rule that must never be violated, where the failure would be silent: that no query can escape its tenant scope, that a permission cannot be widened by a code path, that an audit record exists for every mutation. Those are load-bearing. A test asserting that a helper formats a date is not. ## The connection to the product Here is where it stops being a process story. Everything above is a description of what a system needs in order for an AI to work on it safely: an unambiguous data model, decisions recorded in machine-readable form, state that can be verified rather than assumed, permissions that hold without relying on good behaviour, an audit trail that says who did what, and a way to undo a mistake. That is also, precisely, the list of what a *business platform* needs in order for an AI to operate it safely on a customer's behalf. Which means building Cyril this way has not been a novelty or a cost-saving. It has been the most demanding possible test of the product's central claim. Every time the development process needed a new guarantee to stay safe, the same guarantee turned out to be missing from the platform. One audit log rather than several. One permission model that the automated actor inherits rather than bypasses. A rollback path that exists because the schema supports it, not because someone remembered to add an undo button. I did not plan that symmetry. I would now argue it is not a coincidence: agent-operable software and agent-buildable software are the same category of thing, and if you are building the first, building it the second way is the cheapest honest test you will find. ## What I would tell someone starting - **Write the decision down the moment you make it**, in the place the next session will look. An undocumented decision will be re-litigated, and probably reversed. - **Never trust a status field.** Confirm against the artefact. Assume every green light is answering a narrower question than the one you asked. - **Isolate parallel work at the tool level.** Rules that rely on politeness between agents fail at the first collision. - **Spend your test budget on the invariants that fail silently**, not on coverage percentage. - **Review the diff, not the summary.** The summary is written by the same system that wrote the code, and it is describing what it intended. Cyril is pre-launch. Its Agentic mode — where you hand a goal over entirely — is coming soon rather than shipped; what exists today is the platform and an AI assistant that plans, shows its plan, and acts where you can watch. That distinction matters more to me than it might to a marketing department, because the whole argument above is that the gap between what a system claims and what it can prove is where the trouble lives. ## Common questions ### Does an AI actually write all the code? Implementation, tests and documentation are AI-written. Product direction, prioritisation, approval and review are human. The division that works is that the AI owns *how* and a person owns *what* and *whether*. ### Is this faster than a human team? Substantially, at the point of writing code — and that turns out to be the least interesting variable. The rate limit is review and verification capacity, which is human, so the practices that make verification fast matter more than raw output. ### What breaks most often? Trusting recorded state. Not bad code — wrong confidence about whether existing code works, from a status field that was accurate about intent and silent about outcome. ### Would you recommend this to another team? The practices, unreservedly, whether or not you use AI: durable written decisions, verification against artefacts, hard isolation of parallel work, tests as the encoding of intent. The staffing model is a separate question and depends on how much reviewing capacity you have, because that is the real constraint. --- If you want to be among the first to use Cyril, [join the waitlist](/waitlist/).