There is a bias anyone who has ever written anything knows: your own text always looks right. You read what you meant to write, not what you wrote. Code is the same. And with language models, the effect is even stronger.
An agent that just wrote a function will explain, with great conviction, why it is correct. Asking it to review its own work is asking it to confirm what it already believes.
Two agents, two goals
At Kabran, writing and reviewing are separate roles, with different instructions.
The agent that executes receives the issue and has one goal: deliver what was asked, with the smallest change that solves it, inside the house standards. It finishes by opening a merge request.
The agent that reviews receives only the merge request and the issue. It hasn’t seen the author’s reasoning, doesn’t know which shortcuts were considered, isn’t attached to anything. Its goal is different: find whatever keeps this from going in.
The reviewer isn’t there to agree. It’s there to look for what nobody saw.
The same ruler on both sides
A review is only fair if whoever writes and whoever reviews use the same criteria. That is why there is a single ruler, read by both. Among other things, it says what blocks a delivery:
- missing or half-delivered acceptance criteria;
- broken behavior or a regression;
- a security flaw, including a secret or environment value hard-coded in the code;
- a screen below the accessibility floor.
And it says, just as clearly, what doesn’t block: a better name, desirable refactoring, a non-critical optimization. A review that fails work on taste is as bad as one that approves everything.
What happens when it fails
The verdict comes back with the reason written and tied to the exact line. The work returns for a fix, and the new version goes through review again — from scratch, with no “I’ve seen this before”.
If the same kind of problem shows up several times, it stops being a code problem and becomes a standards problem. The question becomes: which instruction was missing so this wouldn’t happen? And the answer goes into the tracks, not into someone’s memory.
Review isn’t distrust
Separating who writes from who reviews isn’t a sign that AI is bad. It is the same principle any serious engineering team applies between people. Nobody is good enough to be the only pair of eyes on their own work.
The difference is that in a factory born with AI, you can apply that principle to every delivery, every day, without it becoming a bottleneck.