AI Will Make Code Cheap, But It Won’t Shrink Most Engineering Teams

Rajesh Rajagopalan is CTO of Winter.

gettyAs a leader in a technology company or role, you may be asking yourself: If agents are writing code, we’ll need a fraction of the engineers, right?

It’s a fair question. But my honest answer, for most enterprises, is probably not. Here’s why, and where I could be wrong.

The same assumption came up about coal.

In 1865, the English economist William Stanley Jevons published The Coal Question. Britain feared running out of coal, and many assumed more efficient engines would solve it. Jevons pointed out the opposite: As coal-powered work got cheaper, it spread into more industries, and the total coal use kept climbing. In his words: “It is wholly a confusion of ideas to suppose that the economical use of fuel is equivalent to a diminished consumption. The very contrary is the truth.”

That’s the Jevons paradox. Make something cheaper to use, and if enough demand is waiting, you end up using more of it.

I think code is going through the same thing.

It’s already happening one layer down. This summer, AI token prices fell by more than one-third while GPU rental prices held, according to market data compiled by Citadel Securities. Cheaper inference didn’t mean less compute. People used more of it.​​

Every enterprise I’ve worked with has two backlogs of projects. There’s an official one. Then, there’s a much bigger one that never got written down because nobody thought these were worth the money or time​.

• Needed Internal Tools That Were Put On The Back Burner: When you have approvals that run through a chain of emails or reconciliations that someone does by hand every month-end, you need a better process. But everyone is used to the manual fixes, so they make do.

• Modernization Efforts That Are Always Pushed Back To “Next Year”: You might have a core system on a database that’s full of stored procedures written by people who left a decade ago, but nobody wants to touch it.

• A Long Tail Of Spreadsheet Workflows: The operations analyst pulls reports, fixes them up in Excel and keys them into another system. There are thousands of these, but each are too small to justify a project.

The benefits are clear, but these needs didn’t justify the cost and the risk, so the business case was never made.

That’s changing. Across the modernization programs we’ve delivered over the last 18 months, engineering effort has come in about 70% lower than it used to. Not all of that is the tooling; good teams matter a lot. But modernization also changes which programs make sense.

And the demand is growing. At one of our clients, an agentic order-entry system built for one division worked well enough, and cheaply enough, that a second division funded its own program soon after. Work that used to be “nice to have, can’t justify” turns into “Why haven’t we started?”

That’s the Jevons moment for software: The forgotten backlog starts showing up as real demand, and someone has to build and run it.

Every piece of software you build is something you now have to maintain, secure and operate. That’s more access to manage, more dependencies to patch and more to monitor and support. The operations side doesn’t shrink because the build side got cheaper. It grows with it.

Much of that work will be agentic too. But someone still has to design those loops and decide what counts as an exception.​

If writing code isn’t the expensive part anymore, what is? It’s two things: deciding what’s worth building, and judging whether what got built is right.

Earlier this year, I wrote about how, once engineers start directing agents, value moves upstream to intent and downstream to validation. The danger is shipping more things nobody validated.

So, the work I see growing is specification, validation and architecture. Someone has to know the business rules well enough to write them down. Someone has to decide how a new service fits with the 20 others around it. Someone has to own it when it breaks at 2 a.m.

Agents can generate the code. They can’t be accountable for it.

Jevons isn’t a law of nature. It only holds when demand grows faster than the cost falls.

And the bar is high. If a program takes 70% less delivery effort, a company has to build more than three times as much software just to keep the same number of build hours. A backlog proves there’s demand. It doesn’t prove there’s three times more of it.

My bet is that most enterprises will clear that bar. But some will build the same portfolio with a smaller team, and that’s a legitimate choice.

The other caveat is about people. Total demand for engineering can grow while specific roles shrink. Coal use rose in Jevons’ time, but that didn’t help every worker tied to the old way of doing things. More software doesn’t automatically mean a better job for every engineer.

Back in 2023, I wrote about skills with different half-lives. Some are perishable, such as a specific framework or syntax. Others are durable, like understanding how a business process works and judging quality. The durable ones are exactly what companies need.

When a CIO asks me how many engineers they’ll need, I ask a different question first: What would you build if building were cheap? Most have been carrying that list for years. Go back through the ideas you turned down, and give each one an owner who’ll run it, not just build it.

Cheap code doesn’t shrink the work. It shows you how much you left undone.​

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?