Insights

AI can write the code. It can't be accountable for it.

Coding agents changed the economics of writing software faster than most teams changed how they work. The result is predictable: more code, sooner, with the same number of people responsible for whether it's right. Some teams ship better than they ever have. Others are accumulating a new kind of technical debt — code nobody on the team fully read — and won't find out for a year.

The difference is not which model they use. It is whether they kept the discipline the model can't supply.

The model is fast and confidently wrong

An agent will write a function, its tests, and a commit message in the time it takes to describe them. It will also invent an API that doesn't exist, satisfy the test it wrote instead of the behaviour you meant, and quietly widen the scope of a change because the prompt was loose. None of that is a reason not to use it. It is the reason the process around it matters more than it did before, not less.

A useful way to think about it: the agent is the most productive junior engineer you have ever worked with, and it will never become senior on its own. Everything a good team does to make junior work safe — clear briefs, review, tests, a person who signs off — is exactly what makes agent work safe.

What holds

The spec comes first, and it lives in the repo. The single biggest lever is the quality of the brief. "Add export to CSV" produces a guess; a written spec with the states, the edge cases, and what "done" means produces the feature. Writing that spec is the hard skill most teams skip, and agents make skipping it expensive. Keep it versioned next to the code, so the intent and the implementation are reviewed together.

Every line gets read. Not skimmed for style — read for what it does. Review catches the invented API, the test that tests nothing, the change that touched a file it had no reason to touch. If the volume of generated code makes full review impossible, the answer is smaller changes, not lighter review.

Tests are the contract, so a person writes what they assert. Agents are excellent at scaffolding tests and terrible at deciding what correctness means. Let the agent generate the cases; a person decides what the feature must and must not do, and rejects tests that merely mirror the implementation.

Gates verify before anything ships. Type checks, linters, the test suite, security scanning, and a check that the change stays inside its declared scope — run automatically, on every change, in CI, before a human spends attention. A gate that only runs on the developer's machine is a suggestion.

Observability from the first release. If an agent-written change misbehaves in production, you need to see it that day, not in the quarterly retro. Logging, error tracking, and a trace from any output back to the change that caused it.

Licence and provenance checks. Generated code can reproduce licensed snippets. Scan for it the way you scan for vulnerabilities, and treat it as the same class of problem.

A name on every release. The agent doesn't decide. An engineer does — and is accountable for what went out, the way they always were. This is the rule that makes the others hold: when a person has to stand behind the release, the spec gets written, the review gets done, and the test gets read.

What this looks like in practice

Intent becomes a spec in git. An agent builds from it, in a branch, with the tests it scaffolds and the ones a person wrote. The gates run. A senior engineer reviews the change against the spec, not just the diff. The release goes out with that engineer's name on it, in the open, where the client can see every commit. For work where client code and data can't leave a controlled environment, the agents run against our own inference platform, built in-house, instead of a third-party API. Over time, the classes of change the agent gets right stop needing line-by-line review — and the ones that still surprise you keep it. Autonomy is earned per kind of change, never granted wholesale.

None of this is new. It is what good engineering teams already did, applied to a collaborator that types faster than any of them. The teams getting the most from AI aren't the ones who trusted it most. They are the ones who never stopped checking.

AI can write the code. It can't be accountable for it. by Martin Prunell is licensed under CC BY SA. Source code examples are licensed under MIT. Categorized under Engineering / AI & Agents.

Related reading