When I sit down with leaders and ask why they’re investing in AI, the answer almost always comes back to speed. That sounds reasonable, but “speed” only has meaning if you know what’s actually slowing you down.
Most leaders, when pressed, can’t answer that question with any precision. They have a vague sense that delivery is too slow, a clear sense that their best engineers are getting recruited away, and a board that wants to see innovation move faster. So they buy coding assistance tools because they are the most visible and treat developers feeling that they’re moving faster as proof the strategy is working.
But the first job of an AI strategy is to identify your actual throughput bottleneck.
Faster coding ≠ faster delivery
In a typical project, a developer spends about 21% of their time writing code. The rest is meetings, testing, debugging, design, security review, and a huge amount of waiting for environments, builds, and reviews.
Now think about where the AI investment is going. Almost all of it targets that 21%. Every demo is about code generation, and success metrics focus on lines of code generated by AI.
“In a typical project, a developer spends about 21% of their time writing code. Even if AI made the coding portion ten times faster, you’d still only be optimizing less than a quarter of the system.
Even if AI made the coding portion ten times faster, you’d still only be optimizing less than a quarter of the system. The other 79% stunts your gains. Current research finds that the realistic ceiling for AI coding tools used in isolation is a 5 to 10% throughput improvement.
That’s a modest step forward, but falls short of the transformation your board is expecting.
Where throughput actually lives
If coding is 21% of the job, coordinating between systems and teams accounts for most of the rest, and that’s where the real throughput gains are hiding. The more interesting AI story reduces friction across all parts of the software development lifecycle.
- Translating a one-page business requirement into a draft technical spec, with acceptance criteria, epics, and task breakdown.
- Helping developers, testers, and security engineers navigate large unfamiliar codebases.
- Generating unit tests, identifying coverage gaps, producing realistic test data.
- Doing a first pass on merge requests to flag obvious problems, so the human reviewer starts from the interesting questions.
- Drafting release notes from commit history. Summarising a 4:00 a.m. production incident before the on-call engineer has finished their coffee.
The deterministic workflows your teams already rely on, like CI/CD pipelines, golden paths, and automated approvals, are exactly what enable AI to participate without breaking things.
The winners you didn’t expect
In my last year of conversations, the organizations getting the most measurable value from AI are large, slow-moving, traditional companies like banks, telecoms, and defense contractors.
That result runs against expectations for organizations with legacy systems, regulatory overhead, and risk-averse cultures. And yet a British universal bank regulated by the FCA, the PRA, and the Bank of England has rolled out an AI-enabled DevSecOps platform to 18,000+ users, supporting 48 million+ customers, with developer satisfaction north of 80%. Their CIO is on the record describing that they’re using it to refactor legacy code, generate tests, and detect vulnerabilities.
It’s not just banks. A world leader in telecommunications and networking equipment had an OSS/BSS team stuck on upgrade cycles measured in years. After bringing AI into a mature CI/CD pipeline, they saved 130,000 hours over six months, cut deployment time by 50%, and increased their testing scenarios tenfold.
Two traits explain why organizations like these outperform other companies:
- They already know how to run rigorous engineering. Mature CI/CD, automated testing, and a deep-rooted culture of “trust but verify” mean AI-generated code hits a pipeline built to catch mistakes before they become incidents. No engineer treats AI output as authoritative.
- They already know how to govern probabilistic systems. Banks have been running credit models, fraud models, and market risk models for the better part of two decades. “How do we govern a system that makes probabilistic decisions with real consequences?” is not a new question for them.
None of this scaffolding was built for AI. It was built for regulatory compliance and operational reliability. But it turns out to be exactly right for AI.
AI is an amplifier
DORA’s recent research on AI in the software development lifecycle concludes that AI doesn’t create maturity; it amplifies whatever maturity you already have.
“AI doesn’t create maturity; it amplifies whatever maturity you already have.”
This is what Barclays and Ericsson demonstrate. They didn’t get good at AI because they invested in AI. They got good at AI because they were already good at the fundamentals of testing, review, governance, and change control.
The inverse is true too. If you have a weak platform with manual deploys, thin tests, ad hoc review, and no governance, then AI just helps you generate technical debt faster.
You can see this playing out in the open-source world right now, where maintainers of major projects are publicly asking contributors to stop submitting AI-generated merge requests. It’s tempting to blame “AI slop,” but the real problem is that the projects don’t have the documentation, contributor guidelines, or volunteer reviewer capacity to absorb the volume. Enterprise teams are about to hit the same wall.
So the boring infrastructure investments you’ve been putting off because they don’t have a trendy AI story? Those are the investments that now determine whether your AI strategy works or fails.
The 10x developer was always a myth. But the 10x organization, where every engineer benefits from a platform that catches mistakes, reduces friction, and lets AI participate safely, is genuinely within reach.
Group Created with Sketch.
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.