How strict coding standards boosted a major project

The move from writing code to verifying it has created a new bottleneck in software development. AI coding assistants, now adopted by engineering teams, produce an increasing portion of production code—but without clear methods to verify correctness, security, or alignment with requirements. Research demonstrates productivity gains in controlled tests, yet real-world deployment exposes delays, quality problems, and recurring security flaws. The core issue has shifted from model performance to responsibility. Who bears accountability for AI-generated outputs? How can deviations from intended behavior be detected? And where should oversight responsibilities lie between humans and machines?

Regulatory standards are now addressing these challenges. The EU AI Act’s high-risk provisions require risk management systems, documentation requirements, and meaningful human oversight. The ISO/IEC 42001 standard mandates a formal AI management system with controls and audit trails. Even NIST’s AI Risk Management Framework organizes expectations around four phases: governance, mapping, measurement, and management. When AI contributes to production code, simple output reviews are no longer sufficient. The focus has moved from whether AI can generate code to whether the entire process can be properly governed.

A study examined one solution: using specifications as governance foundations rather than mere prompts. The findings were definitive. A specification did not improve reviewers’ ability to find bugs. Instead, it transformed drift detection into a structured, high-confidence process where issues could be linked to approved requirements rather than vague concerns. The trade-off was time—reviews against a baseline took 48 minutes compared to 27 minutes for code-only checks. However, the additional time was consistent, and the accountability gap was closed.

How Specifications Function as Governance Tools

A specification under this framework serves as a three-layer agreement: business requirements, high-level design documentation, and low-level design specifications. For instance, a money-transfer application’s specification might state that transfers cannot result in negative account balances. The high-level design defines the TransferService interface, while the low-level design establishes testable rules—such as rejecting transfers exceeding available funds. These clauses form the drift contract that reviewers compare against generated code.

The governance approach relies on three core principles:

Establish governance over inputs before outputs are produced. Fixing a reviewed specification is less costly than correcting generated code.
Create an explicit, auditable baseline. The approved specification, high-level design, and low-level design together form a single reference point.
Keep humans engaged for judgment, not for handling volume. Automation identifies discrepancies, while a designated person determines correctness and documents changes.

This creates five control points across the development lifecycle, each producing artifacts for the next stage:

Develop and approve the specification, high-level design, and low-level design.
Reviewers confirm completeness, interface definitions, and testable behaviors.
The model generates code based on the approved documents.
Drift is identified by comparing generated code against the baseline.
A human resolves each discrepancy, recording adjustments.

The outcome is an iterative cycle rather than a one-way prompt process. A baseline is created, approved, and version-controlled. The model generates code against that version. Deviations are logged, and humans reconcile them. The records, approved baseline, generation log, drift log, and reconciliation notes, form the complete audit trail. Responsibility for generation rests with the model, but accountability always belongs to a human.

Drift Review: Recall versus Attribution

The study involved reviewers evaluating two AI-generated banking systems, one in Java and one in Python. Each reviewer performed two tasks: a baseline condition (specification plus high-level and low-level designs) and a code-only condition (public API only).

The results showed no statistical difference in bug detection between the two approaches (0.525 versus 0.518 findings, p=0.69). The specification did not enhance bug-finding effectiveness. However, it provided critical attribution. Baseline reviewers linked 81% of their findings to specific violated requirements, while code-only reviewers attributed 0%, defaulting to vague statements like “something seems incorrect.” This highlights the governance shortfall. Without a baseline, reviewers could not determine whether observed behavior was intentional or not.

Confidence levels improved with the baseline (4.2 versus 3.4, p=0.068), though the additional time, 48 minutes compared to 27 minutes, stemmed from systematically reviewing each invariant. This represents a measurable cost, but one that ensures traceable decision-making. The difference lies between a generic claim of “Together, those artifacts turn the workflow from ‘we reviewed the AI output’ into something that can actually be traced, explained, and audited.”

When “Specify First” Succeeds, and When It Fails

The research demonstrated that execution matters more than the mere presence of a specification. For hard, multi-constraint work, treating the specification as a governing document rather than inline text yielded better outcomes. On easier tasks, the dramatic gains people attribute to “specifying first” are largely a reasoning effect in disguise. If you are going to claim specification prompting improves quality, control for reasoning first.

Specification governance is the best investment in one specific area: hard, multi-constraint work built by a capable-but-imperfect model.