AI removed one constraint and exposed the others
EY-Parthenon, EY's strategy consulting brand, worked with the survey platform Potloc and interviewed 400 chief technology officers (CTOs) of software companies headquartered in 13 European countries. The results are published as Beyond the code: How AI is redefining the software industry (2026). The UK, Germany and France account for just over half of the sample.
One question asked CTOs to rank the three biggest constraints in their software development lifecycle (SDLC). Coding came seventh.
| SDLC stage | Ranked in top three |
|---|---|
| Quality assurance (QA) and validation | 54% |
| Architecture and context-setting | 39% |
| Security and compliance review | 38% |
| Requirements and specifications | 36% |
| Code review | 32% |
| Test generation and test maintenance | 24% |
| Coding and implementation | 22% |
Source: EY-Parthenon and Potloc CTO survey, report pages 18-19. These are self-reported rankings from European CTOs, not measured throughput. Still, 78% of these CTOs left coding out of their top three.
What are the biggest software development constraints with AI?
According to EY-Parthenon's 2026 survey of 400 European software CTOs, the biggest constraints are now downstream of coding. Quality assurance and validation lead, followed by architecture and context-setting, then security and compliance review. Coding and implementation ranks below all three.
The report's own heading for that page:
"AI didn’t remove the bottleneck — it pushed it downstream"
Why AI moves the constraint downstream
The survey shows where the freed capacity goes. 56% of CTOs say they redeploy time saved by AI coding tools into quality assurance and code review. 55% put it into new features. Among CTOs who measure it, 84% say delivery lead time and release cadence improved.
Quality has not kept pace. Among those who measure it, 60% report no material change in escaped defects (bugs found after release) and production incidents. When generation gets faster and checking does not, work queues at the checking stage. We covered the queueing mechanics in Why Code Review Cannot Scale With AI Output. EY's data is the survey-level version of the same effect.
Architecture and context are now production constraints
Test suites and security scanners serve the first and third constraints. The second has far less tooling. We read "architecture and context-setting" as telling the people and agents doing the work what the system is supposed to look like: which boundaries hold, which libraries were ruled out, which decisions are still current.
Coding agents make this harder, not easier. An agent can retrieve ten documents that mention a database and still not know which decision is in force. More context is not the same as authoritative context. That gap is the subject of Memory Is Not Governance.
The report's view of competition points the same way. In its words: "The construction of the software code is becoming replicable. The context around it is not." Boards see it too. 44% of CTOs say investors and boards treat architecture and data foundations that absorb new AI use cases without rework as strong evidence of AI advantage.
Human review cannot be the whole control system
EY asked which practices teams use to keep AI-generated code reliable, maintainable and secure:
| Practice | In use |
|---|---|
| Mandatory human review before merge | 62% |
| Static code analysis or security scanning | 45% |
| AI-specific coding policies or standards | 41% |
| Approved AI tool list | 36% |
| Data privacy and compliance checks | 35% |
| Automated test coverage requirements | 34% |
| Developer training and guidance | 22% |
| Traceability of AI-assisted code | 20% |
The leading control is a person reading a diff. Policies and standards are documents that someone has to remember. Only one team in five can trace which code AI produced. Meanwhile, about one in three respondents had at least one AI- or agent-related production incident in the past year.
Human review scales with reviewers, not with output. It is good at judgment and poor at checking the same fifty constraints on every change. Gartner expects the control point to move: it predicts that by 2027, over 65% of engineering teams using agentic coding will treat integrated development environments (IDEs) as optional, "shifting control, governance, and validation to automated platforms."
The missing piece is decision governance
Put EY's top constraints side by side. Architecture and context-setting is about knowing which decisions apply. Validation and security review are about checking that a change respected them. Both depend on decisions the team has already made. EY did not ask how teams record those decisions, but its control data points the same way: 41% rely on AI-specific coding policies or standards, and the most common control is mandatory human review (62%).
That is the job of engineering decision governance: the system that determines which engineering decisions govern a given change, why, and with what evidence. An architecture decision record (ADR) says what was decided. Decision governance gives it force: where it applies, whether it is still current, and how anyone can tell it was followed.
Without it, every independently made change is a chance to lose engineering coherence. Each change passes its own tests while the system drifts from the decisions that hold it together.
What changes in the AI-native SDLC
We read EY's findings as pointing to a delivery stack with four layers, each answering a different question:
- Generation. Agents and assistants write the change. This layer is now cheap and widely available.
- Context and retrieval. The agent gets relevant documents and code. Useful, but retrieval cannot say which document is authoritative.
- Decision governance. Approved decisions are resolved for the specific change: which apply, which is current, which wins when two overlap.
- Deterministic enforcement and evidence. The enforceable decisions are checked the same way every time, and the result is recorded.
EY's control figures suggest most teams still rely on people and documents for the last two. The AI-native SDLC concept page covers the full lifecycle.
The moat moved too
EY's first finding is about strategy, not delivery. The CTOs see the standardised layers of a product, such as dashboards, interfaces and standard integrations, as most exposed to AI-built copies. They see proprietary data, compliance logic and customer-specific implementation as safest. The report calls this the moat moving "up the stack."
The same logic applies inside an engineering organisation. If code becomes cheap to reproduce, the durable asset is the set of decisions needed to reproduce the right code. We argued the strategic side in AI Won't Just Write More Software. It Will Make Software More Ambitious. and The AI ROI Problem Is Not About Models.
What engineering leaders should do
- Measure where work waits, not how fast code appears. EY's CTOs already see the constraint downstream. Track review queue time, rework and escaped defects next to generation speed.
- Turn your top constraint into a list of decisions. If architecture and context-setting is where work waits, write down the boundaries and dependency rules agents most often get wrong, and give each one a scope.
- Separate judgment from repetition. Keep human review for trade-offs. Move the checks that should give the same answer every time into automated enforcement.
- Make AI-assisted work traceable. Only 20% of EY's respondents trace AI-assisted code. Every verdict should point back to the decision that produced it.
Where Mneme fits
Mneme is an open-source decision and control layer for agentic software development. For architectural decisions in a repository, it implements part of decision governance today. It compiles the enforceable parts of accepted decisions into typed rules, which are machine-checkable rules with exact meaning, and checks proposed changes against them. Checks run inside supported agents through hooks, which intercept a file write before it lands, in Claude Code and OpenAI's Codex command-line interface (CLI), and again in continuous integration (CI) before merge. Each violation names the decision and rule that triggered it. Its Decision Index, the versioned record of a repository's decisions shipped in mneme-hq 0.10.0, keeps each decision's version history, lifecycle state and source.
Mneme is not a QA platform or a security scanner, and it does not replace review. Pulling decisions from Confluence, Jira or chat tools is not shipped.