Blog

AI coding assistants are no longer a novelty. They are part of everyday engineering. They write a growing share of production code, and they can generate code across the whole software lifecycle. But there is a catch: AI has increased the volume of code much faster than it has increased our confidence that the code is correct, secure, and actually does what we intended.

So the bottleneck has moved. It used to be writing code. Now it is verifying code. And that turns the hard question into a governance question: Who is accountable for AI-generated behavior? How do we detect when it drifts from intent? How do humans and models split the work of oversight?

This is not abstract. Regulations and frameworks like the EU AI Act, ISO/IEC 42001, and the NIST AI Risk Management Framework now expect risk management, record-keeping, and meaningful human oversight. If more production code is AI-generated, saying “we review it carefully” is not much of an answer.

The popular response is to review the specification, not just the code. Treat the spec as the contract the AI must satisfy. Review it up front. Hold the generated code accountable to it. The author believes in that idea, but wanted to test whether it survives measurement. So they built a study around the central human act: reviewing AI-generated code against an approved baseline.

The honest result changed how they argue for the whole approach. A specification baseline did not help reviewers catch more bugs. What it did was make the bugs they caught accountable. That distinction matters, because it tells you when the cost of spec-driven governance is worth paying.

The study: baseline vs. code-only

The study used a multi-account banking service — a small but regulated domain where correctness, validation, limits, interest, statements, and audit trails all matter. The baseline had three layers:

1. Specification — business requirements and rules.
2. High-level design (HLD) — components and interfaces.
3. Low-level design (LLD) — concrete invariants each method must uphold.

For example: a transfer must be atomic, idempotent, and must never create or destroy money. Those requirements become named invariants a reviewer can check against the generated code. The full baseline defined twenty such invariants.

Five reviewers, each with three to ten years of experience, reviewed real AI-generated banking services in two conditions:

• Baseline condition: they received the approved spec, HLD, and LLD, and reviewed the code against it.
• Code-only condition: they received only the public API and had to judge correctness without an approved contract.

This code-only setup is basically today’s default AI-code-review workflow.

The headline result: recall vs. attribution

The study measured two things:

• Recall: how many real drifts or defects the reviewer found.
• Attribution: whether each finding could be tied to a specific approved requirement or named invariant, rather than just “something looks off.”

The results were a trade-off, not a clean win.

• Recall did not improve. Baseline reviewers found 0.525 of real drifts on average. Code-only reviewers found 0.518. The difference was statistically indistinguishable.
• Attribution improved dramatically. Baseline reviewers tied 81% of their findings to a named clause. Code-only reviewers tied 0%. They had no contract to point at, so they could only say things like “I can’t tell whether this behavior was intended.”
• Confidence rose from 3.4 to 4.2 on a five-point scale, but only directionally.
• Time cost rose sharply. Baseline reviews took about 48 minutes on average. Code-only reviews took about 27 minutes.

So the spec baseline did not make reviewers better bug-finders. It turned drift review into a contract-anchored, attributable, higher-confidence activity — but at a real time cost.

A replication with large language models in the reviewer seat found the same pattern. Across ninety machine reviews, recall stayed basically unchanged, while attribution collapsed from 0.67 with a baseline to exactly 0.00 without one. The lesson: without an approved contract, there is no requirement to cite — for humans or models. LLM code-review tools can be useful as a pre-screen, but without a governed baseline they cannot produce a real accountability trail.

Delivery matters more than presence

The generation side produced another counter-intuitive finding: how you deliver a specification matters more than whether one exists.

On a twenty-invariant banking service, asking the model for “a specification, then the code” in a single prompt was indistinguishable from just asking for code directly. Both landed at 23.8% on a weak model. But a staged approach — author the specification, then implement from it in a fresh generation step — nearly doubled the pass rate to 45% and halved build failures.

The difference was not the words. It was treating the spec as a governing artifact rather than inline prompt text.

There is also a deflationary catch. On easier tasks, the dramatic gains people attribute to “specifying first” are largely a reasoning effect in disguise. When the model was asked to reason about edge cases first but write no specification at all, that chain-of-thought arm captured almost all of the apparent spec-first gain. So if you want to claim specification prompting improves quality, you need to control for reasoning first.

Costs, limits, and when to spend the effort

None of this is free.

The most concrete cost is time. Spec-anchored review took roughly 48 minutes versus 27 minutes for code-only. That is a recurring labor cost. It is predictable, and it is the most automatable part of the loop, but today it is a real tax.

There is also the up-front discipline of authoring specs, HLD, and LLD, and keeping the baseline synchronized as the system evolves. That discipline is the main deployment barrier.

The evidence also has honest limits. This is a small pilot: five reviewers, two services, one domain. At that sample size, “significant” results certify a consistent direction, not a calibrated effect size. The staged-generation win may partly come from the model being run twice. The automated replication supports the pattern but is not a substitute for human oversight.

So the conclusion is not “always write specs.” It is a targeting rule.

Specification governance pays off most in one specific corner: hard, multi-constraint work built by a capable-but-imperfect model.

On the complex banking task, the weaker model gained about twenty-one points from spec discipline. The strong model, which already aced the task, gained roughly two. On trivial tasks, the apparent win was mostly the reasoning effect.

Reach for spec governance on regulated, high-stakes, long-lived systems — finance, insurance, healthcare — where many constraints must stay consistent, intent must survive over time, and you already owe an audit trail to a regulator or standard. Skip it for throwaway scripts, prototypes, and tasks your assistant reliably one-shots.

When you do use it, make accountability explicit. The model is Responsible for generation, but a human is always Accountable. The artifacts — approved baseline, generation record, drift log, reconciliation record — can support the governance, traceability, record-keeping, and human-oversight controls that NIST AI RMF, ISO/IEC 42001, and the EU AI Act emphasize.

A staged adoption path keeps the cost manageable:

1. Pick the corner: apply governance only to your highest-stakes, multi-constraint service.
2. Stand up the gate: review the spec for completeness, interfaces, constraints, and testable behavior before generation.
3. Make the baseline explicit: approve and version spec + HLD + LLD as one auditable baseline.
4. Add drift detection: compare generated code against the baseline and route each flag to a reconciler.
5. Automate the walk: use an LLM pre-screen to triage likely drifts before human review.

Conclusion

AI made code abundant. It made governance, not writing, the new bottleneck. The instinct is to sell specification discipline as a way to catch more bugs. The measurements say otherwise: an approved baseline did not raise recall, but it took drift review from 0% attributable to 81% attributable, at a real and quantified time cost. Delivery beats presence. Easy-task gains are mostly reasoning. The limits are worth stating out loud.

So govern the input before the output. Hold the code accountable to an approved baseline. Name the human accountable for deciding how each meaningful drift is resolved. Then spend that governance where the targeting rule says it pays off: hard, high-stakes, long-lived systems built by capable-but-imperfect models — not as ceremony everywhere else.

Make the code abundant. Just don’t make the plan optional. And don’t pretend the plan is free.