Copilots Everywhere; Productivity Nowhere
I’ve spent a lot of time recently with large enterprises and legacy-heavy organizations thinking about AI, developer productivity, and the future of software development.
One thing is clear: we have not yet seen meaningful productivity gains at scale.
If AI were truly transforming the software development lifecycle (SDLC) in these environments, we’d expect to see it show up in the numbers: double-digit improvements in technology spend efficiency; reduction in reliance on system integrators; leaner engineering organizations.
But none of that has materially happened.
It’s not because enterprises aren’t investing. They are. They’ve bought copilot licenses; added Cursor, Codex, and other tools; established significant LLM/token budgets.
Then why haven’t we seen AI-driven productivity gains in enterprise software development?
The core problem: treating AI as retooling instead of organizational change.
Tooling ≠ Transformation
Most enterprises are approaching this like a tooling upgrade. Of course, it’s not.
Yes, the functions of SDLC remain: requirements; design; implementation; testing; release. But the process is no longer linear.
And there’s more. Roles blur. Activities shift. Decision-making moves earlier. Execution becomes partially or fully delegated to agents.
This requires rethinking the system and organization, not just adding tools.
Where Real Opportunity Starts
One of the more insightful frameworks I’ve heard came from a CTO I deeply respect. He simplified the question:
“What is the fastest way to measure if AI is actually working in our SDLC?”
His answer wasn’t velocity. It wasn’t lines of code. It wasn’t even cycle time. It was:
👉 Reduction in the complexity of user stories
First, a clarification: “complexity” refers to the number of “points” used to estimate the difficulty of delivering a given user story. Here’s why it matters. In enterprise environments, this “complexity” is largely a proxy for how hard it is for humans to understand legacy systems. It’s highly variable, and it’s often inflated due to knowledge gaps and cognitive overhead.
So instead of measuring output, measure how much cognitive burden is being removed.
A First Agentic Use Case
How do you reduce cognitive load in software development? Here’s a very practical starting point.
The first agent shouldn’t write code. It should understand the work.
Imagine an agent that analyzes a user story, navigates the legacy codebase, assigns a true complexity score, and produces an execution plan.
Even if humans still execute that plan? You’ve already eliminated a huge layer of waste. You’ve standardized understanding. You’ve reduced variance across engineers.
And over time? That plan becomes executable by agents.
Adoption vs. Expectation
Enterprises are still early on the maturity curve:
Tool adoption (we are here)
Workflow augmentation
Agent-assisted planning
Agent-executed development
Fully re-architected SDLC
Most companies are stuck at step 1, expecting step 4 results.
That gap is the source of frustration. Overcoming it starts with recognizing that AI in enterprise software development is not a plug-and-play productivity boost. It’s an organizational redesign problem.
The winners won’t be the ones who buy the most tools or spend the most on tokens. They’ll be the ones who rethink how work is defined, reduce cognitive complexity, introduce agents at the right layer (starting with planning, not coding), and evolve their SDLC into something non-linear and adaptive.
I expect that we will see massive productivity gains. But they won’t come from copilots alone. They’ll come from changing how software development actually works.
Has your organization moved beyond the tool adoption stage? How did you achieve the breakthrough, and how far have you gotten? Let me know in the comments.
