Amdahl’s Law doesn’t care about your sprint velocity.

There’s a pattern playing out in companies right now.

Engineering gets AI tooling. Code generation, automated testing, AI-assisted reviews. Within a quarter, velocity is up. PRs merge faster. Features ship sooner. Leadership is excited. Slides go to the board.

And then the revenue numbers come in. Flat.

The post-mortems are always the same: “we built a lot, but it didn’t translate.” Everyone nods. Someone suggests better prioritization. The real problem goes undiagnosed.

The problem has a name from 1967

Gene Amdahl was a computer architect. His law describes how much you can actually speed up a system by improving one part of it.

The formula is simple: if a process is 20% parallelizable and you make that 20% infinitely fast, your total speedup is capped at 1.25x. The other 80% sets the ceiling. Forever.

It was written for CPUs. It describes your company perfectly.

What the pipeline actually looks like

Engineering is roughly 20% of a company’s total value delivery pipeline. The rest — before and after — is everything else.

Before engineering touches a line of code: market research, requirements, design, UX validation. After the code ships: security review, QA, legal, deployment, marketing, sales enablement, customer success, support.

Each stage is sequential. Each stage gates the next.

When you accelerate only coding — even by 10x — Amdahl’s math is brutal:

Max overall speedup = 1.22x

Not 10x. Not 5x. One-point-two-two.

You didn’t transform the company. You moved the bottleneck.

Where it actually goes

Product and design choke first. Engineers finish sprints ahead of schedule and reach for backlog items that are loosely specced or not specced at all. PMs are overwhelmed. Design is the gating dependency. Features ship on hunches, not validated requirements.

Security and QA choke next. 10x code output means 10x review surface. Your AppSec team of three is not suddenly 30 people. Your manual QA regression cycle was calibrated for one major release a month, not four. The code lands in a queue, not in production.

Legal shows up when you least expect it. AI-generated code carries IP and license ambiguity nobody is reviewing fast enough. New vendor integrations need data processing agreements. Enterprise contracts are still a 6-week cycle. The feature is done. It waits.

Sales can’t sell what they don’t know. Features ship. The AEs have no demo, no updated battle card, no pricing clarity. The customer who was evaluating you signs with a competitor who had worse features but a cleaner narrative. The sales cycle is still 60–90 days regardless of how fast engineering moved.

Support absorbs the blast. More releases equal more surface area for confusion. Ticket volume spikes. SLAs slip. NPS quietly drops. Some of the revenue you gained starts churning.

The math doesn’t lie

This assumes 10x improvement on the accelerated portion. The ceiling is set by what you don’t accelerate.

What this means in practice

AI transformation is not an engineering project. It is a systems problem.

The question is not “how do we make engineers faster?” The question is: what fraction of our total value delivery pipeline can we accelerate, and in what order?

Every function that stays slow becomes the new bottleneck. The pipeline doesn’t care which stage is the constraint — it just slows to match it.

The companies that will see real revenue impact from AI aren’t the ones with the best engineering AI stack. They’re the ones that treated every team as part of one system — and accelerated accordingly.

Requirements, design, security, QA, legal, finance, marketing, sales, support. All of it. The whole pipeline.

Anything less is just moving the bottleneck downstream and calling it transformation.

If your sprint velocity is up and your revenue isn’t, you’re not seeing the ROI problem. You’re seeing Amdahl’s Law.