I cannot read the code my agents write.
I do not work in software. I cannot read the code that comes out of these models, I cannot debug it, and when something is explained to me in detail it may as well be in Russian. I did not set out to build a delivery pipeline. I set out to avoid learning to code, which I still have not done.
What I ran into is that agents will tell you they did the work. They will tell you the tests passed. They will tell you the change was reviewed. Almost none of that is checkable by default, and I had no ability to check any of it by reading.
The problem I actually had
The problem I actually had was not "how do I get an agent to write code". It was "how do I trust output I am structurally incapable of evaluating".
What I did instead
The answer I stumbled into was to stop trying to evaluate the output, and make the models evaluate each other. Give them separate roles, from different vendors, with no ability to grade their own work, and put a check at the end that involves no model at all.
Then make every claim they produce something a machine can verify rather than something I have to believe.
That is what this site is about. Not because I am qualified to tell anyone how to do it, but because I appear to be the only one writing about it from the position of the person who cannot check.
Who this is for
Almost everything written about AI agents writing code is written by engineers for engineers. The fastest growing group of people using these tools cannot read the output either. They have no vocabulary for what they are worried about and no framework for what to ask for.
I am one of them. This is the thing I wish had existed.
What it took
- Millions of tokens spent.
- Dozens of hours of my own time. Several hundred hours of compute, because one hour on the clock has been running three to four hours of parallel model time, sometimes more.
- Six models involved at various points, from different vendors and including open-weight ones running locally. Anthropic, OpenAI, Alibaba, Google, and a local open-weight model. A Moonshot model is something I have access to and have not used yet.
- One autonomous mission completed end to end in a private repository, with no human between the objective and the merge commit.
- A long written record of everything that went wrong, kept at the time it went wrong rather than reconstructed afterwards.
The method
I make the models argue. One writes, a different one from a different vendor reviews, and when they disagree I make them justify, concede, or explain until something resolves. I am not adjudicating on technical merit, because I cannot. I am watching whether the disagreement resolves for a reason or resolves because one of them gave up.
Then a deterministic gate, no model involved, checks that the required evidence actually exists before anything is allowed to merge.
The reason there are so many models is not sophistication. It is that I do not trust any single one of them, including the ones I like, and I have been given specific reasons not to.
Where to start
The proof record has the one completed mission, the failure history, and the honest residual. The checklist has twenty-two questions to ask about an agent-shipped change.
If you want to argue with this
Written contact only. The invitation is to disagree, correct something, or say what your own setup looks like.
What would you need to prove about an agent's change before you would let it merge without you?