AI Writes Code 10x Faster, So Why Don't We Ship 10x Faster? What Amdahl's Law Taught Us

Every few weeks someone shows a demo where an AI agent writes a whole feature in minutes. Typing code has never been cheaper. So here is a fair question for every team building with these tools, including ours: if writing code got many times faster, why didn't shipping?

The answer is a 59 year old idea from computer architecture. It is called Amdahl's law and it is the clearest way we know to think about what AI coding tools actually change.

This is not an anti-AI post. We use these tools every day and they have changed how we work for the better. But "10x faster" is the wrong promise and setting the right expectation is what lets a team get the real gains. So this post does two things: it shows with simple math why the hype overshoots and it shares what has worked for us once we stopped looking only at the coding step.

The law in one sentence

In 1967 Gene Amdahl pointed out that speeding up one part of a job can only speed up the whole job by as much as that part matters. If a task has a piece you cannot speed up, that piece sets a hard ceiling on the total gain, no matter how fast you make everything else.

The formula is short:

Speedup = 1 / ((1 - p) + p / s)

• p is the share of the total time spent in the part you are speeding up

• s is how much faster that part becomes

• 1 - p is everything else, which stays the same

Amdahl was talking about processors. The part you could run in parallel got faster with more cores. The serial part did not. Add a thousand cores and the serial part still decides how fast the program finishes.

Swap "cores" for "AI coding tools" and the law fits software delivery almost too well.

Where the time actually goes

Writing code is only one step between "we should build this" and "users have it". A typical change also goes through:

1. Deciding what to build and why

2. Understanding the existing code and the problem

3. Writing the code

4. Code review

5. Tests and CI

6. QA on real devices and browsers

7. Release (deploys, app store review, rollouts)

8. Verifying it works in production and fixing what slipped through

AI tools mostly accelerate step 3, with some help on 2 and 5. Studies of developer time tend to find that hands-on coding is a minority of the week, usually under half. Meetings, reviews, waiting and reading code take the rest.

Running the numbers

Say coding is 40% of the time it takes to ship a feature. Now give the team a tool that makes coding 10x faster.

Speedup = 1 / (0.60 + 0.40 / 10) = 1 / 0.64 ≈ 1.56x

A 10x faster coder ships about 56% faster. Make coding infinitely fast (zero seconds per feature) and the ceiling is:

Speedup = 1 / 0.60 ≈ 1.67x

That is the uncomfortable part of the law. Past a certain point, making the fast part faster stops mattering. The 60% you did not touch is now the whole story.

Coding share of lead time	Coding 2x faster	Coding 10x faster	Coding infinitely fast
20%	1.11x	1.22x	1.25x
40%	1.25x	1.56x	1.67x
50%	1.33x	1.82x	2.00x
70%	1.54x	2.70x	3.33x

Even in a team where coding is 70% of the work, which is rare, a perfect AI only gets you a little over 3x.

AI speeds up other steps too, up to a point

To be fair to the tools, coding is not the only step they help with. AI can take the first pass at code review, write and fix tests, explain unfamiliar code and draft release notes. Every step it speeds up raises the ceiling.

Say that on top of 10x faster coding, AI also makes tests, first-pass review and reading code (another 20% of the time) twice as fast:

Speedup = 1 / (0.40 / 10 + 0.20 / 2 + 0.40) = 1 / 0.54 ≈ 1.85x

Better. But look at the last term. The remaining 40% is work AI does not shorten: deciding what to build, testing on real devices, waiting for app store review and checking production. Even if AI made everything else instant, that 40% caps the gain at 1 / 0.40 = 2.5x. The law still applies. It just moves the ceiling to the steps that need a person, a phone or someone else's queue.

The bottleneck doesn't disappear, it moves

Amdahl's law has a quiet second lesson. Once you shrink one step, the next slowest step becomes the bottleneck. In manufacturing this is called the Theory of Constraints: a system flows only as fast as its narrowest point. Speeding up anything else just piles up work in front of that point.

With AI coding tools, here is where the pile tends to form:

• Code review. A developer who can open five pull requests a day instead of one has just quintupled someone else's review queue. Review needs a human who understands the change. Understanding does not get 10x faster.

• Tests and CI. More changes means more pipeline runs, more flaky test reruns, more waiting for a green build.

• QA and devices. Someone still has to tap through the app on a real phone, in dark mode, on a slow network.

• Release gates. App store review takes as long as it takes. A rollout still needs watching.

• Decisions. When building is cheap, the hard question is no longer "can we build it?" but "should we?" Product judgment, design and saying no become the scarce resource.

• Production verification. Code that was fast to write still has to be proven correct where real users are.

So the gain from faster coding is real, but it shows up first as longer queues somewhere else.

Worse: the slow part can grow

The plain formula assumes the rest of the work stays the same size. With AI it often doesn't. Generated code tends to come in larger diffs, touch more files and include code nobody on the team fully wrote. That makes review slower, debugging harder and bugs more likely to reach production.

You can add that to the formula with a factor g for how much the non-coding work grows:

Speedup = 1 / ((1 - p) × g + p / s)

Take our 40% example again. Coding gets 10x faster, but review and debugging get 20% heavier (g = 1.2):

Speedup = 1 / (0.60 × 1.2 + 0.04) = 1 / 0.76 ≈ 1.32x

The 56% gain shrinks to 32%. If the extra review and rework is a bit larger than that, the team ends up slower than before, while everyone feels faster because the typing part flies.

This is not only theory. Two well known studies point the same way:

• Google's DORA 2024 report found that a 25% increase in AI adoption was associated with an estimated 1.5% drop in delivery throughput and a 7.2% drop in delivery stability, even as individuals reported feeling more productive. (source)

• METR's early 2025 study of experienced open source developers found that with AI tools they took 19% longer to finish real tasks, while they believed they had been about 20% faster. (source) METR has since said it is changing its study design and the tools have improved a lot since then, so treat the exact number as a snapshot. The gap between feeling fast and being fast is the lasting lesson. Their late 2025 follow-up points to a speedup instead, though METR says it can no longer measure it well because many developers now refuse to work without AI. Their 2026 survey has people reporting 1.4x to 2x more valuable work. That is a real gain and it is also very close to what Amdahl's law predicts, nowhere near 10x.

What this looks like at Ecency

We build Ecency's web app, iOS and Android apps, the SDK behind them and the services that power them as a small team. AI coding tools are part of our daily work and they have earned real credit:

• A small team covers more ground. Web, mobile, SDK and backend changes that used to compete for the same few people now move in parallel.

• The backlog gets smaller. Small bugs and polish issues that used to wait for months get fixed, because writing the fix is no longer the expensive part.

• Investigations go faster. Tracing a bug through unfamiliar code, logs or another repo takes far less time when you have a tireless reader at your side.

• Tests come with the change. Writing the test is cheap now, so it ships in the same pull request instead of "later".

But Amdahl's law told us the coding speedup alone would not reach users at the same rate. So the bigger improvement was changing the workflow around the code and pointing the tools at those steps too:

• Write the issue first. A clear problem statement makes both the AI output and the review better.

• Smaller, focused pull requests. Easier to review, easier to roll back.

• Automated review on every pull request, then a human pass. The bot takes the first sweep so people spend their time on what matters.

• Run the targeted tests while working, the full suite before merging. Fast feedback without skipping the safety net.

• Verify in production by repeating the exact thing that was broken, not by trusting that the code looks right.

Some steps stay as slow as they always were and we accept that:

• App store review does not care how fast the code was written.

• Real device testing on phones still takes a person and a phone.

• Code that touches keys, wallets and transfers on the Hive blockchain gets a careful human read every time. Fast and wrong is not an option when it is someone's funds.

• Deciding what to build for the community is still the slowest and most important step.

None of the workflow advice is new. AI just made it matter more, because the steps around coding are now where most of the time goes. Improving them is what turned faster coding into faster shipping for us.

The takeaway

AI coding tools are a real speedup and we would not want to work without them. Amdahl's law tells you how much that speedup is worth on its own: as much as coding mattered and not a bit more.

The rest of the gain is still there to be had, just not from the code editor. Look at the whole path from idea to user, find the slowest step and work on that one. Then do it again, because once you fix it the bottleneck will have moved.

What is the bottleneck in your workflow now that coding got faster? Tell us in the comments. We read them all.