Amdahl's law for software teams: why faster coding barely helps

Everyone on the team has an AI assistant. Code that took a day now takes an hour. So why does a feature still take three weeks from ticket to users? This is the AI coding productivity paradox, and people usually explain it with vague talk about culture or hype.

There is a precise explanation, and it is almost sixty years old. Gene Amdahl described it for parallel computers in 1967. It applies to a software team just as well as to a processor, and it tells you exactly where to look for the gains that didn’t arrive.

Amdahl’s law in one paragraph

If a part of a job takes a share p of the total time, and you make only that part s times faster, the whole job gets faster by 1 / ((1 − p) + p / s). The part you didn’t touch, 1 − p, sets a hard ceiling. Even if s goes to infinity, the job can’t get more than 1 / (1 − p) times faster.

For software teams, p is the share of lead time spent actually writing code. AI coding tools raise s. Everything else (understanding the ticket, waiting for answers, review, CI, approvals, release, rework) is the 1 − p that stays where it was.

How much of a developer’s time is coding?

Atlassian’s 2025 State of Developer Experience report surveyed 3,500 developers and managers. Developers said they spend only 16% of their time coding. Whatever the exact figure for your team, it is rarely above half, and on mature products with many stakeholders it is usually much lower.

Plug 16% into the formula. Make coding twice as fast and delivery gets about 9% faster. Make it ten times faster and you get about 17%. Make it instant and you top out near 19%.

Overall speed-up vs coding speed-up

By the share of total time that is coding

• Coding is 16%
• Coding is 30%
• Coding is 50%
• Coding is 70%

Data as a table

Coding speed-up	Coding is 16%	Coding is 30%	Coding is 50%	Coding is 70%
1×	1×	1×	1×	1×
2×	1.09×	1.18×	1.33×	1.54×
5×	1.15×	1.32×	1.67×	2.27×
10×	1.17×	1.37×	1.82×	2.7×
20×	1.18×	1.4×	1.9×	2.99×

The lines flatten fast. Past about 5×, more coding speed buys almost nothing, because the remaining time is all in the other stages. This is why a team can honestly feel twice as productive at the keyboard and see delivery barely move.

Saved 10 hours, lost 10 hours

The same Atlassian report puts numbers on the other side of the equation. 68% of developers said AI saves them more than 10 hours a week. 50% said they lose more than 10 hours a week to organisational friction, and 90% lose at least 6. The top sources were finding information (services, docs, APIs), adapting to new technology and switching context between tools.

Hours saved by AI vs hours lost to friction

Share of developers, per week

Data as a table

	Value
Report any time saved with AI	99%
Save more than 10 hours with AI	68%
Lose 6 or more hours to friction	90%
Lose more than 10 hours to friction	50%

For a typical developer in that survey, the time AI gives back is roughly the time the organisation takes away. That is Amdahl’s law with a twist: the untouched part of the work isn’t static. It can grow.

When the untouched part gets bigger

The formula assumes the rest of the work stays the same size. With AI it often doesn’t. Faros AI’s 2025 telemetry of over 10,000 developers found that high-AI teams merged 98% more pull requests while review time per pull request rose 91% and pull requests grew 154% in size. DORA’s 2025 report found that AI correlates with higher throughput and also with rising delivery instability, which means more rework later.

So the faster stage pushes more load onto the slower stages. Here is a model of one ticket to show how that plays out.

One ticket's lead time, four ways

• Coding
• Review and its waits
• Everything else

Data as a table

	Coding	Review and its waits	Everything else
Before AI	6 h	4 h	10 h
Coding 5× faster	1.2 h	4 h	10 h
Faster coding plus review +91%	1.2 h	7.6 h	10 h
Review and waits redesigned	1.2 h	1.5 h	4 h

In the third row, the coding gain is almost entirely eaten by heavier review: 18.8 hours instead of 20. The fourth row is where the real speed-up lives, and none of it comes from coding faster.

Bad responses to the paradox

The most common bad response is to push harder on the part that already got faster: more licences, prompt training, targets for AI-written lines. Amdahl’s law says this has the smallest possible return.

The second is to measure the wrong thing. Lines of code, commits and pull requests per developer all go up with AI for free. They make a dashboard look good while lead time stays flat. Faros saw exactly this: team activity up, company-level outcomes flat.

The third is to decide AI “doesn’t work” and pull back. The tools did their part. The organisation didn’t change around them.

Where the rest of the time goes, and how to shrink it

The good response is to treat the 1 − p as the real backlog. Work through it in this order:

1. Measure lead time by stage on a sample of real tickets: time to start, coding, waiting for review, review, CI, waiting for approval, release. Most teams find waiting dominates. I go through how to map it in where the hours go.
2. Shrink review first, because AI makes it grow. Small diffs, evidence attached to every pull request, and an independent machine reviewer before a person. More on that in code review is the new bottleneck.
3. Cut information friction. The top friction source in Atlassian’s survey was finding information. Agents can answer “which service owns this API?” from code and docs if you give them access, and that is a direct cut to the untouched part.
4. Remove hand-offs that exist only for sign-off. Every approval step is a queue. Keep the ones where a person decides something; automate the ones where a person only confirms that checks passed.
5. Let agents work while people don’t. Waiting for a reviewer overnight is a lost night. A pipeline where agents write, check and review each other without a person in the middle turns that night into progress.

The same law inside an agent pipeline

Amdahl’s law doesn’t stop applying once agents do most of the work. It just moves. In a pipeline where one agent writes, another reviews and a third runs checks, the slow part is whatever still needs a person: a question only the product owner can answer, an approval, a merge button. A run that needs ten minutes of agent time and then sits six hours waiting for someone to answer a one-line question has a serial fraction of over 97%, and it is all human.

That is why the design of a good agent pipeline is mostly about the waits. Agents should collect every question they need answered up front, before work starts, instead of stopping halfway. They should keep going on everything that doesn’t depend on the answer. And the human decisions should be batched, so a person spends twenty minutes in the morning instead of being interrupted all day.

There is also a second, more hopeful law. Gustafson’s law, the companion to Amdahl’s, says that when a system gets faster, people usually don’t run the same job quicker: they run a bigger job in the same time. For a team, that means the capacity freed by agents doesn’t have to show up as a shorter lead time on one product. It can show up as more products.

The bold conclusion

Amdahl’s law has an optimistic reading. Once coding is close to free, the remaining time is mostly people waiting for people. That is an organisational design problem, and it is far more solvable than making engineers type faster ever was.

Take it to its end. If agents write the code, a different agent reviews it, checks prove the acceptance criteria and only high-risk changes wait for a person, then p is no longer a small slice. Most of the lead time becomes automatable, and the ceiling in the chart above moves up with it. That is the case for redesigning delivery around agents, and why I think a product that needs nine engineers today can be run by far fewer, with the rest building new things.

Questions

What is the AI coding productivity paradox?

Developers feel much faster with AI tools, yet teams don’t deliver much faster. Faros AI found high-AI teams merged 98% more pull requests with no significant company-level improvement, because the gain is absorbed by review, waiting and other stages.

What is Amdahl’s law in software development?

It says the overall speed-up from making one part of the work faster is limited by the share of time that part takes. If coding is 16% of lead time, even infinitely fast coding can speed delivery by at most about 19%.

How much time do developers actually spend coding?

Atlassian’s 2025 survey of 3,500 developers and managers reported 16% of developers’ time spent coding. The rest goes to meetings, finding information, review, waiting and coordination.

How do I get real productivity gains from AI coding tools?

Measure lead time by stage and attack the largest waits, usually review and approvals. Faster coding only pays off once the stages around it are redesigned.