Why a New Tool Won't Make You Five Times Faster: Amdahl's Law of Human Productivity

Using Amdahl's law, the article explains why tools like AI for programmers or 3D CAD for engineers deliver far smaller overall speedups than marketing promises — they accelerate only about a third of the work, so even an infinitely fast tool boosts total output by at most tens of percent, and the bottleneck merely shifts elsewhere (from writing code to reviewing and approving it). The author backs this with empirical studies, including the randomized 2025 METR trial, where experienced developers were 19% slower with AI despite believing the opposite, and the "J-curve" phenomenon, where productivity first drops after adoption. According to him, real productivity gains come not from faster tools but from rebuilding the way work is done — and that takes years, not quarters.

The Design Engineer Who Draws Too Fast

Imagine a mechanical design engineer who has just received the latest parametric 3D CAD system. The software lets him model three times faster than in the old 2D system. His manager expects three times the output. A quarter goes by and nothing changes — the engineer still delivers roughly the same number of projects as before.

He isn't lazy. The problem lies elsewhere: drawing was never more than a third of his job.

The rest of his day is spent consulting with manufacturing engineers, running strength analyses, communicating with the customer, taking part in design reviews, and searching the archive to see whether someone has already worked out a similar part. None of that has changed — and it is precisely these activities that determine how fast a project actually moves forward.

The same thing is happening today with artificial intelligence and programmers. And the same thing happened with computers in the 1980s, with electricity at the turn of the century, and with the steam engine a hundred years before that. The pattern is always the same, and it has a precise mathematical description.

What Amdahl's Law Says

In 1967 Gene Amdahl formulated a principle that originally described the limits of parallel computation, but which holds universally for any speedup of one part of a system. The formula is simple:

Where p is the fraction of the work the tool accelerates, s is how many times it speeds it up, and S is the resulting overall speedup. The consequence is merciless: if the tool speeds up only 30% of your work, then even an infinitely fast tool will not speed up the whole by more than 1.43×. And the difference between a twofold and a fivefold speedup of a sub-task is surprisingly small at the level of the whole.

This is not theory. It is arithmetic — and it holds regardless of whether we are talking about CAD, AI, or any other tool.

How Much Time Do We Actually Spend on What the Tool Speeds Up?

For Amdahl's law to be of any use, we need to know p — what fraction of working time the tool actually covers. The data exist, and they are consistent across fields.

According to a 2019 survey by Tidelift and The New Stack, in which nearly 400 professional developers took part, software engineers spend roughly 32% of their working time writing new code and improving existing code. Another 35% goes to code management — maintenance, testing, dealing with security matters. And 23% goes to meetings, management, and operational tasks. The remaining 10% is taken up by other activities.

Similar figures are confirmed by a Microsoft Research study titled Time Warp, based on a summer 2024 survey of 484 Microsoft developers. In it, developers report devoting the most time to communication and meetings (around 12%), coding (about 11%), debugging (about 9%), and architecture (roughly 6%). The rest is split among code reviews, documentation, onboarding, and learning new technologies.

Clockwise analyzed 1.5 million meetings across 80,000 software engineers from 5,000 companies and found that the average individual-contributor engineer spends 10.9 hours a week in meetings. On top of that, they have 19.6 hours of continuous blocks of two or more hours — time when they can really concentrate. The remaining roughly six hours is "fragmented time," that is, gaps between meetings too short for deep work. According to research by Gloria Mark of UC Irvine, regaining concentration after an interruption takes about 23 minutes.

The situation in engineering disciplines is analogous. The actual 3D modeling in CAD typically takes up 25–35% of a design engineer's working time; the rest consists of calculations, simulations, consultations, documentation, and administration.

A simple conclusion follows from this data: a code-writing assistant primarily accelerates one third of a programmer's working time. 3D CAD accelerates roughly the same share of a design engineer's time.

The Calculation Nobody Wants to Hear

When we plug real numbers into Amdahl's formula, the results are sobering:

If AI doubles the speed of coding and coding makes up 35% of working time, the overall speedup is 1.21×. At a fivefold speedup: 1.39×. And with infinitely fast coding — that is, if code appeared instantly — the overall speedup would not exceed 1.54×.

For 3D CAD: a threefold speedup of drawing (30% of working time) yields an overall speedup of 1.25×. Even instantaneous drawing would reach no more than the aforementioned 1.43×.

The key observation: more important than how much the tool speeds up (s) is how much work it speeds up (p). A tool that slightly speeds up 70% of the work beats a tool that dramatically speeds up 30%.

The Productivity Paradox: Data Against Intuition

Not only do tools speed up just part of the work — people also systematically overestimate how much they help.

The 2025 study by the organization METR is so far the most rigorous test of AI assistants under real-world conditions. Sixteen experienced open-source developers worked on 246 real tasks in their own repositories, with each task randomly assigned as to whether they were allowed to use AI (mostly Cursor Pro with Claude 3.5/3.7 Sonnet). Before they began, the developers expected AI to save them 24% of their time. Objective measurement showed that with AI they were 19% slower. Even after the study ended, they estimated the speedup at 20%. The gap between subjective perception and measured reality thus amounted to 39 to 43 percentage points, depending on whether one takes the prior estimate (24%) or the retrospective assessment (20%). The causes of the slowdown: time spent formulating prompts, checking AI outputs, debugging subtle errors, and integrating generated code into the existing codebase.

A broader view is offered by the 2025 Faros AI research report, based on telemetry from more than 10,000 developers across 1,255 teams. Teams with a high rate of AI usage completed 21% more tasks and merged 98% more pull requests. But the time to review each such request grew by 91%. At the company-wide level, the researchers found no statistically significant correlation between the rate of AI usage and improvement in the key software delivery indicators (DORA metrics). The bottleneck shifted from writing code to approving it — exactly as Amdahl's law predicts.

An April 2026 post on the Atlassian blog, which applies this principle directly to AI, illustrates it with a concrete example: if individual work makes up only 20% of a project's life cycle and AI primarily speeds up that part, then even instantaneous execution of all individual tasks will speed up the whole system by a factor of at most 1.25×. The remaining 80% — reviews, decisions, approvals, cross-team coordination — moves at the same speed as before.

The J-Curve: It Gets Worse First

A study by Kristina McElheran (University of Toronto, a digital researcher at the MIT Initiative on the Digital Economy) and co-authors including Erik Brynjolfsson adds another layer. The work, published in April 2025 — with wider attention in January 2026 — analyzed U.S. Census Bureau data on tens of thousands of manufacturing firms from 2017 and 2021. It found that productivity declined after the deployment of industrial AI — by 1.3 percentage points on average. After correcting for the selection effect (firms with higher expectations deploy earlier), the short-term negative impact was even more pronounced.

After four years, however, the trajectory reversed. Firms that had deployed AI outperformed the others both in productivity and in market share. Researchers call this pattern the "J-curve" — an initial dip followed by growth.

The dip was not caused by bad technology. The cause was a mismatch between the new tools and existing processes. Systems for predictive maintenance, quality control, or demand planning required investments in data infrastructure, employee training, and a redesign of workflows. Without these complementary investments, even advanced technologies failed to deliver the expected results.

McElheran points to a striking pattern: older firms with established routines and hierarchies had significantly greater difficulties. Some even reduced their use of structured managerial practices after deploying AI — and that decline alone explained nearly a third of their productivity losses. Younger firms integrated AI faster and with smaller losses.

Historically, this is a well-known phenomenon. Brynjolfsson identified the "productivity paradox" back in 1993 — the observation that, despite massive investment in information technology in the 1970s and 1980s, productivity stagnated. The paradox was resolved in the 1990s, but only for firms that complemented their IT investments with organizational change. A similar lag accompanied earlier technological revolutions as well — the dividends came only after decades, once entire industrial processes had reorganized around the new technology.

The Hidden Dimension: Quality

So far we have spoken only about speed. But tools like 3D CAD or AI coding assistants have a second, often more important dimension — reducing the error rate.

A parametric 3D model eliminates whole classes of errors: part collisions, dimensional inconsistencies, assembly interferences. A digital prototype reveals problems before the first part is manufactured. AI code-writing assistants catch known anti-patterns and security vulnerabilities. Integrated simulations (FEA, CFD) replace physical prototypes.

The economics of errors, meanwhile, says that the cost of fixing them grows by an order of magnitude with each phase in which the error is detected. An error caught in the design phase costs on the order of single units. The same error detected in a prototype costs ten times as much, in manufacturing a hundred times, and at the customer a thousand times. A tool that catches 20% of errors earlier may have a higher return on investment than a tool that speeds up work by 50%.

The problem is measurement. Speed is easy to measure — time, throughput, completed tasks. Quality is measured as the absence of something. How many errors would we have without the tool? That is a counterfactual that is almost impossible to determine precisely. The result is a systematic bias: firms invest in speed (because they see it in the numbers) and underestimate quality (because they don't see it in the numbers).

The Counterargument: When Amdahl Doesn't Hold

Amdahl's law assumes a fixed breakdown of the work. But what if the tool changes that breakdown?

Here is a legitimate objection. AI that not only generates code but also automates reviews, tests, and documentation increases p — the share of work it accelerates. CAD with integrated simulation eliminates the separate analysis step. A tool that covers a third of the work is a different category from a tool that covers two thirds.

The second objection was formulated by John Gustafson as early as 1988: instead of asking "how fast can I do the same thing?", ask "how much more can I do in the same time?" More iterations, more design variants, better exploration of solutions. CAD that makes it possible to explore ten variants instead of two does not change speed — it changes the quality of decision-making.

Both objections are valid. But both require a fundamental redesign of processes, not the mere deployment of a tool into the existing way of working.

What to Measure and What to Expect

On the basis of the available data, realistic expectations can be formulated.

In the short term of one to two years: individual productivity on the accelerated task rises by 10–30%. Overall worker productivity by 5–15% (the limitation following from Amdahl's law). Company productivity may even temporarily worsen (the J-curve). Quality potentially improves for trivial errors, but new types of errors appear — AI hallucinations, excessive trust in generated output.

In the medium term of two to five years: firms that redesign their workflows around the tools can achieve a 15–30% overall improvement. Firms that merely deploy a tool into an existing process plateau at 5–10%. The key differentiator is digital maturity before deployment — the study by McElheran et al. shows that firms with existing digital infrastructure benefit significantly more.

In the long term, historical precedents show an overall productivity improvement of tens of percent, but spread over a decade and conditional on a fundamental redesign of how work is organized.

And what to measure? Certainly not lines of code per hour or the number of drawings per day — those are metrics that the tools distort. Meaningful indicators are end-to-end: the number of features delivered per sprint, the total time from request to delivery, the share of errors that make it into production, the rework rate, and the time from investing in the tool to a measurable benefit.

The first step should be to map the breakdown of working time before deploying the tool. Where do people actually spend their time? Amdahl's law says unambiguously: optimize what takes the most time — not what is easiest to speed up.

Conclusion

Next time someone promises that a new tool will "10× productivity," it is enough to ask for two numbers: what share of the work the tool covers, and what happens to the rest. The answer will almost always be more sober than the marketing material says — but also more realistic than the disappointment that arrives six months later.

Real productivity gains do not come from faster tools. They come from changing how work is done — and that takes years, not quarters.

Methodological note: The analysis draws on empirical studies published between 2019 and 2026. Main sources: METR 2025 (randomized controlled trial, 16 developers, 246 tasks — Becker, Rush, Barnes, Rein), Faros AI Research Report 2025 (telemetry from 10,000+ developers across 1,255 teams), McElheran, Yang, Kroff, Brynjolfsson 2025 "The Rise of Industrial AI in America" (U.S. manufacturing firms, Census Bureau data, the J-curve), Brynjolfsson 1993 (the productivity paradox), Clockwise Engineering Meeting Benchmark 2022 (1.5 million meetings, 80,000 engineers, 5,000 companies), Tidelift/New Stack Developer Survey 2019 (approx. 400 respondents), Microsoft Research "Time Warp" 2024/2025 (484 Microsoft developers), Atlassian Blog 2026 (application of Amdahl's law to AI). The estimates for mechanical engineering are based on a cross-section of industry data and are not backed by a single study of comparable scope — this is a limitation of the analysis. The numerical values from Amdahl's law are exact calculations from the formula, not estimates.

The concept, structure, and editorial line of the article are the work of the author, who developed the content sketch, established the key theses, and directed the entire creative process. Generative AI (Claude, Anthropic) was used as a tool for research, fact-checking, and fleshing out the author's draft.

The author edited the outputs throughout, verified the key findings, and approved the final wording. No part of the text was published without human oversight. All factual data were verified against the publicly available sources cited in the text.

The process complies with the requirements of Article 50 of EU Regulation 2024/1689 (the AI Act) on the transparency of AI-generated content. #poweredByAI