In one ashikov.ru task, I added a check for file endings. Regular text files had to end with exactly one LF, while Markdown files had to end with two.
The implementation looked complete. The check was part of the common make check command, positive and negative cases passed, and the final verification was green.
A separate review found a case those checks missed: a file ending with CRLF could still pass even though it violated the stated rule.
The problem was not the absence of tests. There were enough checks to make the implementation look convincingly correct, but not enough to disprove it.
After several cases like this, I started treating coding-agent review differently. I want the second agent to see the task, repository rules, and resulting change, but not the history of how the first agent arrived there.
Review independence depends not only on who performs the review. It also depends on what context the reviewer receives before starting.
Clean Context Does Not Mean No Context
The second agent should not work blindly.
It needs:
- the original task or issue
- current repository rules
- acceptance criteria
- the current codebase
- the diff
- available reproducible checks
That is enough to determine whether the task has been completed.
Before the first review pass, I try not to provide:
- the implementation conversation
- the first agent’s plan
- its explanation of the chosen solution
- its self-review
- its final argument for why the task should be considered complete
Those are not part of the task contract. They are the implementer’s interpretation of the result.
task context
→ what must be true
implementer context
→ why the implementer believes it is already true
An independent reviewer needs the first one.
The Implementer’s Explanation Frames the Review
A coding agent usually produces a useful final report. It lists changed files, explains implementation decisions, and shows which checks passed.
That report is valuable to the owner of the task.
For a fresh reviewer, it can be too strong a hint.
If the second agent starts with something like:
implemented A
handled case B
verified C
all checks pass
it already has a model of what the result is supposed to mean. It can validate those claims and produce another confirmation of the same model.
That is not what I need from a second pass.
I want the reviewer to reconstruct this relationship independently:
requirement
→ implementation
→ evidence
and look for places where it breaks.
So the first question is not “Did the first agent implement this correctly?”
It is closer to:
Which properties of the task does this change actually prove, and what counterexample would show that the evidence is insufficient?
That makes the review start from the contract rather than from the author’s explanation.
How a Green make check Missed CRLF
For the file-ending task, the contract was simple:
regular text → exactly LF
Markdown → exactly LF LF
The implementation inspected the final bytes of each file. For regular text, the condition checked that the ending contained the required LF and did not contain an extra LF.
At first glance, that was enough.
The separate review asked the reverse question: which invalid byte sequences could still satisfy this condition?
That exposed CRLF.
Its last byte is also LF, so the check could succeed even though a forbidden CR appeared immediately before it.
Markdown had a similar edge case.
After the review, the condition was fixed and regression scenarios were added specifically for those endings.
The interesting part is not CRLF itself. That bug only required a small change.
The important part is that the first pass already had a working implementation, negative tests, and a green common gate. The additional value came from independently looking for an input that would make the claimed property false.
The Second Agent Should Rebuild the Proof
If the first agent’s job is to implement the change, the second agent should have a different job.
The implementer roughly follows this direction:
contract
→ solution
→ checks
→ finished result
The reviewer should work backwards:
result
→ which property is proven
→ what proves it
→ which cases remain uncovered
→ whether that matches the original contract
This can expose more than bugs in the implementation.
The reviewer may find that a test verifies an internal detail instead of the required behavior, a negative case is missing, one acceptance criterion has no evidence at all, or the change affects behavior outside the requested scope.
In the previous article, independent review was one layer in the evidence used to establish coding-agent readiness. The next boundary is what makes that review independent in the first place: the reviewer has to reconstruct the evidence rather than inherit it.
Read the First Agent’s Report After the Review
I do not discard the implementer’s final report.
I change when it is read.
The second agent first receives the task and the resulting change and reaches its own provisional conclusion. Only then do I compare that result with the implementer’s report.
At that point the report becomes another verification source.
For example, the implementer may claim that a particular scenario was tested, while the reviewer cannot find evidence for it. That discrepancy is worth investigating.
Or the reviewer may identify an important boundary that does not appear in the first agent’s report at all. That suggests the original proof of readiness did not cover that part of the task.
The sequence becomes:
implementation
→ implementer self-check
→ independent clean-context review
→ compare with implementer report
→ fixes
→ repeat verification
The author’s report remains useful without determining the direction of the first independent pass.
A Different Model Is Not Required
The second review can use a different model. Differences between models may produce different analysis strategies.
But changing the model does not create independence by itself.
If the second agent receives the first agent’s full conversation, implementation plan, architectural explanation, and self-review, it still starts inside an already constructed model of the solution.
The reverse is also true. A fresh run of the same model can provide useful review when it receives a separate context and has to reconstruct the requirements and evidence on its own.
I therefore treat these as different properties:
different model
≠
independent review
separate context
→ ability to reconstruct the proof independently
A different model can strengthen the second pass. It does not replace context isolation.
Not Every Change Needs a Second Agent
I do not use this process for every commit.
For a mechanical change with narrow scope, an unambiguous contract, and an existing automated check that directly covers the required property, another agent may add little value.
A separate pass becomes more useful when the implementer has substantial freedom: choosing an architecture, defining the boundaries of the change, adding new verification, or handling many behavioral branches.
I find it particularly useful for CI/CD changes, automated workflows, repository rules, and similar logic where it is possible to produce a formally green result while leaving part of the real contract unverified.
The more freedom the implementer had in constructing both the solution and its evidence, the more valuable it is to reconstruct that evidence independently.
The Second Agent Is Not There for a Second Opinion
The number of agents alone provides no guarantee.
Two agents can confirm the same incorrect model of a task.
I do not need another voice saying that the solution looks reasonable. I need another path from the requirements to the evidence.
So I separate the roles like this:
first agent:
implement the task
and prove that it is ready
second agent:
do not trust that proof
build your own
If both paths independently reach the same conclusion, confidence in the result becomes stronger.
Not because the second AI is automatically smarter than the first.
Because it was not given the answer to the question it was supposed to verify.