Have We Wrapped Our Heads Around GenAI's Impact on Software Roadmaps?
- Published Date:
I’ve sat in planning sessions where output was visibly up and it seemed reasonable to plan for more. What recent research has made harder to ignore is that the multiplier was never the interesting part.
The gains are uneven. Routine and greenfield work can accelerate sharply; complex legacy and integration work moves far less. So the effect isn’t simply that more fits into a quarter — the relative economics of the backlog have changed, and the backlog may need re-ranking.
At the same time, faster implementation removes friction that used to expose vague requirements. Ambiguity no longer necessarily slows us down. It can move quickly and consistently into the code, the tests, and the review artifacts.
And as more functionality arrives per unit of development effort, estimating test effort as a percentage of development effort becomes steadily less reliable.
The roadmap question isn’t “how much more can we deliver?” It’s: what happens when development effort stops being a reliable proxy for the things we actually need to plan?
1. The ranking moved, not just the capacity
Every prioritisation framework we use — RICE, WSJF, value-versus-effort — puts effort in the denominator or on one axis, and the roadmap is that ranking laid against a calendar. Which matters, because the gains are bimodal. McKinsey’s study of 4,500 developers across 150 enterprises found roughly 46% less time on routine tasks but under 10% on high-complexity work [1]. Stanford’s research found 35–40% gains on simple greenfield tasks and often 10% or less on complex legacy code [2].
If effort fell 46% for one class of work and 8% for another, the ordering of our backlog changed — independently of total capacity. Items that sat below the line because they were expensive relative to their value may now clear it. Items we kept prioritised partly because they felt cheap may not have moved at all.
The instinct, mine included, is to adjust how much fits into a quarter. Re-running the ordering is the less obvious move and probably the more valuable one, since capacity adjustments are estimates whereas re-ranking is a decision about value.
For those of us in regulated industries — healthcare, banking, financial services — re-ranking may reveal less movement than headline productivity figures imply, because more of the portfolio sits in the slow-moving class.
2. Requirements clarity has never mattered more
When code was expensive, the cost of iteration braked vague requirements. Someone would hit the ambiguity while building and come back to ask. That friction was doing quiet quality work on our behalf.
Remove the friction and the ambiguity isn’t caught. It gets implemented.
This isn’t a marginal shift in emphasis. DORA’s 2026 research frames it as a relocation of the bottleneck: as AI accelerates code generation, the constraint moves to specification and verification, and specifications stop being overhead relative to implementation. They become the scarce resource [2][4].
Survey evidence points the same way. In DeviQA’s 2026 survey of 300 QA practitioners, 42% named non-compliance with requirements among the defect categories they most often encounter in AI-generated code — third, behind logical errors (58%) and unhandled edge cases (52%) [5]. Respondents described the mechanism plainly: the tooling produces precisely what the ticket says, leaving someone downstream to work out what should have been specified but wasn’t.
A peer-reviewed 2026 paper on spec-driven development puts the causal claim simply: specifications improve output quality because they remove the ambiguity that otherwise forces a model to guess [6]. Microsoft’s engineering guidance reaches the same conclusion from practice — that clarity established early usually reduces total delivery time, and that outcome quality is closely tied to spec quality [7].
The connection I’d most want to draw out is this. Practitioner accounts of AI-assisted delivery name unverifiable output as a distinct failure mode: without explicit acceptance criteria, there is no way to establish whether generated code is right, so reviews become endless [8].
That is worth sitting with, because it means specification quality sets a ceiling on what any downstream verification can achieve. Validation runs against intent. If intent was never written down, the reviewer or QA engineer has nothing to validate against and is reduced to inferring what should have been built — which is precisely what DeviQA’s respondents described [5].
So the two problems aren’t siblings. Weak requirements don’t only produce wrong code; they disable the mechanism we would otherwise rely on to catch it.
DeviQA’s respondents described setups where the same model writes the ticket, writes the code, generates the tests, and reviews the pull request [5].
Several reported this working well on small, well-scoped issues. What it removes is independent verification. The disagreements between different authors — the tester who reads the acceptance criteria differently from the developer — were doing real defect detection at the specification-to-implementation boundary. When one author holds all four roles, an ambiguity isn’t caught. It propagates consistently through every artifact, and every gate agrees.
The obvious objection
If specifications matter more, are we not simply reinventing big upfront design? It’s a fair challenge, and one the practitioner community is actively making — at least one widely-read 2026 critique argues spec-driven development is largely contract-design rebranded, and that the value lies in the thinking done while writing the spec rather than in any tooling around it [9]. Thoughtworks places the practice in the “assess” category rather than “adopt,” and explicitly rejects the view that specifications alone suffice [10].
Two things make the current situation different from waterfall, though.
First, specification authoring is itself becoming cheaper. Early studies of generating structured acceptance criteria from natural-language tickets report meaningful time savings per feature, with generation completing in minutes [4]. The upfront investment is not what it was in 2005.
Second, the compliance case has hardened independently. Specifications are increasingly treated as evidence rather than documentation, and high-risk obligations under the EU AI Act came into effect in August 2026 [11]. For those of us delivering into healthcare and financial services, traceability from requirement to test to release is becoming a contractual artifact rather than an internal good practice.
There’s also early evidence that constraining generation at the specification layer works better than inspecting output afterwards. A 2026 case study on a banking microservices application reported a 73% reduction in security defects when non-negotiable constraints were encoded into the specification, compared with unconstrained generation [12]. That’s a single case study and should be read as such — but the direction is consistent with everything above.
The practical consequence for planning: specification effort becomes a visible line item rather than assumed overhead, and discovery capacity, not engineering capacity, may now govern roadmap velocity. Accelerating build while leaving discovery staffed as it was puts a faster engine behind the same narrow intake.
3. Development effort has stopped being a proxy for test effort
Many of us have estimated test effort as a ratio of development effort, with figures between 25% and 40% widely cited [13]. Test effort doesn’t actually scale with development effort — it scales with scope delivered, regression surface, and risk. Development effort was only ever a rough proxy for scope.
Practitioners said so long before AI. Prolifics Testing argued in 2023 that no universal formula derives tester count from developer count, noting that two projects with identical requirements can differ enormously in test effort depending on implementation quality and unit-test discipline — the better-built one needing less testing [14]. The ratio persists most stubbornly in fixed-bid work, client SOWs, and services estimation — which is where many of us live.
So the ratio held approximately, because development effort and scope delivered moved together.
The proxy broke. Development effort no longer tracks scope delivered. LinearB’s analysis of 8.1 million pull requests across 4,800 organisations found AI-adopting teams merging 98% more pull requests, with developers completing 21% more tasks [15]. More scope arrives per unit of development effort, so a percentage of that effort under-provisions testing by construction.
Test effort per unit of scope may be rising. Separately, the same volume of functionality appears to demand more verification than before — higher defect density, regression surfacing outside the change boundary, and an additional validation layer over generated artifacts.
Either change alone would weaken the ratio. Together they break it in both directions, so the error compounds rather than cancelling.
The tempting conclusion is that testing got cheaper too, because AI generates test cases and scripts. Authoring did get cheaper. But that treats QA as one activity when it’s three, in this order:
Authoring test cases and scripts — genuinely cheaper now.
Validating them before they are trusted to run — harder than before, and requiring more senior judgment than authoring ever did.
Executing them — already automated, already cheap.
That middle activity is where responsibility now concentrates, and it’s precisely what percentage-based estimating renders invisible. Four reasons it resists automation:
A test generated from an implementation confirms the implementation. If the code misread the requirement, tests derived from that code assert that it does exactly what it does. They pass. Nothing looks wrong. This is why validation has to run against intent — and why it fails entirely when intent was never specified.
Happy-path bias is well documented. DeviQA’s respondents consistently described AI handling the primary path competently and missing what sits adjacent — boundary values, negative scenarios, non-standard flows [5]. That work moved from the writing stage to the testing stage.
The regression surface can widen beyond what the diff suggests. The most consistent qualitative pattern in the survey was defects surfacing where the change did not appear to touch [5]. Where a narrow diff once justified smoke testing, respondents described running full regression.
Accountability didn’t move. When a QA engineer signs off, they own that judgment, whether the test was written by a person or generated. The volume of artifacts to validate went up. The accountability attached to each sign-off did not.
From the same survey of 300 QA practitioners [5]: 52% report bug volume has increased against 2% reporting a decrease, 58% report their own testing workload has grown, and no respondent described QA headcount being added in response.
The defect signature landing on QA — logical errors, unhandled edge cases, requirements mismatches — is dominated by categories that pass linters and compilation and surface only under structured testing or in production.
A note on this source: DeviQA is a QA outsourcing vendor with a commercial interest in the conclusion. Their methodology and data gaps are disclosed in the report. I’d treat the figures as directional.
What test estimation might be based on instead
There’s no clean replacement ratio, and I’d be sceptical of anyone offering one. What seems more defensible is estimating from the drivers that actually move test effort:
- Regression surface — the blast radius of the change, rather than the size of the diff.
- Requirement ambiguity — the less precisely specified an item is, the more validation it generates downstream.
- Criticality tier — compliance-adjacent surfaces carry validation requirements that don’t scale down with development effort.
- Volume of generated artifacts requiring review — a real input with no equivalent in the old model.
- Independence requirement — whether an item needs a verifier who authored neither the code nor the tests.
4. What we’d need to measure
Most engineering measurement was designed for a period when development effort was the planning currency, so it counts activity at the authoring stage and infers the rest. Gartner published a metrics set in July 2026 that reads as an attempt at a replacement panel [16]. Their framing point matters as much as the list: selecting outcome metrics is the product owner’s or product manager’s job, because those metrics must align to product and business objectives to close the loop back to value.
Five of their measures earn a place in a roadmap conversation:
- AI code share — the proportion of committed code that is AI-generated, framed as the baseline needed to interpret any throughput number. Roughly 19% of QA respondents couldn’t say whether the code they were testing was AI-generated [5]; without this signal, most of the questions below are unanswerable.
- Cycle-time acceleration — percentage reduction against a pre-AI baseline over 30-day windows. The discipline is in forcing an explicit baseline rather than a remembered impression.
- AI code durability — the share of AI-written code still standing after 30 or 90 days without being patched, reverted, or substantially rewritten.
- Change failure rate — the quality headroom we have before adding scope.
- Technical debt levels — maintained as a working list teams add to and draw down, representing accumulated rework and deferred maintenance.
Durability and technical debt are the two I’d most want visible in planning. GitClear’s 2026 research across 623 million changed lines found duplication rising sharply and refactoring falling to 3.8% of changed lines, from 21% in 2022 [3] — deferred work that doesn’t disappear, but resurfaces later as roadmap items nobody planned for. These two measures are the closest thing on this list to an early warning.
This is licensed Gartner research, summarised and paraphrased. Anyone quoting it directly should check their own entitlement.
Six questions for the next planning session
- Have we re-ranked the backlog, or merely increased quarterly capacity?
- Is specification readiness a condition for entering delivery — and is that effort visible in the estimate?
- Is discovery capacity keeping pace with build capacity?
- Does any verification gate have an author independent of the code and tests?
- Are we estimating testing from risk, ambiguity, and regression surface rather than development effort?
- Are we measuring code durability, change failure, and deferred maintenance — not just throughput?
Where I’ve landed, provisionally
The pattern underneath all of this is the same. AI compressed the authoring of things — code, tickets, test cases — and left the judgment about whether those things are right roughly where it was, while increasing how much of it is required.
Development effort worked as a planning currency because it correlated with that judgment. It bought us a ranking, an ambiguity signal, and a test estimate more or less for free. That correlation has weakened, and the work now is to buy those three things deliberately and separately.
If I had to pick one place to start, it would be the requirements end rather than the testing end. Not because verification matters less, but because everything downstream inherits whatever ambiguity we leave upstream — and no amount of validation rigour recovers a specification that was never written.
I’d value hearing how others are handling this, particularly the test estimation question. It’s where I’m least confident anyone has a good answer yet.
Amit Saini
CTO
Amit has over 20 years of professional experience with more than 15 years on Product Development and management. Rich experience of building enterprise products from grounds up – Data Management and Analytics Platform, Sales Operations Cloud, Business Rules Engine, B2B Integration products – cloud and on premise, Business Process Manager and Server Side Security management software.
- McKinsey & Company, study of 4,500 developers across 150 enterprises. Reached via secondary reporting.
- DORA / Google Cloud, The ROI of AI-Assisted Software Development (2026), including the Stanford Software Engineering Productivity figures. dora.dev/ai/roi/report/
- GitClear, The Maintainability Gap: 2026 AI Code Quality Research (623M changed lines).
- The Specification as Quality Gate: Three Hypotheses on AI-Assisted Code Review (arXiv, 2026), summarising DORA 2026 on the specification bottleneck and citing Fonseca et al. (arXiv:2510.18861) and Hassani et al. (arXiv:2508.20744) on generated acceptance criteria.
- DeviQA, State of AI-Generated Code 2026: The QA and Testing Gap (July 2026) — proprietary survey of 300 QA engineers, SDETs, and test leads. Vendor research; methodology and data gaps disclosed in the report.
- Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants, AIWare 2026 (ACM).
- Microsoft for Developers, Spec-Driven Development: A Spec-First Approach to AI-Native Engineering (June 2026).
- Practitioner field guides to spec-driven development (2026), on intent drift, context decay, and unverifiable output as distinct failure modes. Secondary.
- B. Kindred, Same Patterns, New Hype (2026), critiquing SDD as contract design rebranded. Secondary.
- Thoughtworks, on spec-driven development and the continued primacy of executable code.
- EU AI Act, high-risk system obligations effective August 2026.
- S. R. Marri, Constitutional Spec-Driven Development: Enforcing Security by Construction in AI-Assisted Code Generation (arXiv, January 2026). Single case study; directional only.
- Commonly cited percentage-of-development test estimation rules of thumb. Practitioner heuristics, not research findings.
- Prolifics Testing, Optimal Tester to Developer Ratios (2023). Pre-dates the current AI estimation discussion.
- LinearB, 2026 Software Engineering Benchmarks Report (8.1M pull requests, 4,800 organisations, 42 countries).
- Gartner, The Impact of AI on Software Engineering Metrics, 2 July 2026 (G00850799). Licensed research; summarised and paraphrased rather than reproduced.
Explore the Latest
Discover trends and strategies shaping smarter, faster business processes.
