There is a classic doctrine in our field: the architect or lead developer knows every line of code.
I believed in it for a long time. With one lead and two developers, it works. With three developers, it gets very hard. With four, you either burn out or you lose control.
That was before AI. Now a single developer with a capable agent produces more code in a day than a small team used to produce in a week. The doctrine did not just get harder. It stopped being possible.
For now, architects and lead developers still review. Teams are learning, and reading the code is how you learn what the tools do. But in the long run, reviewing code line by line yourself does not make sense.
So the question in one of our community sessions was not whether to stop reading code. It was what replaces it.
One example made it concrete. In a medical imaging product, a single feature produced bug after bug for half a year. The real contribution of the architect and the lead developer was never checking the maths line by line. It was stepping back and saying: we have had enough, redesign this.
That is review at the right level. It is also the level that survives AI.
The first thing that needs replacing is trust in the agent's own report.
A Software Leader architect described it plainly. The AI says it implemented the feature according to the requirement. Then you look, and certain requirements are simply not met.
A ticked checklist from an agent is not evidence. It is a claim.
This is not malice. The model optimises for finishing the task as it understood it. If a requirement was ambiguous, or buried in a long context, it can drop out without anyone noticing, including the model.
The session also forced an honest choice. Are you a human in the loop, approving each step? Or a human over the loop, judging by results?
Both are valid. You cannot have both at once. If you choose to stand over the loop, you judge outcomes, and you accept that you will not know everything inside. Claiming you are over the loop while still demanding to see every line gets you the worst of both: the delay of review without its depth.
If humans cannot read everything, something else has to.
One architect runs three engines. One implements. Two independently review. If both reviewers agree, he does not dig further. Another wrote a small tool that makes two reviewing models argue with each other and feed each other's findings back in.
The idea is simple: models make different mistakes. Disagreement between them is a signal worth a human's attention. Agreement is a reasonable filter for what is not.
Tests need the same scepticism. Agents rewrite tests. Ask one to make a failing test pass and it may quietly change the test.
One participant solved this with simulation. He generated simulators from an OpenAPI specification in roughly a coffee break, covering most of the endpoints of a large cloud platform. Then he mounted the test code read-only, so the agent could not cheat.
Validation by simulation used to be expensive. Now it is cheap. That changes what is worth doing.
.png)
Competing agents and simulators catch defects. They do not tell you whether you built the right thing. That still needs a human, and humans need something they can actually read.
Until now, the code was the clear artefact. It was exact and complete. Now we have to go one step above it and still be clear.
One question in the session stayed with me. What if the AI drew a blueprint of what it built, and that blueprint was what we reviewed?
Architects in construction do not inspect every brick. They review drawings: the structure, the flows, the load-bearing decisions. The bricks are checked by process and by inspection at the right moments.
Software needs the same thing: a model of the system that architects and lead developers can take in. The AI may not need it to do its work. We need it to do ours.
While preparing the Software Leader Master Builder Clinic, I hit a gap that explains a lot of bugs.
Design tools show the flow from screen to screen. They almost never show when the front end calls which API, or what happens when the response is unexpected. That behaviour lives nowhere except in the code.
So that is where the bugs cluster. If the behaviour is not modelled, nobody can review it except by reading the code, which is exactly the thing we can no longer do at scale.
One participant suggested a split: humans write and closely review behaviour tests, while AI scans for security issues and bugs. It is a good start. Behaviour is where human judgement adds the most.
None of this means AI output will be clean by default. Even with detailed specifications, people in the session saw duplication creep in. A weekend project done without design produced a headache of repeated code.
That is not new. Almost every codebase I have seen at a client already needed refactoring. AI simply gets there faster.
The fix is the same as it always was: structure and context. A clear model of the system gives the agents something to build against, gives the reviewers something to check against, and gives architects and lead developers something they can still understand.
That is what we practise in the Master Builder Clinic: modelling processes, system interactions and behaviour first, so that review happens on the blueprint, not on every line.
Stop trying to read it all. Review the blueprint and the behaviour.
