Control for reasoning before you credit spec-first prompting for the quality gain

Review here happens clause by clause, each layer checked against its own spec fragment rather than the document as a whole. A specification in this study carries three layers: the business requirements and rules, a high-level design that names the components and their interfaces, and a low-level design that pins the concrete invariants each method must uphold ^[10]. Take the money-transfer example. The business rule is that a transfer must never leave an account balance negative ^[11]. The HLD turns that into a TransferService interface with a transfer operation over from, to and amount ^[12]. The LLD makes the same rule checkable: reject the transfer and emit no ledger entry when amount exceeds available balance ^[13]. That last clause is what a reviewer later diffs the generated code against ^[14].

So one business rule turns into three clauses that all need to be written, agreed on, and kept synchronized over time ^[19]. That cost lands before anything is generated, and it is the kind of overhead that is easier to justify after an incident than before one.

What the baseline buys is narrower than the usual pitch. Reviewers working against a spec caught the same number of bugs. What changed was the catch itself: each bug became contract-anchored and attributable, with higher confidence, at a measurable time and cost ^[2]. The deliverable is the answer to which approved clause the code violated. That matters because the article's framing is that "we review the output carefully" provides little evidence of how controls are actually implemented ^[18], against EU AI Act high-risk duties for risk management, record-keeping and meaningful human oversight ^[15], ISO/IEC 42001's documented AI management system with controls and audit trails ^[16], and the NIST AI Risk Management Framework's Govern, Map, Measure and Manage structure ^[17].

The finding that should change how you read a spec-first demo is the reasoning confound. On easier tasks, the dramatic gains people attribute to specifying first are largely a reasoning effect in disguise, and the author's instruction is to control for reasoning before claiming specification prompting improves quality ^[4]. For such a number to transfer to your codebase, the comparison has to hold reasoning effort constant across both arms, the task has to be hard enough to carry multiple interacting constraints, and the model has to be capable but imperfect, which is the one area where the author puts the payoff ^[4][5]. Skip the first condition and what you measured is a longer prompt.

The mechanism credited with moving the outcome is a process boundary. The spec is authored, then implementation happens in a fresh generation step, so the spec governs rather than sitting inline in the prompt text ^[3]. That is a testable claim about session structure, and it is cheap to try against your current setup.

The evidence is thin by the author's own account: accepted at GAISS 2026, preliminary and directional, small samples, a few tasks ^[6]. The published takeaways and opening sections give no effect sizes, no review-time figures and no sample counts ^[20]. "Measurable time and cost" is therefore a direction, not a price, and anyone budgeting spec governance is still estimating the overhead themselves.

Read that against the backdrop the article describes: in 2026 most engineering teams use coding assistants weekly, AI authors a large and rising share of production code, and the bottleneck has moved from writing to verification ^[8][7]. Controlled studies report real productivity gains alongside slowdowns and quality problems under production conditions, with AI-generated code reaching production carrying security weaknesses, familiar bug patterns and quiet behavioral drift ^[9]. On a CRUD endpoint, buy the reasoning and skip the three layers. On a settlement path with interacting invariants, the layers are what turns review into something you can hand to an auditor ^[5][18].