A fintech CTO I work with had her board moment three months ago. The chair leaned forward mid-review and asked the question every technology executive dreads: “So you’re telling me you don’t know if this is working?”
Her answer was better than most: “I’m telling you that the numbers we were using to answer that question stopped answering it six months ago.”
The board never asked about velocity again.
The myth and the math
The 5x assumption has taken hold in boardrooms across the industry. Vendors promise it, analysts echo it, CEOs repeat it in earnings calls. And engineering teams absorb the expectation without anyone pausing to ask: 5x faster at what, exactly?
Fred Brooks observed in 1975 that coding accounts for roughly 15 to 20 percent of total delivery effort. The rest is requirements clarification, design decisions, coordination, testing, review, and deployment. AI has not changed that proportion nearly as much as most people assume. Five decades later, the overall shape has shifted far less than anyone expected. AI accelerates the 15 to 20 percent slice. The other 80 percent, the part that requires judgment, communication, and organizational alignment, remains untouched.
Systems theory has a name for this constraint: Amdahl’s Law. Even if AI made coding literally five times faster, the total delivery improvement caps at roughly 19 percent (because most of the work was never coding to begin with). That is real, and worth capturing, but it is a long way from 5x.
The actual measured gains are even smaller. Five independent studies published in 2025 and 2026 used different methodologies and measured different things, but the direction is consistent: individual activity up, organizational outcomes flat or worse. DX tracked 400 companies and found AI usage up 65 percent, PR throughput up 10 percent. MIT and NBER tracked 100,000 developers and found 300 percent more code generated with only 30 percent more software reaching release. Cortex measured PRs per author up 20 percent alongside incidents per PR up 23.5 percent.
The most revealing study came from METR, a Berkeley research nonprofit that ran a randomized controlled trial with experienced open-source developers working on their own repositories. Developers using AI tools took 19 percent longer to complete tasks. After each session, those same developers estimated they had been 20 percent faster. A 39-point gap between perception and reality, where management measures the perception and developers live inside the gap. Nobody has a shared vocabulary for the conversation in between.
The function vs the roadmap
The 5x number is real, just misapplied. A developer says “I wrote that function in 10 minutes instead of 50.” True. The function was 5x faster. But the feature still took six weeks, because the function was never the bottleneck.
Individual productivity is not team productivity, and team productivity is not organizational throughput. The 5x claim is true at the individual task level, plausible at the team activity level, and invisible at the delivery level. When a board hears “we are 5x faster,” they assume the roadmap just compressed by 80 percent. The developer meant the function. The board heard the quarter. Both statements feel true to the person making them, and the gap between them is where organizations lose months of planning credibility.
The failure mode is hedging. A CTO says “we think velocity might not be telling the full story” and every stakeholder concludes their specific use of the metric is the exception. The engineering directors hear it as a product management problem. Product managers hear it as an engineering discipline problem. Everyone agrees something should change and nothing does, because the language was designed to avoid making anyone uncomfortable rather than to name the problem clearly.
What actually changes
Three things change about delivery speed when AI enters an engineering organization. None of them is “5x faster end to end.”
The bottleneck moves. Code generation stops being the constraint. Intent definition, architectural judgment, and review become the rate-limiting steps. Organizations that restructure around this shift capture real gains, not by generating code faster but by reducing the time between intent and validated business outcome. Organizations that add AI to existing workflows experience the paradox: dashboards improve, delivery doesn’t.
The perception gap widens. When AI makes developers feel faster without making the organization measurably faster, the CTO inherits a credibility problem. The board sees dashboards going up while the VP of Product sees the roadmap slipping, and both are looking at accurate data. They are measuring different points in a system that now has a wider spread between activity and outcome.
The board conversation needs a three-part structure. The old structure was simple: here is our velocity, here is our forecast, here is our delivery confidence. The new structure requires three parts: what actually changed (specific gains, acknowledged honestly to establish credibility), what did not change (complexity, coordination, the 80 percent that requires judgment), and what got worse (review burden, comprehension debt, vendor dependency). A CTO who delivers all three parts earns the credibility to propose different measurement. Without all three, the board either concludes everything is fine or concludes the investment failed, and neither gives you permission to measure differently.
The political act
Retiring a metric is a political act, not a technical one. Every metric has constituencies whose authority depends on the numbers staying exactly as they are. The project manager who uses velocity for forecasting. The engineering director who uses cross-team comparisons for performance reviews. The CFO who reports sprint completion rates to the board.
Metrics allocate power. Telling a stakeholder that their metric no longer works, without offering them something better, produces resistance that looks like disagreement but is actually self-preservation. They are not defending the metric. They are defending the organizational role the metric enables them to play.
The CTO’s job is to build the replacement before retiring the old system, stakeholder by stakeholder, with tools that serve each person’s legitimate need. That is a change management problem, not a dashboard problem. And most organizations never get there, because the CTO who retires a metric is implicitly admitting that decisions made using that metric may have been wrong.
AI did not make measurement harder. It exposed that we were measuring the easiest thing instead of the most important thing.
That is the real measurement problem, and the redesign it requires goes deeper than any single post can cover: the retirement process, the stakeholder alignment strategy, and the metrics that survive the AI era. I am working on that deeper treatment now.
Ricardo
