“100x Productivity Boost!” “AI replaced my whole team” “I built an app in a day from idea to production with vibe coding”. “Claude Code turned every engineer into three”.

The internet, especially the corners dedicated to geekdom, professional image building and technology news, is awash with headlines like these. These are illustrative examples, but they capture the rhetoric: AI is making us dramatically more productive.

These claims leave an important question unanswered: what improved across the whole system? Faster coding, fewer staff and better delivery are different claims, requiring different evidence. Making one part of software development faster does not automatically improve delivery as a whole.

I’m pretty left-leaning on economics, so perhaps it’s no surprise that I’m suspicious of the assumption that producing more is always better. But the question here is narrower: what happens when we apply that assumption to every part of a process?

That brings me to scientific management, developed in the late 1800s and early 1900s and often called Taylorism after its most influential advocate, Frederick Winslow Taylor.

In the most reductionist way possible: Scientific management analyses work as a sequence of measurable tasks so each can be studied, standardised, and enforced in a single “best” way. The promise is that breaking work down, measuring it and optimising each step will improve overall productivity. For a fuller introduction, see scientific management on Wikipedia.

Taylor wasn’t ignoring the need to coordinate work. Planning, training and cooperation between management and workers were part of his approach. In The Principles of Scientific Management, he also described prosperity in terms of minimising the combined expenditure of human effort, natural resources and capital. But he went on to describe maximum productivity as a state “when each man and each machine are turning out the largest possible output”. There is a tension here worth examining: maximising the output of each part need not minimise the costs or improve the results of the whole.

In the context Taylor was operating in, the late stages of the industrial revolution, when mass manufacturing and increasingly complex factories were becoming common, the prevailing industrial trends of the day were standardisation and mechanisation. It was understood and observed that if you can standardise a process, it becomes more routine and easier to remove waste from it. If you can then mechanise it, you enforce the standardisation and often achieve it faster and in ways that humans couldn’t.

The combination was a brutal 1-2 punch for productivity in a factory context. The tempting inference is that improving each process independently must improve the factory as a whole. This feels intuitively correct: if the system is a composition of the individual processes (“the sum of its parts”), local efficiency gains ought to add up to systems gains. This is the assumption: that the system behaves like a clean sum of its parts.

The tech industry, and software development in particular, has been arguing about individual productivity for years. What counts as being more productive, and does making each of us more productive actually improve the whole? Today’s AI productivity rhetoric is playing familiar tunes. In those opening slogans, speed and output stand in for value again. This is the part of Taylor’s argument I’m drawing an analogy with, rather than claiming his entire approach amounted to optimising isolated tasks.

Take a simple example: a laundry business replaces hand washing with washing machines. Each load takes less manual labour, and the initial wash finishes sooner. That looks like a productivity improvement.

But customers need clean, dry washing back. Two things can prevent the faster wash from improving the service as a whole: bottlenecks and rework.

It is unlikely that the washers and dryers will complete at the same rate, that loading and unloading can proceed at the same rate, that quality inspections can happen and take the same amount of time. This can lead to washing piling up before the dryer is ready to take the next batch. There will likely be industrial solutions to these problems, but the underlying principle of the theory of constraints stands: the bottleneck limits throughput - the number of loads completed per hour. Speeding up another stage won’t necessarily increase overall throughput, and may simply create a larger queue. That is a different measure from the elapsed time for a single load, and improvements elsewhere may still reduce costs, labour or defects.

There is another consideration: quality and rework. Implicit in the washing machine example is the assumption that the washing machine does the same work to at least the same standard as the human washer it replaces. If not, it could mean multiple trips through the washing phase.

Imagine each load used to need 3 hours of washing. With the new machine, half need 2 hours, but the other half need washing again and take 4 hours in total. The average washing time is still 3 hours per load. That excludes time spent waiting in queues, drying and handling: the customer’s turnaround time includes all of those too. Maybe this is OK if you look at costs other than just wall-clock time. For example, the input costs of the machine, electricity and water may still reduce total costs.

Suppose, for simplicity, there are no queues and drying and handling take another hour per order. You promise customers their washing back within 4 hours. Previously, every order met that deadline. Now half take 3 hours and half take 5: the average turnaround is unchanged, but half the orders are late. Worse still, focusing on the improvement from 4 hours to 3 for the successful first washes could lead you to believe you can take on more customers. If you fill that apparent extra capacity without accounting for rework, queues will build and customers will wait even longer. That could make the change worse for your customers despite any cost savings.

Faster individual stages are only part of the picture. We also need to measure end-to-end delivery, reliability and cost.

These ideas about constraints and flow are familiar in DevOps. The Phoenix Project, explicitly inspired by Goldratt’s The Goal, applies them to IT work: improving one team’s output is not enough if the whole system still cannot deliver. The Lean Startup makes a related argument about value, treating validated learning about customers as progress rather than simply producing more. Both offer reasons to question whether faster activity means better outcomes.

Now look back at those phrases from the top again. What do they tell us about useful, reliable software reaching users sooner? An app going from idea to production in a day tells us something about elapsed delivery time. Replacing a team tells us something about staffing. Neither tells us, on its own, whether the software meets users’ needs or what it will take to keep it working. And where the claim is about faster coding, did that relieve a bottleneck, or just move more work into the next queue? These slogans invite us to celebrate speed and output before asking what improved across the whole system. We have been here before.

DORA’s 2025 report, State of AI-assisted Software Development, supports this distinction. Over 80% of respondents report that AI has increased their individual productivity. That is a report of perceived improvement, rather than a direct measurement of how much more useful software reached users.

At the delivery level, the survey analysis found that higher AI adoption was associated with higher delivery throughput, but also greater delivery instability (pages 37–38 of the full report). Those associations do not, on their own, establish cause and effect.

DORA’s framing is that AI is an amplifier - it magnifies an organisation’s existing strengths and weaknesses. This points towards the importance of stronger organisational foundations, rather than tools alone.

The frustrating part is that smart people will agree with all of this, then post about their extraordinary productivity gains and declare that the role has changed forever. The systems thinking and the excitement never quite meet.

The test is whether the whole system delivers useful, reliable software with better outcomes for users, less effort or lower cost - not simply whether we can produce code faster.

Next time we’ll start to unpack the issues of what agentic coding is actually speeding up, and what it isn’t, to see whether the time saved comes with costs elsewhere.

Stay sane, and stay healthy.