AI writes the code, the tests, and the checks on them. The chain can't see its own blind spot

The article describes a methodology of AI-assisted development in which the machine writes the contract, the implementation, the tests, and the checks on them, while the human is left only with intent and a single final review. The main risk is that when one model passes through all the layers, its single blind spot propagates through the entire chain — something the system cannot check on its own. The author therefore calls for enforced independence — mutation-tested and property-based tests, model diversity, and human review at the level of intent — drawing on Brooks, design by contract, data from SWE-bench, and Article 14 of the EU AI Act.

In the methodology of AI-assisted development, the machine takes part in almost everything—from formulating the contract through implementation and tests all the way to verifying and pre-cleaning them. What remains for the human is twofold, the things the machine does not supply: the intent, that is, what the system is supposed to guarantee, and a single independent code review. But if one model writes all the layers, its one learned assumption runs through the entire chain—a blind spot that the chain never checks on itself. The whole methodology stands or falls on whether it can enforce that independence rather than merely pretend to have it.

In 2026, the best agentic systems solved around 87.6% of the tasks in the SWE-bench Verified set, assembled from real bugs in open-source projects that humans once fixed; the figure holds for Claude Opus 4.7 from April 2026. An impressive number—until you add the second one. On the harder, more memorization-resistant SWE-Bench-Pro set, even top models held a standardized score of around 46% in early 2026 (Claude Opus 4.5); when that set was introduced in autumn 2025, it had been barely 23%. Between 87 and 46 percent lies almost the whole truth about what artificial intelligence can do in development today: routine, well-bounded work it largely handles on its own, the harder work roughly by half. And there is one more warning. The paper "The SWE-Bench Illusion" (arXiv:2506.12286) documented that models guess the path to a file purely from the bug description, without access to the repository they would supposedly need for it. So part of the success is memorization, not reasoning.

This asymmetry raises a question—when the machine does most of the routine writing, what is left for the human? The bottleneck in delivery today is not writing code, but reviewing it. It is an Amdahl bottleneck that sets the speed of the entire chain. If AI does not flood that bottleneck but pre-cleans it, the methodology I want to describe here opens up: AI-assisted design and implementation, in which the center of gravity of human work shifts from writing code to specifying it, and where the human review can remain the only one, because it comes after the machine filter.

This is possible only under conditions that can be described precisely. And what carries it is no figure about how many people will shift roles. What carries it is something else: the moment the same model is responsible for design, implementation, and checking, the whole methodology hangs on a single thing—whether the chain can maintain independence where it cannot see it itself. The rest of this text is about what must hold for that, and where it breaks.

The idea was formulated by Fred Brooks in 1987 in the essay "No Silver Bullet." He divided software complexity into accidental and essential. Accidental is the drudgery development creates for itself: writing repetitive code, managing types, syntax. Essential is the decision about what to actually build, how the parts should fit together, what is an assumption and what is a guarantee. Brooks argued that tools can carve away only the accidental; the essential stays with the human. If he is right, then AI that carves away the writing of code leaves the human with exactly what an architect does. And it is not a promotion of the coder to architect, but an uncovering of what was always the architect's work: the machine takes over laying the asphalt, the design reasoning remains.

We are not undermining our own foundation by saying so. The worry "if the machine takes over the writing, where will architects come from" rests on the conflation that an architect is necessarily a retired coder. An architect, like a structural engineer, comes primarily from a university; design thinking is a discipline in its own right, not an add-on layered over years at the keyboard. This does not rule out that they can code or that they worked their way up from below—that is a legitimate path, just not the only one and not the necessary one. We do not, after all, make bridge architects out of asphalt pavers: a bridge is designed by someone who can calculate the structure, not by whoever rolled the surface the longest. A programmer is not made an architect by the number of lines written, but by having thought about what the system is supposed to guarantee; and AI does not take that thinking away. Where those future architects will come from is a question for the schools, not for this methodology, and the answer is that they must educate different people, not churn out identical juniors into positions that are disappearing anyway. That is a topic for a separate text; I dealt with it in The Last Generation of Seniors and in The Second Derivative of Knowledge.

What must hold for a single code review to suffice

Let us start with what makes a review a review and not guesswork. Bertrand Meyer worked this out in 1992 into design by contract: every function has a precondition the caller must satisfy, and a guarantee the called party delivers in return. That is exactly the point—who is responsible for the call parameters and how the interface is defined. The theoretical basis is older, going back to Hoare's axiomatics of 1969. And it is precisely this layer whose intent is owned by the human architect and for which they are responsible: the contract is the assignment. The design of the contract itself, however, is AI-assisted. From the human intent the machine helps express the preconditions and guarantees, watches over their mutual consistency and completeness (whether any case has been left unhandled), and only then implements the code against the finished contract, verifies that it is met, measures coverage, and adds tests. What remains irreplaceably human here is the assignment and the judgment of what the contract is actually supposed to guarantee; the machine assists with the design and the realization around it, provided those boundaries are clear.

Named differently, it is test-driven development moved up a floor. In classic TDD (Kent Beck, 2002) the human first writes a test, then the code that satisfies it. Here the architect writes the contract—precondition, guarantee, property—and the machine fills in the implementation against it; "green" here is not a satisfied example but a verified specification. Property-based tests, which will come up shortly, are the same idea taken to its conclusion: the test stops being an example and becomes an assertion about intent. The discipline, however, holds only as long as the contract is driven by human intent. The moment its authorship is in fact taken over by the same machine that writes the code, what made test-driven development valuable vanishes—the independent description of what is supposed to happen.

But test coverage is a treacherous metric. Laura Inozemtseva and Reid Holmes showed in 2014 that, once you control for the number of tests, the correlation between coverage and a test suite's ability to detect a fault is only weak to moderate, and higher coverage percentages do not change that much. A tougher criterion is the mutation score (Jia and Harman, survey study from 2011): how many artificially introduced faults the tests actually catch. That this is not the same thing was documented by Meta on its own testing line. Of 571 tests its tool generated to catch previously uncaught faults, 277 (that is, 49%) would not have been detected had only line coverage been evaluated: they catch a fault without adding a single line of coverage. The requirement is therefore not "high coverage," but "mutation-vetted tests plus property-based tests that describe intent, not examples."

The second requirement is the filter itself—the AI code review before the human one. AI pre-cleaning takes hold where the work is mechanical: format, style, types, dead code and—newly most interesting—the assessment of static-analysis findings. The SAST-Genius tool in 2025 cut the number of false-positive reports by roughly 91% (from 225 to 20) compared with Semgrep alone; ZeroFalse reached over 90% precision on the OWASP benchmark set, so residual false alarms dropped to single-digit percentages. But here it is essential to separate precisely what pre-cleaning means, otherwise the problem from the piece on independent review returns. When the filter removes coarse noise—formatting, a trivial bug, a false alarm—it spares human attention for the substance and frees it from the fatigue of sifting through trivia; that is the psychological gain for the sake of which the human does not take the first look at raw machine output. But when the filter starts making design decisions and the human then merely approves the machine's solution, we are back at the anchoring I warned against in the series. The line runs between mechanical cleanup and substantive rewriting: the human reviews against the contract and the intent, not against the diff of changes the machine handed them.

For that line to hold, the code reviewer must have something other than a raw diff in front of them: the change in the contract, the change in the schema, the architectural decision affected (ADR in the sense of Nygard's 2011 record), the shift in the mutation score, and a triaged list of filter findings. And the application's schema need not be a stale model of the kind the CASE tools of the nineties ran aground on. A language model can regenerate it on demand from the code, so a C4 diagram or PlantUML stays current, because it is created anew rather than maintained by hand.

From this follows a fairly sharp division of labor. The filter reliably catches the mechanical: style, types, a large part of trivial security findings and their false alarms, missing edge tests, contract violations that trip an assertion. What remains for the human is what AI is demonstrably weakest at—whether that contract is even the right contract. That is the essential complexity, and at the same time the place where the machine breaks. Misu et al. (FSE 2024) did have GPT-4 generate verified methods in the Dafny language for 58% of the tasks, but these were textbook examples; Lahiri (FMCAD 2024) showed that even a specification that passes verification need not capture the intent—the code is verified, not what the code was supposed to do. The architect's work has not shrunk by this, only shifted: from writing lines to judging whether the contract corresponds to what is really being demanded of the system.

Five layers, one origin

The strongest objection, which does not go anywhere, is structural. In this division of labor the machine does not write only the code, the tests, and the pre-cleaning. In real practice even the design of the contract arises with AI assistance: the human holds the intent, but tunes the formulation of preconditions and guarantees with the machine, and the contract's internal consistency, its coherence, is in turn checked by AI. Summed up: one model has its fingers on the code, the tests, the pre-cleaning, the design of the contract itself, and its verification. Five layers, one origin, one learned assumption, and therefore one blind spot that none of them sees, because they all inherited it from the same weights. What remains exclusively human then shrinks to two things: the intent (what the system is actually supposed to guarantee, that is, precisely the essential complexity at which AI fails) and one final review.

To this is added the theater of metrics. A high mutation score and a "all contracts satisfied" report can both be gamed with equivalent mutants and trivial guarantees that merely restate the implementation—Goodhart's law in live broadcast. Independence here is therefore not grounded in the authorship of the contract, because that is largely machine-made; it is grounded only in the human intent and that single review, set against a chain otherwise saturated with one assumption.

What to do about it? Three things, and none of them is cosmetic. First, the human must review at the level of intent, not conformance: whether the chain does what the contract says is already verified by the machine; what the machine does not verify is whether it is the right contract, and that is exactly where human attention must aim. Second, "green" must mean something: mutation-vetted tests and property-based tests distinguish a genuine guarantee from a trivial one that merely copies the code. Third, and most importantly, real diversity must enter the chain—a different model or tool for designing the contract, a different one for checking it, a different one for the review, so that the blind spots do not overlap. This too has a ceiling: models trained on similar data share part of their assumptions, so different model families help more than different versions of the same one. Diversity shrinks the blind spot, it does not eradicate it. Without those three measures, AI-assisted design is nothing more than seat-of-the-pants programming one floor up—a chain admiring its own reflection.

The second objection is invoked most often in the debate and rests on a study by Judy Hanwen Shen and Alex Tamkin of Anthropic (January 2026). Fifty-two developers learning an unfamiliar asynchronous library performed seventeen percentage points worse in a subsequent test without AI after working with AI (roughly two grade levels, Cohen's d = 0.738, p = 0.01), with the biggest drop in debugging. It sounds like proof that AI dulls developers. But that study measures an entirely different question than the one this methodology poses: how a human does in the middle of acquiring unfamiliar material when AI is taken away from them. These were, moreover, experienced programmers (most with over seven years of practice) who were merely touching a specific library for the first time—not the training of beginners. Here, however, no one works without AI, and it is not about teaching novices at all: the architect writes the contract and reviews with AI at hand. A different population, a different condition, a different construct. It is not a weak argument against the methodology; it is not an argument against it at all, and I will not dwell on it further.

And there is a level I cannot pass over. Article 14 of Regulation (EU) 2024/1689, that is, the AI Act, requires for high-risk systems human oversight designed so that the person is able to recognize a tendency to over-rely on the machine's output; automation bias is named there literally. For remote biometric identification systems, moreover, Article 14(5) demands confirmation by two persons—there, one review of the system is by law not enough. Responsibility, meanwhile, rests with the deployer and the provider, not the model. After an incident, a single signature under the deployment must be traceable, and the reviewer must be able to explain why they let a particular defect through. If they cannot explain it, because they relied on a pre-cleaned diff, then not only they failed, but the entire design of the oversight.

So that this is not a matter of faith, the falsification conditions belong here. The methodology falls if an audit shows that contracts systematically describe the intent incompletely even when a human writes them; if human review after the filter catches faults just as often as two human reviews did before, meaning the filter pre-cleaned nothing; or if, after the shift of roles, the delivery metrics stay put and the whole reshuffling was merely cosmetic.

Writing contracts instead of lines is not a loss of craft; it is the craft moved higher, because the writing, the tests, and the debugging all aim at one place—at what the system is supposed to guarantee. But this draws the entire risk into a single point. When one day such a system goes down, the fault will not be in the code that no one wrote by hand. It will be in a badly built contract and in the single review that was supposed to catch it.

Note on methodology and sources

Primary, peer-reviewed, or official sources (high confidence):

Brooks, F. P.: "No Silver Bullet – Essence and Accidents of Software Engineering." IEEE Computer 20(4), 1987, pp. 10–19.

Meyer, B.: "Applying Design by Contract." IEEE Computer 25(10), 1992, pp. 40–51. (Meyer had introduced the term "design by contract" earlier with the Eiffel language; this essay develops it.)

Beck, K.: Test-Driven Development: By Example. Addison-Wesley, 2002.

Hoare, C. A. R.: "An Axiomatic Basis for Computer Programming." Communications of the ACM 12(10), 1969, pp. 576–580. DOI 10.1145/363235.363259.

Inozemtseva, L., Holmes, R.: "Coverage Is Not Strongly Correlated with Test Suite Effectiveness." ICSE 2014. DOI 10.1145/2568225.2568271.

Jia, Y., Harman, M.: "An Analysis and Survey of the Development of Mutation Testing." IEEE TSE 37(5), 2011, pp. 649–678. DOI 10.1109/TSE.2010.62.

Foster, C. et al. (Meta): "Mutation-Guided LLM-based Test Generation at Meta." FSE Companion 2025, arXiv:2501.12862. (Of 571 generated tests, 277, that is 49%, would have failed the line-coverage criterion even though they catch real faults.)

Alshahwan, N. et al. (Meta): "Automated Unit Test Improvement Using Large Language Models at Meta." FSE 2024 Companion, arXiv:2402.09171.

Misu, M. R. H., Lopes, C. V., Ma, I., Noble, J.: "Towards AI-Assisted Synthesis of Verified Dafny Methods." Proc. ACM Softw. Eng. 1(FSE), 2024. DOI 10.1145/3643763. (GPT-4 generated verified methods for 58% of the tasks from the MBPP dataset.)

Lahiri, S. K.: "Evaluating LLM-driven User-Intent Formalization for Verification-Aware Languages." FMCAD 2024. arXiv:2406.09757.

Shen, J. H., Tamkin, A. (Anthropic): "How AI Impacts Skill Formation." arXiv:2601.20245, January 2026. RCT, N = 52, GPT-4o model; difference in score 17 percentage points (≈ 2 grade levels), Cohen's d = 0.738, p = 0.01, biggest drop in debugging. Participants were experienced developers (most with 7+ years of practice) learning an unfamiliar library, not juniors.

DORA / Google Cloud: Accelerate State of DevOps Report 2024 (dora.dev/research/2024). The effect of AI on throughput and stability is associational, not causal.

METR (Becker, Rush, Barnes, Rein): "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity." arXiv:2507.09089, 2025. Update at metr.org/blog/2026-02-24-uplift-update/ (METR itself labels its −19% result as outdated and the new data as unreliable).

Regulation (EU) 2024/1689 of the European Parliament and of the Council (AI Act), Art. 14 (incl. para. 4(b) – automation bias – and para. 5 – two persons for remote biometric identification).

Nygard, M.: "Documenting Architecture Decisions" (ADR), 2011. Brown, S.: the C4 model (The C4 Model: Visualizing Software Architecture, O'Reilly, to be published 2026, available in early access; older self-published Leanpub version 2023).

Preprint / vendor / registry (medium confidence, the figures may change quickly):

SAST-Genius: arXiv:2509.15433, 2025 (reduction of false positives by ~91%, 225 → 20 vs Semgrep). ZeroFalse: arXiv:2510.02534, 2025 (precision > 90%, F1 = 0.912 on the OWASP Java benchmark set).

SWE-bench Verified (Jimenez et al., ICLR 2024): the ~87.6% figure for Claude Opus 4.7 (April 2026) comes from an aggregator citing Anthropic's announcement, and has not been independently re-measured under a uniform procedure. SWE-Bench-Pro (Deng et al., arXiv:2509.16941, 2025): at the set's introduction (autumn 2025) the best models solved around 23%; the ~46% figure is the SEAL standardized score for the leading model (Claude Opus 4.5) in early 2026. "The SWE-Bench Illusion": arXiv:2506.12286, 2025 (evidence of memorization).

Limits of this text:

The figure "half of coders → architects" has no primary source; it is a working hypothesis and an upper estimate. What can be empirically supported is at most the range "a substantial portion, on the order of 30–50%," and even that only indirectly (Brooks 1987 + DORA 2024), not by measurement of this specific workflow.

The rule "70% fast, 30% hurts" is practitioner folklore (Osmani, 2024), not proof; it therefore does not appear in the text as a hard claim.

The Shen and Tamkin study (2026) measures a different question—the performance of learning developers in a test without AI—than the one this methodology poses; it therefore does not appear in the text as a counterargument, only as a frequently cited but tangential objection.

Industrial adoption of contract languages is uneven: documented mass deployment is mainly for SPARK/Ada (aviation, railways); JML, ACSL, and Dafny are predominantly research.

The "shared blind spot" objection has a strong theoretical basis but is not quantified in the literature so far—it is an open problem.

This analysis was produced with the help of AI. The data and sources were verified as of the date of processing (May 2026), but the situation may change. Before using it for decision-making, I recommend updating the data and independently verifying the key findings.

Transparency of creation:

The concept, structure, and editorial line of the article are the work of the author, who drew up the content sketch, established the key theses, and steered the entire creative process. Generative AI (Claude, Anthropic) was used as a tool for research, locating primary sources, and the formulational development of the author's content sketch.

The author edited the outputs throughout, verified the key findings, and approved the final wording. No part of the text was published without human review. All factual data were verified against the publicly available sources cited in the text. The procedure is in line with the requirements of Art. 50 of Regulation (EU) 2024/1689 (AI Act) on the transparency of AI-generated content. #poweredByAI