Verification Cost Is Not a Proxy for Correctness Risk
The bimodal code strategy has become the industry's consensus answer to AI-generated code risk. The argument goes: treat AI code generation as a spectrum. Automate aggressively where verification cost is low — boilerplate, scaffolding, tests. Require human authorship where verification cost is high — payment logic, security boundaries, mission-critical paths. Enforce the boundary in CI. Treat verification cost as a first-class architectural concern.
It sounds rigorous. It has a clean mental model. It gives teams a policy they can implement.
It is also built on a premise that doesn't hold.
The Premise
The bimodal strategy treats verification cost as a proxy for correctness risk. Low verification cost implies lower risk — you can run the tests, they pass, the code is safe to ship. High verification cost implies higher risk — you need human judgment because the tests alone aren't enough.
The premise embedded in that reasoning: passing verification means something about correctness. That a green test suite on AI-generated code is meaningful signal — not just about whether the code agrees with the tests, but about whether the code is right.
This is the premise worth examining before building an architecture on top of it.
What Verification Actually Does
Tests tell you what your system agrees with. They do not tell you what is true.
This is not a philosophical abstraction. Rice's Theorem establishes it formally: no non-trivial semantic property of a program is decidable in general. The space of possible inputs is infinite. A test suite is a finite sample over that space — a bet, formalised. Type systems constrain the output space, eliminating structurally incoherent programs. But structural coherence is not semantic correctness.
What you have when a test suite passes is this: the generated code satisfies the tests a human wrote. That is a much weaker claim than "the generated code is correct." The verifier does not introduce truth. It introduces a formalised opinion — marginally better than an unformalized one, not categorically different from one.
The bimodal strategy's "low verification cost, automate freely" zone is not a lower-risk zone. It is a zone where the team has accepted a weaker correctness signal and called the acceptance safe. The risk hasn't decreased. The signal quality has decreased. The strategy treats those as equivalent.
The Boundary Is Drawn on the Wrong Axis
The bimodal strategy draws its boundary on verification cost. What it should be drawn on is consequence of undetected failure.
These are not the same axis, and the difference is not subtle.
A data serialization layer is low verification cost — tests are easy to write, coverage is easy to achieve, a passing suite is fast to produce. By the bimodal strategy's logic, this is safe territory for AI generation. But a serialization layer that touches every API response has a blast radius proportional to traffic. A silent corruption bug — one that produces structurally valid output that is semantically wrong — will not be caught by a type checker. It may not be caught by tests that were written to verify the happy path. It will be caught by users, three days later, after it has propagated through every cached response in the system.
A complex pricing algorithm that runs once a month for a single enterprise customer is high verification cost — the logic is intricate, edge cases are numerous, test coverage is hard to achieve. By the bimodal strategy's logic, this is dangerous territory. But its consequence of undetected failure is bounded — one customer, one billing cycle, a recoverable error.
The bimodal strategy would protect the pricing algorithm with human authorship and ship the serialization layer with AI generation and a green test suite. It has assigned higher risk to the lower-consequence code and lower risk to the higher-consequence code — because it confused verification cost with correctness risk.
Consequence of undetected failure is determined by: blast radius (how much of the system is affected), detectability (how quickly a failure surfaces), and recoverability (how reversible the damage is). None of these properties correlate reliably with how easy it is to write tests.
The Human Authorship Assumption
The "human-authored only" zone of the bimodal strategy rests on a second assumption: that human authorship, combined with verification, gives you something meaningfully closer to correctness.
It gives you human judgment applied to a formalised opinion. Which is better than no human judgment. Which is not the same as correctness.
A human engineer writing payment processing logic is exercising 10 years of accumulated intuition about edge cases, failure modes, and business semantics. That intuition is valuable. It is also not a truth oracle. The tests they write are still a finite sample over an infinite input space. The type system still only verifies structural conformance. The code review is still one person's opinion reviewed by another person's opinion.
Human authorship raises the quality of the input to the verification process. It does not change what the verification process is capable of establishing. The "human-authored, high verification cost" zone of the bimodal strategy is not a correctness zone. It is a higher-quality-opinion zone with a more expensive verification step attached.
That distinction matters when the strategy is used to justify confidence. "We require human authorship and full test coverage for mission-critical paths" sounds like a correctness guarantee. It is a process guarantee — a statement about who wrote the code and what tests were run, not about whether the code is right.
Enforcing the Wrong Boundary Mechanically
The most operationally appealing part of the bimodal strategy is CI/CD enforcement. Policy in a document gets ignored under delivery pressure. A pipeline gate doesn't.
But a pipeline gate enforcing a boundary drawn on the wrong axis systematises the error. You have now mechanically enforced a policy that protects the wrong code with human authorship and ships the wrong code with automated generation — consistently, at scale, with the confidence that comes from having a process.
This is a known failure mode in software architecture: formalising an incorrect intuition makes it harder to correct, not easier. The informal version is questioned when it produces bad outcomes. The formalised version is defended because questioning the process requires questioning the architecture.
A gate that asks "was this module in the human-authored zone?" is answering the wrong question. The question the gate should ask is "what is the consequence of an undetected failure in this module, and is the verification quality sufficient given that consequence?" That question is harder to mechanise. It requires reasoning about blast radius and detectability that doesn't reduce to a module classification.
The bimodal strategy chose the question that could be enforced in CI over the question that should be answered. That choice has a cost.
What a Consequence-First Architecture Looks Like
Rejecting the bimodal strategy does not mean abandoning architectural discipline around AI-generated code. It means anchoring that discipline to the right property.
A consequence-first architecture classifies modules not by verification cost but by failure consequence:
Consequence class A — failures are immediately detectable, bounded in blast radius, and reversible. A standalone analytics job, a reporting module, a batch process with idempotent retries. AI generation with standard verification is appropriate here — not because the verification proves correctness, but because failures surface quickly and recovery is cheap.
Consequence class B — failures may be delayed in detection, moderate in blast radius, and partially reversible. An internal service, a background worker, a non-critical data pipeline. AI generation with elevated review standards — not test coverage targets, but explicit review of failure modes and blast radius.
Consequence class C — failures are potentially silent, wide in blast radius, or irreversible. Any layer that touches all traffic, any component with external financial consequence, any code path where a silent bug can propagate before detection. Strict review regardless of authorship, with explicit verification of blast radius and failure mode coverage — not just line coverage.
The serialization layer that touches every API response is class C. The complex monthly pricing algorithm may be class B. The classification inverts what the bimodal strategy would produce — and does so by reasoning about what actually matters when something goes wrong.
The Honest Version of the Strategy
There is a version of the bimodal strategy that is defensible — one that is honest about what verification establishes and uses consequence as the primary axis.
It sounds like this: AI-generated code and human-authored code are subject to the same verification limitations. Neither produces provably correct software. The question is not who or what authored the code — it is what the cost of being wrong is, and whether the verification process we have is adequate given that cost. Where the cost of being wrong is low and failures are quickly detected, we can move fast and accept the verification signal we have. Where the cost of being wrong is high and failures may be silent, we slow down — not because we trust human authorship more, but because we want more eyes on the failure modes, more explicit reasoning about the blast radius, and a higher-quality formalised opinion before we ship.
That framing doesn't give you a clean architectural boundary you can enforce in CI. It gives you a reasoning process you apply per module. It is harder to operationalise and impossible to fully automate.
Which is precisely why it's more honest. The clean boundary was always an illusion — a policy that felt like a guarantee because it was enforced mechanically. The consequence-first version makes the uncertainty explicit, which is the only intellectually defensible starting point for reasoning about correctness in systems that can't be formally verified.
Tests are still worth writing. Human authorship still matters. Verification still catches real bugs. But none of that is the same as correctness — and an architecture that treats it as correctness is building on sand, regardless of how neatly the sand has been organised.