The interesting question about AI in software is not whether it can write code. It has been able to for a while. The question is what you have to put around it before the output is safe to run in front of paying customers.
Here is the arrangement we settled on, and the reasoning for each part.
It starts written
Before any code, a change is a specification: what it does, what it must not break, and how we will know it worked.
This is not process for its own sake. An agent given a vague instruction produces something plausible and wrong, and plausible-and-wrong costs more to unpick than nothing at all. Writing the spec is also where most of the disagreement happens, which is the cheapest place for disagreement to happen.
Agents implement, in isolation
The bulk of the work is done by agents, in branches nobody else is using. They do not touch anything shared. They do not touch production. If the result is wrong, the cost is a discarded branch.
That isolation is the whole reason this is safe to do at volume. The failure mode of an agent is not that it refuses; it is that it confidently does the wrong thing, and the containment has to assume that.
The reviewer is never the author
Output is reviewed by models from different vendors, plus an automated review gate.
The reason is not that more opinions are better. It is that a model cannot see its own blind spots any more reliably than a person can. Asking the thing that wrote the code whether the code is good gets you the answer it already believed. Different training, different failure modes, and the disagreements are where the bugs are.
An engineer signs it
A person reads the diff, fixes what needs fixing, and puts their name on the commit.
This is the line that matters most and it is the one most often skipped. Not because a human catches everything, but because somebody has to be answerable. A pipeline where nobody chose to ship is a pipeline where nobody is responsible when it breaks, and that is not a technical problem, it is an organisational one.
What this actually buys
Speed usually costs quality. This is the arrangement we found that does not, and the mechanism is unglamorous: the volume comes from agents, the judgement stays human, and the gate is a person who has to answer for what passes.
It is how we hold six of our own products and more than twenty client platforms to the same standard with a team that could not do it by hand.
What it does not buy
It does not remove the need to know what you are building. An agent will implement the wrong feature beautifully. It does not remove the need for people who can read a diff and tell whether it is right, and those people are not cheaper or easier to find than before.
And it does not remove the reviewing. That is the corner people cut first, because it is the part where nothing visible happens, and it is the corner that decides whether any of the rest was worth doing.
Why we describe our own method
Because it is the same method we install when a client asks us to automate their operations. We are not selling a way of working that we do not use.