The code looked clean. According to Abhishek Pareek, its ledger update still had a concurrency problem.
\nPareek, founder and director of Coders.dev, described a financial billing module in a written response to PSEEDR. In his account, \"the primary model missed critical race conditions in the ledger update logic because the syntax was clean.\" The team caught those risks only after it added a second, architecturally distinct model to review the work. It now requires that review before the code reaches a human engineer.
\nFor an engineering lead, the appeal is clear: another reviewer may catch a costly mistake before anyone ships it. The harder question is what to do with the review once it arrives. An objection can reveal a real defect. It can also rest on a mistaken requirement, or describe a failure that the implementation already prevents. Each of these can sound equally persuasive on the page.
\nPareek's account also leaves open what made this particular review succeed. He describes the second model as a more robust reasoning model, so the team changed both model family and model strength at once. We do not know whether a fresh review by the original model would have caught the defect, or how many false alarms accompanied the useful finding. His experience gives a team a reason to try the workflow; it does not isolate the benefit of changing models.
\nGiacomo Balli, CEO of BigBalli Consulting, uses Claude Code to write most of the code in his one-person studio and Codex to review it. He captures the next step plainly: \"I treat a disagreement as a reason to go look rather than a verdict.\"
\nIn Balli's workflow, Claude takes a first pass, Codex critiques the plan or the diff, and the two go back and forth before Balli makes the final call. He reserves this process for work that is large or hard to reverse, not every routine change. He describes its value as an impression from daily use rather than a measured defect rate, and reports no commercial relationship with either vendor.
\nSeveral things change at once in that arrangement. The code gets another pass. The reviewer is asked to find failures rather than finish an implementation. Its context may differ too: if the author model has spent a long session developing one design, while the reviewer starts fresh with the diff and the original requirements, the two are not reading from the same starting point. A different model is one more change on top of these. Balli's response does not specify whether his review context differs in this way.
\nA team can reasonably prefer the whole arrangement without yet knowing which of these changes helped the reviewer find a defect.
\nBalli describes the danger of carrying the author's assumptions into the review: \"two passes that agree are not confirmation, they are a shared blind spot, usually the first model's unstated assumptions carried straight into its own review.\" His observation supports giving the reviewer room to examine the requirement afresh. It does not establish that a different model family is the only way to create that room.
\nThere is evidence that the same model can improve its own work. In the 2023 Self-Refine paper, which tested GPT-3.5 and GPT-4, one model generated an output, wrote feedback on it, and used that feedback to refine the output. The authors reported improvements over a single pass on the tasks they evaluated, including code optimization and code readability. On math reasoning, however, they found almost no gain. The feedback rarely located an error; for one model, 94 percent of the feedback said everything looked good. When the authors instead let an external signal tell the model which answers were wrong, the gains on that task grew.
\nThese results do not rank today's code-review products, and they do not show that self-review will catch a production race condition. They do challenge the blanket claim that a model can only repeat its own mistakes. The pattern is more specific: when the feedback step recognizes a problem, refinement has something to work with; when it cannot recognize the error, another round changes little.
\nFor a team choosing a reviewer, this shifts the question toward observable work. Which consequential defects does the extra pass find, and how much effort does it take to separate those defects from false alarms? Model agreement alone cannot answer that. Neither can disagreement.
\nA useful review finding connects a situation the code can actually reach to a requirement it would violate. A hypothetical ledger makes that connection easier to see. This example illustrates a possible failure; Pareek did not share his code, so it is not a reconstruction of his incident.
\nSuppose two workers, A and B, each need to apply a different transaction to the same account balance. Both read the old balance before either worker writes a change. A calculates a replacement balance from the old balance and A's transaction. B separately calculates its own replacement from that same old balance and B's transaction. Neither calculation knows the other exists.
\nA writes its calculated balance first. B then writes its own calculated balance, replacing the value A just stored. Because B calculated from the old balance, B's replacement includes B's transaction but leaves out A's. The final stored balance fails to reflect both transactions. This sequence is a lost update, and it happens because each worker writes a whole replacement value rather than applying its change to whatever is currently stored.
\nWhether real code permits this sequence depends on its transaction boundaries, locking, and write behavior. A warning that two requests might run concurrently has not yet established a bug.
\nThe reviewer therefore needs to point to the relevant code and explain how that sequence can occur there. The engineer can then inspect the implementation, or write a targeted test that forces the proposed order of reads and writes. If an existing guard prevents the sequence, there is a concrete reason to reject the finding. If the sequence is reachable and the requirement is to preserve both transactions in the balance, the team has a defect to fix.
\nAnthropic's Code Review documentation describes a similar separation between finding a possible problem and verifying it. Agents analyze the diff and surrounding code, and a verification step checks candidate findings against actual code behavior before the results are deduplicated and ranked by severity. The documentation also suggests a repository instruction requiring behavior claims to cite a source file and line rather than infer behavior from a name. This is one vendor's documented review process. It illustrates what verification involves without showing that verification requires another vendor's model.
\nA failing test can make a review finding much easier to investigate. It can also make a wrong assumption look authoritative. The test tells you that the code did not meet the expectation written into the test. You still need to know whether that expectation belongs to the software's actual requirements.
\nAnthropic's work on property-based testing provides examples of both outcomes. Its agent read code and documentation, inferred properties that should hold, and wrote tests for them. One property was straightforward: if a function slices a dictionary into chunks, reconstructing the dictionary from those chunks should produce the original dictionary.
\nThe function instead returned the first chunk repeatedly, because it never advanced its iterator. Reassembling repeated copies of the first chunk could not restore the omitted entries. Here the property described the intended behavior, the test exposed how the implementation broke it, and the maintainers merged the fix.
\nA report about dateutil's Easter calculation went differently. The test flagged dates that did not fall on a Sunday for some years under the Julian calendar. Maintainers explained that the behavior was intended, because calendar systems differ. The test had found a mismatch with its own expectation, but that expectation did not correctly capture the intended behavior.
\nThe researchers name the underlying difficulty: when code relies on an implicit assumption, only the maintainers can decide what property correctly describes the intended behavior. They also describe the review that stood between a failing test and a filed report. Three expert reviewers spent about an hour per candidate bug, and any bug that left one of them uncertain was discarded before the authors did their own review. Producing a failing test was part of the investigation, not the final decision.
\nAn author and a reviewer can likewise agree on what a test should demand and still misunderstand the requirement. Resolving their finding requires checking both the observed behavior and the reason it is supposed to be wrong.
\nBalli also sees a source of noise in how the review is assigned: \"the reviewer has to be told explicitly that agreeing is a valid answer, or it manufactures objections to look useful, which is its own kind of noise.\" His observation points to a practical choice in the review brief.
\nGive the reviewer the intended behavior, the relevant constraints, and access to the code it needs to check a claim. Ask it to explain the affected path, what should happen there, and the consequence if the code behaves differently. Make a review with no findings an acceptable result. The Code Review documentation describes that outcome too: when the review finds no issues, the check run reports that none were detected.
\nClear expectations also help the engineer decide when to stop a debate. A finding does not get stronger because the models argue about it for another round. New evidence can strengthen it: a reachable caller, an overlooked configuration, a failing input, or a requirement the first pass missed. Another round that merely restates the same hypothetical adds nothing. When the author model receives an objection, it should inspect the alleged failure in the code and respond with what it found there, rather than implement the objection because it was raised.
\nA rejected finding should carry a reason: the path is unreachable, or the requirement permits the behavior. If a consequential finding depends on a fact the team cannot establish, it stays unresolved. Agreement between the models does not supply that missing fact.
\nEven a valid observation needs a decision about scope. A pre-existing bug may belong in a separate fix. A readability suggestion may improve the code without justifying a release block. Those distinctions let the team resolve the review of the current change without turning it into an unplanned rewrite.
\nBalli's choice to reserve the extra review for large or hard-to-reverse work gives a team somewhere to start. The consequence of a mistake matters more than patch size alone. A small authorization change can carry more risk than a large presentation change.
\nTo find out whether changing models helps on its own work, a team could compare review passes on the same changes. Run two reviewers: a fresh session of the author model, and a different model. Give both the same diffs, requirements, repository context, and review budget, and let each finish a separate pass before either sees the other's findings. This is a proposed comparison, not an experiment conducted for this article.
\nThen resolve the findings against the code and requirements. Count consequential defects caught by one approach and missed by the other. Record false alarms as well, and the time engineers spend investigating them. More comments can create more work without finding more important failures, so comment volume is a poor substitute for that comparison.
\nEven a careful comparison cannot prove that a patch has no bugs. Finding no additional defect leaves open the possibility that both reviewers missed one. Review findings belong alongside tests, operational constraints, and the team's knowledge of the system. Two model approvals cannot replace a verification step that has yet to happen.
\nPareek's experience explains why a team might add another reviewer. Balli's workflow shows why someone must own the decision that follows. A failure path the first pass missed, a requirement it overlooked, or an assumption worth challenging gives that person something concrete to investigate. Establish what can happen, check why it would be wrong, and change the code when the evidence supports the finding. When the next objection adds no new evidence, let the review end.
\n", "articleImage": { "alt": "Two metal inspection cards show a check mark and a question mark above a circuit board and test probe. Text: Prove the bug.", "width": 1280, "url": "https://content-edge-frzs2wwjiq-uc.a.run.app/assets/article-covers/a-second-ai-code-reviewer-helps-only-when-someone-settles-the-disagreement.d0e3dba1.jpg", "height": 720 }, "image": { "@type": "ImageObject", "alt": "Two metal inspection cards show a check mark and a question mark above a circuit board and test probe. Text: Prove the bug.", "width": 1280, "url": "https://content-edge-frzs2wwjiq-uc.a.run.app/assets/article-covers/a-second-ai-code-reviewer-helps-only-when-someone-settles-the-disagreement.d0e3dba1.jpg", "height": 720 } }