Delivery is still breaking down, and the reason is no longer engineering capacity. Timelines slip. Audit evidence gets assembled by hand in the days before a review. Requirements get interpreted one way by the business and another way by engineering. Compliance teams arrive late. Rework absorbs a meaningful share of engineering capacity every quarter, and it is not because engineers are slow.
Before AI-assisted development, this was easy to diagnose. Engineers could not write code fast enough, so capacity was the constraint and the remedy was more of it. That constraint is largely gone. Enterprises are generating code faster than at any point in their history, and the delivery problem has not disappeared. It has changed shape.
The organizations struggling most are not the ones that failed to adopt AI. They are the ones that adopted AI on top of an ungoverned delivery structure. They accelerated the wrong thing. What used to be a capacity problem is now a governance problem: requirements clarity, decision traceability and audit evidence, the parts of delivery that coding tools do not touch.
For banks and insurers, that shift is not an efficiency question. It is a regulatory one. The Digital Operational Resilience Act and the EU AI Act both demand a reconstructable chain from decision to evidence, and when a growing share of the code is machine generated, there is only one artifact in the delivery lifecycle positioned to hold that chain consistently. It is the specification.
AI removed the capacity constraint in software delivery and exposed a governance gap that already existed. Code arrives faster. Requirements clarity, decision traceability and audit evidence do not.
Spec-Driven Delivery treats the specification as a governed operational asset rather than a development document, connecting business intent, delivery, compliance and AI governance through one versioned artifact that stays authoritative from ideation through audit.
For institutions facing the Digital Operational Resilience Act and the EU AI Act, that traceable thread is a compliance requirement rather than a best practice. The leadership decision is whether governance is designed into delivery from sprint one or retrofitted later at roughly three times the cost.
By the numbers
90%
of technology professionals now use AI at work, and more than 80 percent believe it has increased their productivity
– Google Cloud DORA Report, 2025
30%
of those same professionals report little or no trust in the code AI generates
– Google Cloud DORA Report, 2025
66%
of developers name AI output that is almost right, but not quite, as their single biggest frustration, while 33 percent trust the accuracy of AI output and 46 percent actively distrust it
– Stack Overflow Developer Survey, 2025
$2.41T
estimated cost of poor software quality in the United States in a single year, including roughly $1.52 trillion of accumulated technical debt
– CISQ, 2022
4 to 6 wks
of delay per production cycle from rework alone at organizations in the early stages of delivery maturity
– ML arteka delivery readiness data, 2024 to 2026
3x
longer audit preparation than governed peers, and roughly three times the cost to retrofit compliance after delivery rather than design it in
– ML arteka delivery readiness data, 2024 to 2026
Why Is Delivery Still Breaking Down After Code Got Faster?
The capacity constraint is gone. GitHub Copilot, Claude Code, Cursor and a generation of AI coding tools have changed how software gets written, and the volume of code an enterprise can produce is no longer the binding limit on what it can ship.
The failure point has moved in two directions at once. Upstream, to whether business intent survives translation into engineering work. Downstream, to whether anyone can reconstruct, months later, why a decision was made and what evidence supports it. Neither is a coding problem, which is precisely why coding tools do not solve either one.
The industry’s own research says the same thing in different words. Google Cloud’s DORA research programme, whose 2025 State of AI-assisted Software Development report drew on responses from nearly 5,000 technology professionals, found that 90 percent now use AI at work and more than 80 percent believe it has increased their productivity. The same study describes AI’s primary role as that of an amplifier: it magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones. It also reports that higher AI adoption is associated with an increase in both software delivery throughput and software delivery instability.
Adoption is nearly universal. Trust is not.
Confidence has not kept pace with usage, and the two most widely cited surveys do not agree on how far behind it sits. The Google Cloud research reports that 30 percent of professionals have little or no trust in AI-generated code. The Stack Overflow 2025 Developer Survey is harsher on the same question: 33 percent of developers trust the accuracy of AI output while 46 percent actively distrust it, and 66 percent name output that is almost right, but not quite, as their single biggest frustration. That survey also found 84 percent of respondents using or planning to use AI tools, up from 76 percent the year before.
Executives should plan against the wider range rather than the flattering end of it. Both readings point at the same operational reality. Output that is almost right consumes review capacity, and review capacity is governed by how clearly the work was specified in the first place. When the specification is thin, review becomes archaeology.
This is the uncomfortable conclusion. Nothing in the delivery structure broke when AI arrived. The weaknesses were already there. Scarcity of engineering capacity had been hiding them, and removing the scarcity removed the cover.
What Is the Real Cost of Ungoverned Software Delivery?
The cost does not show up as slow engineering. It shows up as rework, slipped timelines, and audits that are delayed or failed. Across delivery readiness assessments with mid-sized and large enterprises, four governance gaps consistently drive the most lost velocity, the lowest compliance confidence and the least predictable delivery.
| Governance gap | What goes wrong, and what it costs downstream |
|---|---|
| Requirements clarity | Business intent does not survive translation into engineering work. Teams build what they interpreted, not what was intended. |
| Delivery governance | Decisions are made informally and inconsistently, without traceability. Months later, no one can reconstruct why the choices were made. |
| Compliance and traceability | Evidence is assembled after the fact rather than built into the pipeline. Audit preparation becomes a project of its own. |
| Team alignment | Engineering and the business run on different information. Gaps surface only at a milestone or a review. |
These gaps are measurable. Organizations at early delivery maturity face four to six weeks of delay per production cycle from rework alone, and audit preparation takes roughly three times longer than at governed organizations. In assessment after assessment, the constraint is rarely the AI tooling itself. It is the ungoverned requirements and delivery structure underneath it.
The macro number is consistent with what leaders see inside their own portfolios. The Consortium for Information and Software Quality put the cost of poor software quality in the United States at $2.41 trillion in 2022, including roughly $1.52 trillion of accumulated technical debt, which it defines as the cost of reworking suboptimal software. Very little of that total is a coding skill problem.
The irony is that the organizations investing most heavily in AI tooling often feel this most acutely. Velocity increases. Governance does not keep pace. The gap compounds every quarter, and it consumes the very capacity the tooling was supposed to release.
What Is Spec-Driven Delivery, and How Is It Different?
Spec-Driven Delivery (SDD) is an enterprise governance framework that treats the specification as a governed operational asset rather than a development document. It connects business intent, delivery, compliance and AI governance through a single versioned artifact, creating a traceable thread from business intent to audit-ready evidence across the entire delivery lifecycle.
Traditional spec-driven development has always had a clear, useful, but narrow scope: write better specifications, produce better software, write better tests. It is an engineering discipline. Spec-Driven Delivery repositions the specification from a development input into an enterprise operational asset.
| Dimension | The shift from spec-driven development to Spec-Driven Delivery |
|---|---|
| Optimizes for | From software creation to enterprise delivery outcomes |
| The spec is | From a development input to a governed operational asset |
| Pipeline | From spec, code, tests, velocity and software, to business alignment, governance, traceability, compliance and outcomes |
| Lifespan of the spec | From informing one sprint and being superseded, to a living source of truth from ideation through audit |
| Compliance evidence | From assembled after the fact, to a by-product of how delivery is structured |
| Who it serves | From engineers, to every stakeholder, human and AI |
Here is the distinction that matters. A specification, as most organizations use it today, does one job: it tells engineers what to build. It lives in a ticket, a wiki page or a requirements document. It informs a sprint, then gets superseded by whatever the team actually shipped.
That model worked when software was slower to produce. It does not work when implementation can be generated in minutes. The moment delivery velocity outpaces the governance model’s ability to keep up, risk accumulates faster than it can be managed. Nothing in the sprint ritual catches that, because the sprint was never the control.
One Specification, Five Roles
Under Spec-Driven Delivery, the specification does five jobs at the same time. That is what separates it from a document written before a sprint and forgotten by the end of one.
| As a | The specification defines |
|---|---|
| Business artifact | What outcome the organization is investing in, and how success is measured |
| Governance artifact | What decisions were made, by whom, and under what authority |
| Compliance artifact | What controls apply, what evidence is required, and how it is maintained |
| Delivery artifact | What gets built, how it connects to business intent, and what done means |
| AI artifact | The explicit, versioned instruction set that governs what AI generates, and what it does not |
A specification that carries all five roles becomes the shared source of truth for every stakeholder, human and AI, from ideation through audit.
The artifact does not change. Its standing does. It stops being a document someone writes and starts being an asset someone owns, versions and answers for. That is the practical difference between organizations that scale AI-assisted delivery with confidence and organizations that scale it chaotically.
Every major vendor and consultancy is racing to position in the AI-era delivery conversation, and the message is consistent: move faster, automate more, deploy AI tooling broadly. IBM frames it as enterprise transformation. Thoughtworks talks about engineering culture and the cognitive debt that accumulates when AI-generated code goes unreviewed and untraced. Endava and GFT compete on delivery execution and nearshore capacity. Accenture and KPMG lead with digital strategy and risk management. GitHub and Microsoft lead with developer velocity and toolchain integration.
The connective layer between all of those conversations is largely unclaimed. It is the layer where business intent becomes governed requirements, governed requirements become traceable delivery, and traceable delivery becomes audit-ready evidence that doubles as the instruction set AI needs to perform reliably at enterprise scale. That layer is the specification, and it is where most enterprise delivery breaks down.
Why the Stakes Are Highest in Financial Services
For banks, insurers and capital markets firms, ungoverned AI delivery is a question of regulatory exposure rather than engineering hygiene. Two converging regimes turn a traceable, audit-ready specification from a good practice into a compliance requirement.
- The Digital Operational Resilience Act (Regulation (EU) 2022/2554) has applied to EU financial entities since 17 January 2025, covering roughly 22,000 institutions and their critical ICT providers. Its five pillars carry penalties of up to 10 percent of annual turnover or €10 million for serious breaches. In January 2026, Germany’s BaFin clarified that AI systems must be embedded directly into compliant ICT risk management frameworks rather than governed as a separate regime.
- The EU AI Act (Regulation (EU) 2024/1689) brings hard obligations for high-risk AI systems, including creditworthiness assessment and insurance pricing, with a key deadline of 2 August 2026. Requirements include documented risk management, bias-assessed training data, immutable audit logs and human oversight on consequential decisions.
- In the United States, the same logic runs through model risk management guidance (SR 11-7), SOC 2, PCI-DSS and SOX, all of which demand a defensible, reconstructable chain from decision to evidence.
The common thread across every one of these regimes is exactly what Spec-Driven Delivery produces: a traceable, versioned record of what was decided, why, by whom and what controls applied, from business intent through to deployed code. When AI is writing a growing share of that code, the specification is the only place that record can live consistently.
A note on two DORAs
The acronym collision matters in board papers, so it is worth stating plainly. The Digital Operational Resilience Act is EU financial regulation. The DORA research cited earlier in this article is Google Cloud’s long-running study of software delivery performance. They share four letters and nothing else. Confusing them in a committee pack is an avoidable way to lose an argument.
The practical implication for a regulated institution is sequencing. Deadlines are fixed and public. Specification discipline takes quarters to establish. An institution that begins building the governed thread only when an examiner asks for it has already chosen the expensive path.
How Does the Spec-Driven Delivery Framework Work?
The framework rests on a straightforward premise: the specification is an operational asset, not a documentation task. In practice, it connects four stages of enterprise delivery through a single governed artifact.
- Business intent, stated as the outcome the organization is investing in and how success will be measured.
- Governed requirements, versioned and explicit, agreed before implementation begins.
- Traceable delivery, where every decision links back to a requirement and forward to the change it produced.
- Audit evidence, generated as a by-product of the first three stages rather than assembled before a review.
This thread is what most enterprises are missing. Not the code, and not the AI tools. The governed connection that runs through every stage and makes the delivery pipeline accountable.
Four operating commitments
- Governance from sprint one, not sprint twenty. Requirements, traceability and team alignment are built into the delivery model before a line of code is written. Not retrofitted during audit preparation, and not assembled manually before a compliance review.
- Compliance by design, not by assembly. Audit evidence is a by-product of how delivery is structured. Organizations operating this way do not prepare for audits. They arrive at audits with traceability already in place.
- AI-ready specifications. The quality of AI output is directly tied to the quality of the instruction set governing it. Organizations with strong specification discipline extract reliably more value from AI tooling, because the AI is governed rather than merely prompted.
- Measurable maturity progression. Delivery is scored across six dimensions against enterprise peer benchmarks, so improvement is a tracked, documented shift in operational readiness rather than an abstract claim.
| Delivery dimension | The question it answers |
|---|---|
| Requirements clarity | Does business intent survive translation into engineering work? |
| Delivery governance | Can we reconstruct who decided what, and under what authority? |
| Compliance and traceability | Is audit evidence produced by delivery, or assembled before a review? |
| Team alignment and readiness | Do the business and engineering run on the same source of truth? |
| Build and release confidence | Can we ship without heroics and roll back without drama? |
| QA maturity | Is quality designed in, or inspected at the end? |
ML arteka’s position is that delivery governance has become a board-level control rather than an engineering preference.
In the assessments behind this article, the organizations struggling with AI-assisted delivery were rarely short of talent or tooling. They were short of an agreed, versioned statement of what they were building and why, and short of a named owner for it. Once that statement exists and is owned, AI becomes a force multiplier on a governed system instead of an accelerant on an ungoverned one. The order of operations is the whole argument: specify, govern, then scale.
Three Moves from Ungoverned to Operationalized Delivery
Organizations at early delivery maturity, what we call the Emerging stage, have delivery practices that exist but break down under pressure. Engineering effort is dominated by reactive problem solving. Governance is informal. Audit preparation becomes a project of its own.
Moving to Operationalized delivery, where governance is built into the pipeline end to end, requires three moves that no AI tool alone provides.
- Govern requirements before they become code. Make the specification the explicit, versioned contract between the business and engineering, established before implementation begins. This closes the requirements clarity and delivery governance gaps at the same time, and it eliminates the rework cycle at its source rather than managing it after the fact.
- Build traceability into the delivery pipeline, not onto it. Compliance and traceability are architecture decisions. Retrofitting compliance after delivery costs roughly three times more than designing it in from day one, according to ML arteka delivery assessment data. The governance layer must be established at the point of design, not assembled manually before an audit.
- Align teams on outcomes, not tickets. When engineering and the business share the same specification as the source of truth, with shared objectives, shared metrics and shared accountability, alignment stops being a recurring problem to solve. It becomes structural.
Organizations that complete this progression consistently report shorter production cycles, faster audit preparation, and AI tooling that performs more reliably, because the instruction set governing what AI generates is itself governed.
Where the external research and the delivery data converge
If AI amplifies what already exists, as Google Cloud’s 2025 research concludes, then the highest-return investment is not another tool licence. It is the quality of the thing being amplified. That reframes the budget conversation. Spending on specification discipline looks like overhead on a line item and behaves like leverage on the portfolio.
It also reframes the sequencing question every technology leader is currently facing. The right order is not adopt, then govern. It is govern enough to make adoption safe, then scale adoption as fast as the governance can carry it. In a regulated institution, that is not caution. It is the only version of speed that survives a review.
Five Leadership Takeaways
Before your next delivery governance review. Before your next expansion of AI tooling licences.
- AI did not create the gap. It removed the cover. Requirements clarity, decision traceability and audit evidence were already weak. Capacity constraints hid the weakness. Faster code exposed it.
- Treat the specification as an owned asset. A spec that carries business, governance, compliance, delivery and AI roles has a version, an owner and a lifespan. A spec that informs one sprint has none of those.
- Governance designed in beats governance retrofitted. Retrofitting compliance after delivery costs roughly three times more than building it in from day one, and audit preparation runs about three times longer at ungoverned organizations.
- Trust in AI output lags adoption badly. Around 90 percent of technology professionals use AI at work, yet 30 percent report little or no trust in the code it generates and 66 percent cite output that is almost right as their biggest frustration. Review capacity absorbs the difference.
- In financial services, traceability is the regulation. The Digital Operational Resilience Act and the EU AI Act both demand a reconstructable chain from decision to evidence. The specification is the only artifact positioned to hold it.
The Delivery Governance Category That Is Still Open
IBM will talk about enterprise transformation. Accenture will talk about digital strategy. Thoughtworks will talk about engineering culture and modernization. GitHub will talk about developer velocity. Almost every engineering conversation in 2026 will be about AI code generation. Very few will be about spec-driven governance, spec-driven compliance, spec-driven auditability, or the work of operationalizing AI-assisted development inside an accountable framework.
That is the gap, and it is a leadership gap before it is a technical one. Code generation is a procurement decision. Delivery governance is an operating model decision, and it belongs to the executive who owns the delivery outcome, not to the team that owns the toolchain.
The recommendation is unglamorous and durable. Before expanding AI tooling any further, establish who owns the specification, which version of it is authoritative, and how evidence flows from it into the audit record. Score the six delivery dimensions honestly. Fix requirements clarity and delivery governance first, because compliance traceability, team alignment, release confidence and QA maturity all depend on having an authoritative specification to point at.
The window is still open. Regulatory deadlines are converging, AI adoption is close to universal, and the governance layer remains largely unbuilt. Institutions that close this gap in the next few quarters will scale AI-assisted delivery with confidence. Those that do not will spend the following years managing the compounding cost of ungoverned acceleration, and paying for it out of the capacity the tools were supposed to free.
Knowing where you stand is the first move. To pressure test your delivery governance against enterprise peer benchmarks, contact the ML arteka team or request a delivery readiness assessment scored across the six dimensions and delivered as a board-ready executive report.
Executive Questions and Answers
Five questions financial services technology and risk leaders are asking AI assistants and search engines about Spec-Driven Delivery and AI governance.
StrategicWhat is Spec-Driven Delivery and why does it matter now?
Spec-Driven Delivery is an enterprise governance framework that treats the specification as a governed operational asset rather than a development document. It connects business intent, engineering delivery, compliance requirements and AI governance through a single versioned artifact that stays authoritative from ideation through audit. It matters now because AI removed the capacity constraint on writing code. With around 90 percent of technology professionals using AI at work, according to Google Cloud’s 2025 DORA research, the binding constraint has moved upstream to requirements clarity and downstream to decision traceability and audit evidence. Those are the parts of delivery that coding tools do not touch, and in regulated industries they are exactly the parts an examiner asks about.
OperationalHow does Spec-Driven Delivery work alongside Agile, Scrum or SAFe?
Traditional methodologies govern the process of delivery. Spec-Driven Delivery governs the content and the accountability of delivery, so it works alongside an existing methodology rather than replacing it. Agile ceremonies still set cadence. Scrum still manages the sprint. What changes is that requirements, traceability and governance artifacts become explicit, versioned and structured from the start, instead of being managed as separate workstreams or reconstructed before an audit. In practice, teams keep their board and their stand-up, and the specification becomes the contract the board and the stand-up refer back to. The main adjustment is upstream discipline: agreeing what is being built, and why, before implementation begins.
GovernanceHow do we govern AI-generated code so it holds up in an audit?
Start by accepting that governing the output is harder than governing the input, so the practical control is the instruction set. Make the specification the explicit, versioned statement of what AI is permitted to generate and what it is not. Then require every generated change to trace back to a requirement in that specification and forward to the evidence it produced. That gives a reviewer the reconstructable chain that model risk management guidance, SOC 2 and the EU AI Act all expect, without a manual evidence exercise before each review. It also addresses the trust problem the research keeps surfacing: 30 percent of professionals report little or no trust in AI-generated code, and human review capacity is what absorbs the difference.
RiskWhat is the risk of scaling AI coding tools before delivery governance is in place?
The risk is that you accelerate an ungoverned system. Google Cloud’s 2025 DORA research describes AI as an amplifier that magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones, and it found higher AI adoption associated with an increase in both software delivery throughput and software delivery instability. In a regulated institution, instability is not only an outage. It is an audit finding. Unspecified requirements become assumptions, assumptions become undocumented dependencies, and undocumented dependencies surface as production incidents, rework cycles and failed reviews. That consumes the very capacity the tooling was meant to free, and the exposure compounds every quarter it goes unaddressed.
ImplementationHow long does it take to move from Emerging to Operationalized delivery maturity?
It depends on where the gaps are concentrated, but organizations that engage with a structured Spec-Driven Delivery framework typically see measurable movement in their dimension scores within the first two to three quarters. The key variable is whether governance is being retrofitted onto an existing delivery model or built into a new one from the start. The latter is significantly faster and less expensive, since retrofitting compliance after delivery costs roughly three times more than designing it in. Sequence matters as much as effort. Requirements clarity and delivery governance should move first, because compliance traceability, team alignment, release confidence and QA maturity all depend on having an authoritative specification to reference.
Spec-Driven Delivery (SDD) is an enterprise governance framework, developed by ML arteka, that treats the software specification as a governed operational asset rather than a development document. It connects business intent, engineering delivery, compliance and AI governance through a single versioned artifact, producing a traceable thread from business intent to audit-ready evidence. The central argument is that AI did not create the enterprise delivery problem; it exposed one that already existed in how organizations translate intent into delivery. Google Cloud’s 2025 DORA State of AI-assisted Software Development report, based on responses from nearly 5,000 technology professionals, found 90 percent use AI at work and more than 80 percent report productivity gains, yet 30 percent have little or no trust in AI-generated code, and it characterises AI as an amplifier of existing strengths and dysfunctions. The Stack Overflow 2025 Developer Survey found 84 percent use or plan to use AI tools, 33 percent trust output accuracy against 46 percent who distrust it, and 66 percent cite output that is almost right, but not quite, as their top frustration. CISQ estimated the cost of poor software quality in the United States at $2.41 trillion in 2022, including $1.52 trillion of accumulated technical debt. Under SDD the specification serves five roles at once: business, governance, compliance, delivery and AI instruction set. For financial institutions subject to the Digital Operational Resilience Act (EU 2022/2554) and the EU AI Act (EU 2024/1689), that traceable record is a compliance requirement rather than a best practice.