Phase 9. Code review: the critic agent against the author agent | Grigoriy Dobryakov

Grigoriy Dobryakov

Course · AI-Driven Development Lifecycle

Home ← Back to course
Phase 9ADLC course

Phase 9. Code review: the critic agent against the author agent

Phase 8 delivered PRs, and at least one hides a conflict at a task seam. Now we need a second pair of eyes — code review. And here the course makes a non-obvious claim: the value of a human reviewer never rested on their unique perspective, it rested on the scarcity of second eyes. You can put as many agents on it as you want, of any kind — which means "independence of view" is achieved through diversity, not through being human.

There's a subtlety easy to miss: review only works if the author and the critic aren't the same. With humans, that's automatic (different people). With agents, it has to be engineered, or you get the illusion of control.

Ideation1 Discovery2 Marketing3 Requirements4 Architecture5 Formation6 Planning7 Implementation8 Code review9 Testing10 Release11 Operations12 Maintenance13 Governance14

The human role today

A senior engineer or peer checks the PR for correctness, design, security, readability. They're the second pair of eyes and the keeper of team standards: catching bugs, flagging architecture violations, blocking or approving the merge. Classically this is manual review, comments, style debates, and the role of gatekeeper on the branch.

Break the reviewer's value into parts. Checking against rules (standards, linters, ADR compliance, known bug classes) is mechanical. An independent view ("I'd have done it differently, and here's where it breaks") is substantive. Scarcity ("second eyes are rare, review is a bottleneck") is organizational. The first automates completely, the third is removed by the number of agents, and the second — the very reason review exists — requires not a human, but exactly the otherness of the reviewer.

What we hand to the agent

The review agent holds the role of second pair of eyes. It checks the author agent's PR for bugs, design, security, and — critically — compliance with the ADRs from phase 5; it converses with the author; it blocks or approves the merge. On approve, it merges.

The key to the whole phase is role separation. Author and critic have to be different agents, and ideally on different models. If the reviewer is the same model as the author, they make the same mistakes: the critic will miss exactly the defects it would have made itself. That's not review, it's self-confirmation with an extra step. Model otherness stands in for human otherness here.

Agent architecture

Phase state-machine

Inputs

PR (phase 8), architecture + ADR (phase 5), project standards and linters, both contracts at the seam (to see cross-task conflicts).

The agent holds the role

Tools: static analysis; running tests; security scanning; ADR-compliance checking; comment generation; the authority to block a merge.

Artifact

a review with a verdict (approve / blocked) and comments; on approve, a merge.

Handoff: approved code → Testing (phase 10) and Release (phase 11); fixes → back to the author (phase 8). Note the input "both contracts at the seam." The review agent is the first point in the loop that sees more than one task at a time. Phase 8's author is locked inside their own task; the reviewer has access to neighboring PRs and to the architecture — and can therefore catch an assumption drift invisible from inside a single task.

Note the input "both contracts at the seam." The review agent is the first point in the loop that sees more than one task at a time. Phase 8's author is locked inside their own task; the reviewer has access to neighboring PRs and to the architecture — and can therefore catch an assumption drift invisible from inside a single task.

Where it breaks

Collusion of identical models. If author and reviewer run on the same model, review creates an illusion of control: the checkbox is ticked, but there was no independent check. This is a subtle trap — the process is formally satisfied, but there were no real second eyes. Model diversity here isn't decoration, it's the condition for the phase to work at all.

Blind spots of taste and horizon. "This will pass review but become a pain in a year" is a judgment about long-horizon maintainability the review agent makes worse than a human with operational experience. It's strong at what's checkable here and now, weaker at "this is technical debt that will bite later."

Accountability for what slips through. What passes review and breaks production is a question of accountability, not technique. More reviewer agents lower the odds of a miss, but they don't create a subject accountable for the consequences.

What stays human

Auditing review samples and calibrating standards — so the loop doesn't converge into a consensual hallucination that confirms itself. A candidate is involvement limited to irreversible and architecture-sensitive PRs. There's almost no durable remainder inside review itself: otherness comes from agent diversity, and accountability goes into governance (phase 14).

human remainder ≈ 40%

Provocation / thesis

Review is applying checkable rules plus an independent view. The rules automate completely. And "independence" is achieved not by having a human look, but by having someone other than the author look — and agent diversity delivers that more cheaply and reliably than scarce human attention. A human reviewer's value rested on the shortage of second eyes; you can put as many agents on it, of whatever kind, as you need. What stays non-transferable is only the calibration — so that different views don't collapse into one shared delusion.

Running case

Vitrina in this phase

The review agent on a strong model (provisioned back in team-spec, phase 6, specifically for the payment loop) takes the payment-idempotency PR. Inside the task, everything's clean — but the reviewer has access to the neighboring cart PR and to the ADR from phase 5. It catches what was invisible in phase 8: the cart agent treats an order as paid before webhook confirmation, the payments agent treats it as paid after. That's a direct violation of the ADR on retry resilience: a repeated webhook would process the order twice. The reviewer blocks the merge, writes a comment citing the ADR, and returns it to both authors.

Notice what did the work. The defect lived at the seam of two individually correct PRs — no single author saw it. It was caught by an agent with two properties neither author had: a different model (so it didn't make the same mistake) and a wider field of view (both contracts plus the ADR). Neither requires a human — both require correctly engineered otherness. Artifact → Vitrina's PR review, verdict blocked.

In practice

How it actually works — engineering breakdowns

Standalone howto from practice, showing this phase on real code and a working artifact.

Read next

Building AI-driven delivery in-house?

Designing the ADLC loop: where the agent holds the role and where the human principal remains — for your team and product.

Email me

The transition engine

Next Move Engine — the system that takes a team to an autonomous delivery loop.

Next Move Engine →