The common worry about agent-written code is that it will be bad. In practice that is the least of it. Agents write code that compiles, passes the tests, and reads cleanly.
The failure is quieter. It is that the person who shipped it cannot explain why it is right.
When an agent writes the implementation and the tests in the same pass, passing tests prove one thing: the happy path the agent thought of is covered by the assertions the agent thought of. That is a closed loop. It tells you nothing about whether the behaviour is correct, because nobody outside the loop ever defined what correct means.
This is the difference between two sentences that sound similar and are not:
"The agent built the integration, tests pass, I sent it over." Nobody has said what right means here.
"I built the integration. Here is why it is right: it matches the error-handling section of the spec, I tested the failure case by hand, and I can walk you through every branch." That is a defensible delivery.
The code might be identical in both cases. The engagement is not.
Handing execution to an agent is correct. That is the entire point of building this way, and a team that refuses to is just slower.
The failure is handing over your understanding along with the execution. An engineer who lets an agent think for them produces code they cannot explain, defend or adjust, because they never understood what the work needed in the first place.
You find out when something breaks at 2am, or when a client asks why a decision was made, or when the requirement shifts by ten percent and nobody knows which parts are safe to move.
Two human gates, and no more than two. More than that and you have rebuilt the bottleneck you were trying to remove.
Gate one: approve the plan. Before anything is built, a human reads what the agent intends to do and agrees that it is the right approach. Catching a wrong approach here costs a minute. Catching it after the build costs a day.
Gate two: review the code. Not skim it. Review it well enough that you could walk someone else through every branch of it. If you cannot, it is not reviewed, it is glanced at.
Everything between those two gates is the agent's job. Everything at those two gates is not delegable, and a team that delegates them anyway is going to find out why in about a quarter.
The check that prevents most of this is unglamorous. Before the work starts, write down what a senior engineer would accept as a finished delivery for this specific piece of work, in terms the client would recognise. Not "it runs". Something closer to "the retry path handles a rate limit without losing the job, and I have watched it do that".
Then run a pass against that definition before anything reaches a human who is paying for it. A delivery with no evidence it meets the bar is a fail, not a maybe.
That is the whole discipline. It is not sophisticated and it does not need a tool. It needs someone to have decided what right means before the agent started guessing.
The teams getting real value out of agents are not the ones with the best prompts. They are the ones who kept judgment in human hands and gave everything else away.
That is how our bench is expected to work, and it is most of what we screen for. If you want the longer version of how the loop runs day to day, it is written up here.
Anyone can run the tool. That was never the differentiator.
Maxpertise is an AI-native engineering company. We embed native AI engineers inside your team, live in about 10 days. Please enable JavaScript to view the site, or email contact@maxpertise.net.