Experience report
Controlled disagreement: automated adversarial review with a second coding assistant.
One coding assistant plans and implements. A second assistant, from a different provider, attacks it. The event closes when every finding has been resolved, refuted with evidence, or transferred to the developer. Never by consensus.
Why I wrote this
I work alone. My code does not review itself.
The fair question from anyone trusting me with a system: with no team, who checks what you ship. This is my answer, with the numbers from eight weeks of real work.
When someone hires a one-person studio, the mental discount is immediate: there is nobody to review the work. It is a legitimate objection, and answering it with good intentions is not enough.
My answer is a procedure. The coding assistant I work with writes the plan and then implements it. Before that plan is closed, and again before the changes are committed, a second assistant from a different provider receives the material with an explicit instruction: do not approve, attack. Find the security holes, the edge cases, the assumptions that do not hold. Every finding it returns is verified against the code before being accepted, and the event does not end until each one has been resolved, refuted with evidence, or moved into my name as a conscious decision.
That it comes from a different provider is not a whim. Asking a model to review its own output is not an independent control: the literature documents that self-correction without external signal does not reliably improve and can degrade, and that there are defects a model fails to see in what it produced but does correct when they arrive from outside. The point is not to assume the second one is smarter, but to introduce an external signal that may have different blind spots.
This report documents eight weeks of operating that way across five professional projects, with the accounting in plain sight. It includes what the method did not catch, the false findings that took work to dismiss, and a regression introduced by one of my own fixes derived from a correct finding. Without that part it would be advertising, not a report.
A note on this page: Pelatech is a Spanish-language site based in Argentina, so the navigation stays in Spanish. This article is the author's translation of the Spanish original, which is the version of record.
The operation
Eight weeks, counted.
Between June 2 and July 23, 2026, across five projects in production and development. The counts come from session histories and a calibration log written at the close of each round.
Over the auditable subset — the 277 findings from events with numeric counts — at least 64.9 % were incorporated and 3.6 % were refuted with evidence. Incorporated does not mean confirmed defect: it includes hardenings, design improvements, and mitigations accepted as a result of the review. The rest are transfers to recorded technical debt, explicitly accepted risks, and justified discards. It is a floor computed over a self-reported artifact, not an audit: the report declares that limitation and the counting rules in the appendix.
The five projects are identified as P1 to P5 and are not named: three are work for third parties, and the report generalizes any detail that would identify outside systems or organizations. The operational data was not altered.
The method
Two gates and one termination rule.
The roles do not mix: one generates, one attacks, execution arbitrates whatever can be arbitrated, and the last word is human.
To apply it, I condensed it into one page with the prompt, the closure states and the limits: minimal adoption recipe →
Fixed roles
The main assistant plans, implements, verifies findings against the repository and reconciles. The reviewer, from a different provider, attacks. Compilation and tests act as a partial oracle: they settle whatever has an independent oracle. The developer owns the result and answers for it.
Two gates, not one
The first runs over the plan, before any code exists. The second over the change set, before committing. The plan gate was recorded in the calibration log as the more valuable one. That is plausible: changing a design before implementing it is usually less costly, though that difference was not measured. It is also the one no test suite can cover, because there is nothing to test yet.
The prompt asks it to attack, not to approve
The reviewer's prompt is explicitly adversarial: functional errors, regressions, concurrency, security, persistence, domain assumptions, with severity and file:line evidence per finding. Plus a structural constraint that conditions everything else: the reviewer sees the repository but not the main assistant's conversation, so all context reaches it, and only reaches it, through the prompt. Two of the corpus refutations come from exactly that: the reviewer objected against a version of the context that a later decision had already changed.
Termination is by disposition, never by consensus
Agreement between two assistants that share training data does not make a conclusion true, and both can misread the same ambiguous specification in the same way. So the event ends when each finding, individually, has been resolved, refuted with verifiable evidence, or explicitly transferred to the developer. The transfer closes the event but leaves the finding open and owned: debt recorded with an identifier, accepted risk, partial mitigation, or pending escalation. Nothing closes out of fatigue.
Activation is a decision, not an automatism
Not every change goes through the reviewer. The written policy triggers a round when the work unit crosses a high-impact bar — contract between components, database migration, security or authorization, concurrency, logic that is hard to revert — or when there is genuine uncertainty. It is skipped for local, reversible or boilerplate changes. And every run is proposed and approved: it costs tokens and minutes.
The limits
What the method did not detect.
The part an honest report has to bring to the front. The escaped defects follow a clear pattern, and almost none is logic of the reviewed change.
- External contracts — five differences between what was planned and the real XML of a third-party service. Unverifiable with the artifacts in the repository: only the real example revealed them.
- Execution environment — a missing declaration in the Android manifest that broke the camera on every device. It passed the reviewer and three internal reviews; only the smoke test on an emulator caught it.
- Real system state — an integration test after five sprints revealed 23 findings no static review had.
- Product decisions — they require human authority and responsibility. They are not a defect a reviewer can find.
The regression introduced by a fix
The most instructive case in the corpus, and the worst. The reviewer found a real problem: loss of local files when the application crashed. The fix I applied solved that, but its mitigation mechanism introduced a different regression — duplication — which survived the event's closure, which I myself attributed to another cause, and which I ended up detecting on a real device two days later.
The underlying cause was not the reviewer: the component lacked tests because it depended on platform APIs. The lesson went into the calibration log and is worth more than any percentage: a fix derived from a finding is also new code without coverage, and deserves its own event before being closed.
The objection worth confronting
That the escaped defects betray missing tests rather than missing reviewers. It is true, and it does not compete: static review and real execution act on different defect classes and at different moments. Tests cannot review a plan — the gate where the incorporated findings concentrated acts before there is code to test — and the reviewer cannot execute the real environment. This experience did not evaluate how much of the reviewer's contribution could be reproduced through stronger specifications or tests.
What the report deliberately does not claim: that provider diversity is the cause of the observed benefit, nor that the net cost balance is favourable. The controlled comparison that would support either was not performed. The experimental design it would take is specified under future work.
Abstract
The abstract, verbatim.
As it appears in the PDF, split into paragraphs so it reads on screen.
This experience report documents a development methodology operated for 52 days spread over eight calendar weeks across five professional projects: a coding assistant (Claude Code, which executed two Anthropic models over the period) generates plans and implementations; a second assistant from a different provider (OpenAI's Codex CLI), whose underlying model was not recorded and may have varied, attacks them under an adversarial prompt; the first is instructed to verify every finding against the repository; and each review event terminates when every finding has been resolved, refuted with evidence, or explicitly transferred to the developer (the transfer terminates the event; the finding may remain open), a cut-off criterion here called controlled disagreement.
The report explains why the design is plausible (documented limits of self-review, error diversity, execution as arbiter), how it is operated (mechanism, minimal adoption recipe), and narrates one real complete flow end to end, with the prompt, the reviewer's 20 findings, their disposition, and the available timings and token consumption.
Two intervention mechanisms were observed: the detection of existing defects, and design shaping at the plan gate; both are illustrated with traceable cases, together with the false positives, the defects the method did not detect, and a regression introduced by a fix. On the auditable subset of the corpus, at least 64.9 % of findings were incorporated and 3.6 % were refuted with evidence. The available, reconciled accounting (91 documented gate events, units, coverage universes and reconciliations) is presented in the appendices, together with an operational recipe and a dated reference instantiation.
Causal attribution of the benefit to provider diversity, and the net cost balance, remain explicitly hypotheses: no controlled comparison was performed, and the pending experiment is specified.
The document
The full report, as a PDF.
Complete text with the references and the three appendices: operational data, operational recipe, and reference instantiation. Direct download, no sign-up.
Version 3.7 adds discussion of three contemporaneous works: the controlled cross-model review experiment between Claude and Codex (Xiang et al., 2026), the structured-disagreement protocol (Qiu and Gill, 2026), and Refute-or-Promote (Agarwal, 2026).
How to cite it
Reference and BibTeX.
The identifier is a concept DOI: it always resolves to the most recent version, so it does not go stale if the report is revised.
BibTeX
Contact
The report is explicit about what it did not test: the controlled comparison. If you have data from a workflow like this, or want to discuss the experimental design that is missing, write to me.