Skip to content
TwinTeams
Position

Jevons paradox and the demand for experienced developers

This is a position rather than a finding: we think AI raises the demand for experienced developers instead of lowering it, because the constraint moves from producing code to deciding what to build and getting it approved. Here is the reasoning, the evidence against it, and what it means for how we build teams.

·

What Jevons noticed about coal.

In 1865 the economist William Stanley Jevons observed that as steam engines became dramatically more fuel-efficient, Britain burned more coal, not less.

Efficiency lowered the cost of using coal, so more uses became worth paying for, and total consumption rose. The saving per unit was real. It was swamped by the growth in units.

The argument returned to technology when Satya Nadella quoted it as DeepSeek shipped: “Jevons paradox strikes again! As AI gets more efficient and accessible, we will see its use skyrocket.” It has been argued over widely since, including on NPR’s Planet Money.

What we think it means for software.

Writing code is getting cheaper. We think that raises the demand for experienced developers rather than lowering it, because it moves the constraint rather than removing it. Software stops being limited by how fast code can be produced and starts being limited by deciding what to build, and by getting it into production safely.

Senior developers are more experienced. They need less direction, they catch problems earlier, and they get more done. Both of the new constraints are made of exactly that.

It is also why the teams we build are five senior developers rather than ten mixed ones, and why every developer is recruited against the same standard. If the binding constraint is judgement, buying more hands does not move it.

A process moves at the pace of its rate-determining step.

Chemists have a name for this. In a sequence of reactions the slowest one, the rate-determining step, sets the rate for the whole thing, and making any other step faster changes nothing.

Delivery works the same way. Making a step faster only speeds up the process when that step was the one holding everything else up.

If code production becomes five times faster but the work is waiting on a specification nobody has written, a decision nobody has taken, or an approval nobody has signed, delivery does not move. The constraint relocates. It does not disappear.

What is left when writing the code gets cheapThe same five delivery steps shown twice: design, specify, write the code, review and manage. Every step except writing the code is marked as senior developer work. In the first row, writing the code is the longest step. In the second, writing the code is five times faster, but because it produces more code there is more to design, review and manage, so those steps are longer. The work that grows is the work experienced developers do. Step widths are illustrative, not measured.EVERY STEP BUT ONE IS SENIOR DEVELOPER WORKWRITING THE CODE IS THE LONGEST STEPDESIGNSPECIFYCODEREVIEWMANAGECODE FIVE TIMES FASTER · MORE OF IT TO DESIGN, REVIEW AND MANAGEDESIGNSPECIFYCODEREVIEWMANAGEMore code means more design, review and management. That is senior work, and there is more of it.
What is left when writing the code gets cheap
What is left when writing the code gets cheapThe same five delivery steps shown twice: design, specify, write the code, review and manage. Every step except writing the code is marked as senior developer work. In the first row, writing the code is the longest step. In the second, writing the code is five times faster, but because it produces more code there is more to design, review and manage, so those steps are longer. The work that grows is the work experienced developers do. Step widths are illustrative, not measured.EVERY STEP BUT ONE IS SENIOR DEVELOPER WORKWRITING THE CODE IS THE LONGEST STEPDESIGNSPECIFYCODEREVIEWMANAGECODE FIVE TIMES FASTER · MORE OF IT TO DESIGN, REVIEW AND MANAGEDESIGNSPECIFYCODEREVIEWMANAGEMore code means more design, review and management. That is senior work, and there is more of it.
Illustrative, not measured. The point is the direction: writing the code is the only step that shrinks, and producing more of it leaves more to specify, review and manage.

Teams answer that by going deeper and automating more of it: more tests, more static analysis, more checks in the pipeline. That is the right response, and it relocates the work again rather than removing it. Choosing what to verify, how deeply to verify it, and whether the result is good enough to ship is judgement, and it stays with people.

This is the part we think matters more than Jevons itself, because it predicts something specific: wherever a step cannot be automated, that step becomes the pace of the whole thing.

In regulated work, the slowest step is a person on purpose.

Change approval, risk sign-off, audit evidence and compliance review exist because somebody accountable has to put their name to them. That is the function, not an inefficiency in it. So in financial services, healthcare and government work, cheaper code production pushes the constraint straight onto the human checkpoints, and those checkpoints need people who understand both the system and the controls.

We see this in the Australian market directly. Banks and financial institutions here are hiring at staff and principal level, the rungs above senior, where the work is architecture, standards and sign-off rather than volume of code. That is our own observation from the market rather than a published figure, but it is the pattern this argument predicts: when producing code stops being the constraint, hiring concentrates at the levels that decide and approve.

It is the reason our developers are employees on contracts rather than contractors, working on company-owned machines under management, inside the customer’s own systems and policies. Someone has to be accountable at the step that exists to have an accountable person.

Other ways of reading the data.

Three readings run the other way.

Demand for software may be closer to satisfied than unlimited. Jevons held for coal because cheaper energy unlocked enormous new uses. If most of the software people want already exists, cheaper production shrinks the work rather than growing it. Our experience is the opposite, because every company we work with has a backlog it cannot fund, but that is our sample rather than proof.

AI may substitute rather than complement, and the balance will differ by role. A tool that makes an experienced developer faster increases demand for them. A tool that does the whole task removes it. We expect substitution at the routine end and complement at the senior end, which is another way of saying the constraint moves to judgement.

Reductions attributed to AI are real. In Australia, 3,610 roles had been cut with AI named explicitly as the driver as at 2 August 2026, and 11,934 counting reductions with mixed attribution. The index does not break those down by function, so they are not evidence about developers specifically. They are not nothing either.

None of this changes what we would do about it. If the work that remains concentrates in judgement, the team you want is small and experienced. If we are wrong and software demand is close to satisfied, you want fewer engineers than you have, and you still want them to be the experienced ones.

Five seniors, because judgement is the constraint.

We build dedicated development teams in Vietnam: five senior developers minimum, recruited for the roles you name, working for one customer only, on twelve-month terms. You interview every hire, and each team has its own tech lead. The commercial terms are on hire dedicated developers.

If we are wrong about this, a cheaper team of less experienced developers would be the better buy. We have built the company on the view that it is not. Build your team to tell us what you are working on.

Frequently asked questions

What is Jevons paradox?

An observation by the economist William Stanley Jevons in 1865: as steam engines became more fuel-efficient, Britain consumed more coal rather than less, because efficiency made more uses worth paying for. It is quoted in technology to argue that making something cheaper can increase total demand for it.

Does AI reduce the need for experienced developers?

Our position is that it does not, because the constraint moves rather than disappearing: from producing code to deciding what to build and getting it approved, both of which need experience. This is a belief rather than a settled finding, and the case against it is real, including 3,610 Australian roles cut with AI named explicitly as the driver, as at 2 August 2026.

Why does this matter in regulated industries?

Because change approval, risk sign-off and compliance review exist so that an accountable person puts their name to a decision. That step cannot be automated away without removing its purpose, so cheaper code production pushes the constraint onto those human checkpoints.

Why five senior developers rather than a larger mixed team?

If the binding constraint is judgement rather than the volume of code produced, adding less experienced people does not move it. Senior developers need less direction, catch problems earlier and get more done, which is why the team is sized the way it is.
Next step

See what a TwinTeams engagement includes.

Senior engineers who become part of your team: one contract, one invoice, twelve months minimum.