Engineering
Delivering Software with AI Agents
Most teams have bolted a coding agent onto a process designed for humans typing, and then wondered why the delivery numbers barely moved. The agent writes faster. Everything downstream of it, review, test, release and the arguments about what was wanted in the first place, runs at the same speed it always did. The constraint has moved and the process hasn't.
This piece is about what delivery looks like when you move the process too. It's written from doing it, not from a vendor deck. Some of it will read as obvious. Most of it is not yet common practice.
What actually changed
Writing code has become cheap. Knowing that the code is right has not. That one sentence is the whole restructuring argument, and everything below follows from it.
For thirty years the scarce thing in software was production: getting from an idea to working code took skilled people and time, so the process was built to protect their output. Review was a check on effort already spent. Testing was budgeted against the cost of writing. Specifications were loose because tightening them cost more than the ambiguity did.
An agent inverts that. It will produce a plausible implementation of almost anything in minutes, and it will produce it with the same confidence whether it understood the problem or not. The expensive activity is now deciding what to build precisely enough that the agent can't misread it, and then establishing that what came back does what was asked and nothing else. Verification is the job. Writing is the bit in the middle.
Two consequences. First, cheap code is also disposable code: if an implementation is wrong, it is often faster to throw it away and regenerate from a corrected brief than to patch it, which human-written code rarely is. Second, the volume of change goes up by a multiple, so any control that depends on a person reading every line stops working at exactly the moment you need it most.
How the work is structured
The model that works is a loop, not a pipeline: brief, generate, verify, and either accept or re-brief. The skill sits at the two ends. The middle is what you are paying the agent for.
Brief. Every unit of work starts as a written brief the agent reads, not a ticket title it infers from. The brief states the behaviour wanted, the behaviour that must not change, the interfaces it touches, and how success will be checked. If you can't write the acceptance check, you are not ready to generate. This is where most of the senior time now goes, and it is where the quality of the outcome is decided. A vague brief does not produce vague code. It produces confident code for a problem you didn't have.
Context, not prompts. The agent needs the same things a new contractor would need on day one: how the repository is laid out, the conventions, the commands that build and test, what is off limits. Write that down once, in the repository, and keep it current. Teams that rely on re-explaining this in every session get drift, because every session starts from a slightly different understanding.
Small units, fast loops. The agent's error rate compounds with the size of the task. A change you can verify in twenty minutes is worth four changes that each take a day to untangle. Decompose until each unit has one testable claim, generate, verify, merge. Large features are many small loops, not one long one.
Tests first, written by the agent, read by you. The most reliable way to pin down intent is to have the agent write the tests from the brief before it writes the implementation. The tests are short, legible, and the point at which you catch a misreading cheaply. Review the tests harder than the code. If the tests encode what you meant, the implementation either passes them or it doesn't.
Verify, then decide. Verification is three things, in order: the automated checks the brief named, a read of the diff for anything the brief did not ask for, and a judgement about whether the result is acceptable or the brief was wrong. The third one is the one teams skip. When the output is wrong, the question is not "how do I fix this" but "what did my brief fail to say". Fix the brief, regenerate, and you have fixed every future instance of that misreading, not just this one.
Keep the agent out of the merge. The agent proposes; a person accepts. That is not ceremony, it is the control that makes everything above safe to run at speed. The next section is about why.
The controls that let you go fast
Speed without controls is how an agent ships a credential, deletes a table, or quietly adds a dependency nobody vetted. The controls are the same four boundaries we put round agents in production, applied to the delivery pipeline. None of them slows the loop. They are what make the loop safe to run unattended.
Output is a proposal. The agent opens a pull request. It does not merge, deploy, or touch anything with a blast radius. Acceptance is a human decision recorded in the normal place.
Scoped, expiring credentials. The agent runs as its own identity, not yours, with access to this repository and this environment and nothing else. No standing cloud keys on the workstation it can read. If it needs a secret, it gets a short-lived one for the task.
Deterministic gates it cannot argue with. Linting, the test suite, dependency and secret scanning, licence checks, a build in a clean environment. These run in CI on every proposal, they are not prompts, and the agent cannot talk its way past them. This is where the volume problem is solved: the gates scale, reviewers don't.
A named human on the loop. Someone owns the brief, accepts or rejects the output, and can stop the agent. Not in the loop reading every line, which doesn't scale, but on it, accountable for what merged.
Two specifics worth stating because they bite. Pin dependencies and treat any new one the agent introduces as a review item in its own right; agents add packages freely and sometimes invent names. And run the agent in a container or sandbox with the repository mounted, not in your shell with your home directory. The contractor analogy holds: give it a desk and a badge, not your laptop.
What this does to the team
The team gets smaller and more senior, and the roles change shape.
The work that disappears is the typing: boilerplate, scaffolding, the third CRUD endpoint, the migration nobody wanted to write. The work that grows is specification, architecture, and judgement about whether an output is acceptable. Those were always the senior skills. The difference is that they are now most of the job rather than the part done between the typing.
This has an uncomfortable implication for the junior pipeline. The traditional apprenticeship, learning by writing a lot of ordinary code under supervision, is exactly the work the agent has absorbed. Teams need to be deliberate about how people learn to verify if they are no longer learning by producing. Reviewing agent output against a brief is decent training, but only if someone senior is reviewing the review.
A practical shape for a product team: one person who owns the briefs and the acceptance decisions, one or two engineers running loops in parallel, and the platform work of keeping the context, gates and sandbox current treated as a first-class responsibility rather than a side task. That last role is new and it is the one most teams under-resource. The agent is only as good as the repository it is working in, and someone has to keep the repository good.
What to measure
Pick metrics from the worries, not from the vendor dashboard. Lines generated and suggestion acceptance rate tell you the agent is busy. The questions that matter are what could go wrong when you deliver this way, what you would see early if it did, and how often you need to look.
Three cadences. Alarms should read zero and page someone when they don't. The weekly board is what the team runs on. Quarterly reviews catch the slow drifts that a weekly number hides.
| Worry | Signals | Cadence |
|---|---|---|
| Agent builds the wrong thing, confidently. Outputs rejected at verification; rework after merge | Verification rejection rate; re-brief ratio (fixed by changing the brief vs patching the code); defects traced to specification rather than implementation | Weekly |
| Verification skipped as volume outruns reviewers. Reviewer minutes per change collapse while throughput rises; failures drift up | Review depth per change; change failure rate; lead time from brief to merge (read together, never alone) | Weekly |
| Scope creep inside a change. Files, behaviour or interfaces touched that the brief never named | Scope leakage count at review; diff size against brief size | Weekly |
| Supply chain. Packages added freely, some that don't exist | New dependencies per change; proportion rejected; any package not present before the task started | Alarm, plus weekly count |
| Secrets and reach. Agent sees or uses credentials beyond the task | Secret-scan findings in proposals; scope exception requests; actions outside the sandbox | Alarm |
| Context rot. Quality degrades slowly with nothing visibly changed | Rejection rate trending back up after falling; commits since the context file was last updated | Quarterly |
| Nobody understands the code. Incidents fixed by regeneration rather than diagnosis | Time to restore; share of incidents with a found root cause vs a rewritten component | Quarterly, and after every incident |
| Cost exceeds value. Token spend plus senior time per change creeping up | Cost per merged change (tokens and reviewer time); senior time split between briefs and acceptance vs writing code | Monthly |
| Skills erosion. Nobody below senior rejects an output for a substantive reason | Substantive rejections by level; review quality sampled by someone senior | Quarterly |
Some worries carry two signals because one alone misleads: lead time without change failure rate rewards skipping review, and throughput without review depth hides it. The count of metrics falls out of the worries. If a worry has no signal, you are not measuring it, whatever the dashboard says.
Where to start
Don't start with a tool rollout. Start with one team, one repository, and the four things above: a written context file, briefs with acceptance checks, deterministic gates in CI, and the agent running as its own scoped identity with no path to merge. Run it for a month, watch lead time and failure rate, and fix the briefs before you fix anything else.
The teams that get this right are not the ones with the best model. They are the ones that worked out, early, that the job had become verification and reorganised around it.