If you let two coding agents loose on the same repository, something predictable happens: they help each other. And that is exactly the problem.
The chaos before
In the first version of NeoCoder, the backend and frontend agents had access to the whole repository. That seemed practical. The frontend agent can look up what the API really looks like. The backend agent sees what the frontend needs.
What happened then: the frontend agent needed a field the API didn't deliver. Instead of reporting it, it "quickly" added it in the backend. In parallel, the backend agent introduced the same field under a different name. Both test suites green. Two fields, two names, one meaning.
After a few weeks we had exactly what I warned about in "Code is getting cheap": several solutions for the same problem, and nobody knew anymore which one was right.
The architect comes first
So today it runs differently. Before anyone writes code, an architect agent works.
The architect agent writes two things: a specification of what is to be built, and a contract for how backend and frontend talk to each other. Which endpoints, which fields, which types, which error cases.
Only once that's in place do the coding agents start. Both at the same time, because they no longer need each other. One builds the API to the contract. The other builds the frontend against the contract. It's done when both sides fulfil the contract.
Why the separation is so strict
The two agents don't see each other's code. Not "should avoid it where possible". They can't.
That was a deliberate decision, and it was uncomfortable. There are cases where a quick look at the other side would have helped. But every one of those cases is also an invitation to quickly build something extra.
When the frontend agent needs a field today that's missing from the contract, it can't solve that itself. It has to report it. Then the architect agent looks: is that really missing? Does it already exist under another name? Is this the right place for it? And adjusts the contract, or doesn't.
That takes longer than "quickly adding it". A few minutes. In return, no second field with the same purpose comes into being, and the decision is documented.
Artifacts instead of chat
Between the agents, structured artifacts travel, not a chat history. That's the second part that holds it all together.
A chat history is readable for humans and worthless for machines. After thirty messages nobody knows what applies anymore. An artifact is unambiguous: this is the contract, version 4. This is the specification. This is the QA report.
Every task records what it produces and what it consumes. The backend agent consumes the contract and produces an implementation plus test report. The QA agent consumes both and produces a verdict. So it stays traceable where things come from. Weeks later too. Even when the session is long gone.
None of this is new
Fact is: contract first, clean interfaces, no cross-access between modules. We've done it that way in large systems at banks and telcos for years. That's the work of an architect.
What's new is only that it now has to exist in a form agents can work with. Not as knowledge in the head of someone who's been around for ten years. But as a rule an agent can't get around.
And that, I think, is the real task for the coming years: writing down what good architects always knew, in a way that still holds when nobody's watching.
The contract comes first. The agents only see that. Whoever needs something that's missing reports it, instead of grabbing it. That's slower per task and much faster per system.
Written by me. The thoughts, the values, the learnings, the mistakes: all mine. Grammar and spelling are corrected by our own twin model, trained on my texts. Sometimes a stumble stays in. That is mine too.