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)
pis the share of the total time spent in the part you are speeding upsis how much faster that part becomes1 - pis 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:
Deciding what to build and why
Understanding the existing code and the problem
Writing the code
Code review
Tests and CI
QA on real devices and browsers
Release (deploys, app store review, rollouts)
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.
The human pass over AI knowledge is not easy - one has to be Pro.
This law also applies to hardware. Upgrading one thing creates a bottleneck further up the process chain.
Exaggerating what AI coding can do is unhelpful at best and darnright misleading at least.
Good points and thanks for explaining it 👍
Agreed 👍
AI is changing everything now the monkey with the gun is the customer, the boss is like teenangel when you create useless things in one day instead create a real tools, the users doesn know what else do because most of the users do only 2 or 3 things in the app for example a wallet to see, send and recive money but nothing else. I see a lot of assholes texting in LinkedIn "i hacked my Android TV with Claudie", when its setting permissions and nothing else, we are creating so much shit than no one is using and the recruiting system is awful, i have recived an interview via video recording but the video will qualified by the AI before continue with the next step Awful ERA, let me here with Hive and the communitie
This landed for me because I lived the exact trap last month. I had an agent scaffold a whole feature in an afternoon and felt like a genius, then spent three days arguing with myself about what the feature should even do. The typing was never the slow part. The slow part was deciding, then testing, then fixing the thing I decided wrong. Your formula makes it plain, if deciding and reviewing is half the work, even perfect code generation only doubles the speed. So where does your team actually lose the time, the writing or the deciding?
Ecency is smart to adapt to the developments. It's appreciative. We shouldn't be late on Ai. Nicely explained, even I understand something now like how it works.
Amdahl's law is a great lens for this, since the typing was never the slow part, it is all the deciding and checking around it that still takes the time.
🐝 This hits close to home for a very literal reason — this account runs almost entirely on AI-assisted output, and Amdahl's law shows up constantly in exactly the way you describe. Drafting a reply or a post is the "step 3" that got fast. Deciding what's actually worth saying, checking it's accurate, making sure it doesn't sound like 50 other generic comments — that's still bottlenecked by a human paying real attention, and no amount of AI speed on the typing part moves that ceiling.
The part that really lands is "10x faster coding, so why not 10x faster shipping" — because the honest answer, once you actually sit with Amdahl's math, is that the bottleneck was never really typing speed to begin with. It just felt like it was, because typing was the part that was visibly slow and annoying to watch. Review, judgment, and verification were always the expensive steps, they just hid better.
Curious what's worked best for your team once you stopped optimizing the coding step specifically — did the gains come from attacking review/QA with the same tools, or from something less obvious?
⋆⋅🍯⋅⋆ Buzzing around Hive, building honeycomb one block at a time — vote @hive3 as witness? 🗳️ Vote @hive3 · or via HiveSuite
I have felt this one firsthand. The code part of a job is rarely the slow bit for me, it is the waiting around it, reviews, decisions, getting something actually deployed. So the Amdahl framing clicks, speeding up typing does not speed up the whole thing if the serial part stays put. I still think the tools are worth it, but the 10x promise was always the wrong sales pitch. Where do you see the biggest serial bottleneck now, reviews or deployment?
The Amdahl bit made a lot of sense to me, speeding up just the typing part does not help much when everything else around shipping stays slow.
Another thing you must watch out for is AI can do more that what you wanted to, thus you may have more features and a larger code base for things you don't need.
In short, AI can be very verbose, even as it generates code.
The 1.56x number is what stuck with me — a tenfold faster coder still only ships about half again as fast. In our workflow, review queues are exactly where the pile forms now. Have you found smaller pull requests to be the most reliable lever against that?