Tech Evolution #6 — a weekly series on where AI in technology actually is, where the data says it's going, and — clearly flagged — what might happen next. Four weeks ago, Code Got Cheap. Trust Didn't. speculated about a specific inversion in how developers spend their time. This week: the data confirming part of it, and what the industry built in response.
In that article I flagged one scenario as speculation and said plainly what would need to be true for it to happen: intent capture would need to get an order of magnitude cheaper, because review was on track to become archaeology — humans reconstructing what code was supposed to do instead of writing it down first. Four weeks later, a fresh developer survey shows the underlying shift already measurable, and eight major AI coding tools have shipped a structural answer to it. Whether that answer solves the problem or just relocates it is the honest question this week.
Where we actually are
Start with the number that changed since last month's article. Digital Applied's Q1 2026 developer survey — 2,847 developers across 320 agencies and in-house teams, fieldwork through March, methodology and sample composition published alongside the data — found developers now spend a median 11.4 hours a week reviewing AI-generated code versus 9.8 hours writing it, reviewing having overtaken writing as the single largest AI-assisted time sink (38% of respondents call it their biggest sink, versus 29% for writing) (Digital Applied, Q1 2026 Developer Survey). Year over year, review time grew four times faster than writing time (+31% vs. +8%). Review-burden climbed six points as a top-three pain point in a single quarter. Write-in responses converged on one of two failure modes when review capacity ran out: teams merged under-reviewed work, or queued pull requests indefinitely — both reported in over a third of long-form answers.
One disclosure this series owes you before that number carries any weight, because it's the same standard applied to the optimistic claims further down: Digital Applied is a marketing agency that sells AI-transformation consulting, the survey was distributed partly through its own client and partner community, and 58% of the sample sits at agencies rather than in-house teams. The methodology and sample composition are published, which is more than most vendor data offers, and the direction is corroborated below by an independently fielded survey. But the specific inversion — 11.4 against 9.8 — rests on one self-published dataset with a commercial interest in the finding, and should be read as a strong signal rather than a settled measurement.
A second, independently fielded survey corroborates the direction if not the exact numbers: Harness's State of Engineering Excellence 2026, based on 700 practitioners across five countries, found 81% now spend more time in code review since their teams adopted AI tools, 28% report that time rising 30% or more, and — the detail that matters most — 94% of engineering leaders say the metrics they actually need are missing from their measurement stack (Harness, State of Engineering Excellence 2026; press release). This sits on top of the Faros AI findings cited here last month — review time up 441%, 31% more PRs merging with zero review — so this isn't a one-quarter blip; it's the same curve, still climbing, now showing up in a second independent dataset.
The industry's answer arrived faster than I expected: spec-driven development. The idea is to make a structured specification — not the prompt, not the code — the primary artifact, with the agent's code treated as a derived, disposable output that gets regenerated when the spec changes. By 2026 every major coding tool shipped its own version: GitHub's Spec Kit, Anthropic's Claude Code, Cursor, and community frameworks like OpenSpec and BMAD on one side; AWS went further with Kiro, a ground-up IDE where specs are first-class objects and feature requests get converted into EARS notation — an aerospace-grade requirements syntax originally built for safety-critical systems (MarkTechPost, SDD tools comparison, May 2026). GitHub's Spec Kit alone sits at 106,332 GitHub stars as of this week, verified directly against the repository — a genuine adoption signal, not a vendor claim. Early adopters report first-pass success rates several times higher on non-trivial tasks, though those figures come from tool vendors and early-adopter write-ups, not controlled studies, and I'd treat them the way this series treats any number nobody independently replicated: directional, not load-bearing.
The trajectory
The rational read: generation didn't get more expensive, but the thing being generated moved. Review time, an argument that was mostly implicit and reconstructed from a diff, is being restructured as a spec — an artifact you can write, version, diff, and argue about before fifty files change. If intent capture really is cheaper to review than code, because it's smaller, more structured, and closer to what the writer actually meant, then spec-driven development compresses the gap this series has been tracking since article #2, rather than just moving it downstream.
That "if" is the whole argument, and the honest evidence against it is already public. Sibylline Software — building with these tools in production, and, in fairness, building a competing structured-spec layer of its own, so the same skepticism this article applies to the optimistic numbers applies here — reports the opposite of the marketing claim: current agents treat specs "more like suggestions," with teams spending real time writing and discussing a spec only to watch the agent follow roughly 70% of what it was told (Sibylline Software, "The Problems with Spec-Driven Development," Jan 2026). If specs are followed at 70% fidelity, the human still has to review the code to catch the missing 30% — the review didn't move, it doubled, because now there's a spec to review too. Separately, developer François Zaninotto's widely discussed critique — "the Waterfall model, which required massive documentation before coding" — landed hard enough to generate a lengthy Hacker News debate about whether SDD is 2026's rediscovery of a 1990s mistake. The honest counter to the Waterfall comparison is real too: unlike Waterfall's phase-gated specs, SDD treats the spec as a living artifact that updates through implementation feedback — the loop is a same-day cycle, not a six-month one. Both things can be true: it's faster than Waterfall, and it can still fail for a Waterfall-shaped reason, which is specs that don't survive contact with what the code actually needs to do.
One more honest limit, because this series doesn't get to invoke regulation loosely: the EU AI Act's heavy compliance-artifact incentive for SDD — the kind of traceability regulators would reward — was deferred by the EU's Digital Omnibus on AI, which reached the statute book in July 2026. High-risk obligations moved off the August 2026 date to 2 December 2027 for standalone Annex III systems and 2 August 2028 for AI embedded in regulated products. What did take effect on August 2, 2026 is narrower: transparency duties, market-surveillance enforcement powers, and the end of the grace period on general-purpose-model enforcement — not the high-risk obligations that would make spec-to-code traceability a near-term legal requirement (Data Protection Report, July 2026; for the pre-deferral view of how uncertain this looked in the spring, Holland & Knight, April 2026). Whatever is pulling adoption toward Spec Kit right now — 106K GitHub stars and climbing — it's the review-time pain measured above, not a regulatory deadline that, for this specific use case, just moved two years out.
What if...
Speculation, clearly flagged. Each scenario needs something specific to be true before it happens.
What if the spec becomes the new pull request — meaning the bottleneck simply relocates and, in a year, this series is writing about "spec review debt" with its own inversion statistic? The Sibylline finding is the leading indicator: if fidelity between spec and implementation stays around 70% instead of climbing toward 95%+, review never leaves, it just moves one layer up and picks up a second artifact to argue about. What would need to be true: fidelity has to be the thing that doesn't improve — everything else about SDD (adoption, tooling, notation) can mature exactly as advertised and this scenario still happens if agents keep treating specs as suggestions rather than contracts.
What if it actually works — because verification, not just generation, gets its own step-change? EARS-style formal notation and automated spec-conformance checking are, in principle, a type system for behavior instead of syntax: something a machine can check without a human reconstructing intent from a diff. If conformance-checking tooling matures on the same curve that made code generation cheap, review compresses for real instead of migrating. What would need to be true: independently verified (not vendor-reported) fidelity numbers well above Sibylline's 70%, and a notation that stays easier for a human to read than the diff it replaces — the same bar TDD had to clear against "just write the code" a generation ago, and did.
What if regulated industries adopt SDD's traceability early anyway, ahead of any legal requirement? The high-risk EU obligations are deferred, but insurers, auditors, and enterprise procurement have a track record of adopting a control before it's legally mandated — SBOMs did exactly this in software supply chain security. A bank or hospital system citing spec-to-code traceability in a security questionnaire eighteen months before the law requires it wouldn't be unprecedented. What would need to be true: one auditor or cyber-insurer starts asking "where's your spec-to-code trace" as a standard question, the way "where's your SBOM" went from unusual to routine in about two years.
What I'm doing about it
I run a fleet of about twenty scheduled agents that research, write, monitor, and publish on their own credentials, every day — this article was one of them. The habit this series described in article #4 — a written mandate before any agent's first task — turns out to already be a form of spec-driven development, just applied to operations instead of code. When I check an agent's run, I don't read its full output the way I'd read a diff line by line. I check it against what its mandate said it would do, and the gap between the two is what gets my attention. That's spec-conformance review, done by one person, across roughly twenty roles instead of twenty thousand pull requests — small enough that I can still tell the difference between "followed the mandate and got a bad result" and "quietly did something else," which is exactly the distinction Sibylline's 70%-fidelity finding says gets lost at software-industry scale.
The honest limit is the same one this article keeps landing on: a written mandate is only as good as how often reality is checked against it instead of assumed to match it. Spec-driven development is a genuine bet on cheaper intent capture. Whether it pays off depends on whether fidelity climbs — and right now, the best evidence says it hasn't yet.
Next week: the field rotates to cybersecurity.
Research home: blackicelabs.ca