Cheaper code won't kill software development

Thanks to generative AI and AI agents, producing code is becoming cheaper than ever. However, as Thoughtworks' Chief Architect Chris Ford has been reflecting recently, when things get cheaper, the consequences can be more complex than we might initially anticipate.

In 19th-century Britain, people worried the country would run out of coal. Then James Watt built a better steam engine, one that squeezed far more useful power from every lump. The mood lifted: surely the reserves would last longer now?

The economist William Stanley Jevons predicted that the opposite would happen. The more efficiently Britain burned coal, the more coal it burned. Cheaper steam power made new uses for steam worthwhile, and extra demand outweighed the savings. We now call this the Jevons paradox.

I believe we're living through our own version, for the software industry. In this framing, the coal is us: our time, our skill, our hours at the keyboard. The steam is the code we produce, which we can produce more cheaply thanks to coding agents. Code is one of the most expensive and most important inputs in our industry, and when an input like that changes price, everything built around it shifts too.

I've spent many years at Thoughtworks, and my work has evolved gradually from writing code toward shaping projects before they start: how to divide up a problem, which tools to use, what skills a team needs. I'm now writing a book on agentic engineering at scale, and I spend much of my week with CTOs, engineering directors and architects who are deciding how to respond. 

What follows are the trends I see them planning around, ordered from what's happening now to what's still speculative. Whether you agree with me or not, it's worth forming a view, because expectations shape the economy we work in. Every one of these predictions has been seriously raised with me by a tech CTO or engineering directors. If enough leaders believe something will happen, they will act on it and at least try it.

What's already happening in the software industry?

Software is getting more niche

When a project took six months and 10 people, you had to be very sure it was worth it. That threshold kept many ideas from ever getting built. Lower the cost and the threshold drops with it. Developers build tools to scratch their own itch. Teams that ran a workflow from a spreadsheet now use a coding agent to build an app for it. If you can automate something by asking an agent to make it, that may now be worth doing when it wasn't before.

The flip side of this phenomenon affects everyone who supports software. If you work in information security or operations, you're watching new applications appear everywhere, built by everyone. It's an exciting time and a stressful one, and one that requires new forms of governance and oversight. As my colleague Lilly Ryan recently discussed, it's crucial to strike a balance between enabling innovation and ensuring quality in software. 

The bottleneck is moving from building to validating

Prototypes used to contain a small fraction of what the real system needed. Their job was to inspire people and win funding. Now it's easy to produce rich, polished prototypes that contain more than the real system will ever need. We can build almost anything we imagine, and what we struggle with is finding out whether it's right. I'd encourage teams to track validation debt as seriously as technical debt. Cheap code speeds up exploration, but only if we check ideas against real users and real needs.

What are we beginning to see?

A reckoning for low-value SaaS

The claim is that software as a service is dead, because anyone can show a coding agent a product and ask for a version tailored to their own process. I think the substitution is real, but only for the weakest products. If a subscription exists only because running the code yourself was a hassle, customers will start asking why they're paying when a few tokens can create a substitute.

SaaS that comes with real expertise, service guarantees you couldn't match or a physical operation behind it should hold up. Parcel delivery isn't a tracking website. It's all the logistics behind it. And many things we build with agents will lean on SaaS products for extra capability. Expect turmoil, not extinction.

A triple calculation

Technology leaders have long weighed whether to buy software or build it. Now I hear them weigh three things: spend on people, spend on software and spend on tokens. Some ask whether they want a team of 10 or a team of nine with a large token budget. That sits uncomfortably with me, because it turns colleagues into a line in a spreadsheet. But these calculations are happening, so you should know about them. Projects will increasingly need to estimate tokens as well as time.

The junior developer question

Every senior developer was once a junior, so this one is personal. The data is mixed: some charts show younger people leaving the industry, and other datasets show nothing of the kind. The outcome isn't written yet, and I see three paths.

Medicine offers the first. Experienced doctors are more valuable than juniors, yet the profession built training hospitals so expertise keeps getting cultivated. The nuclear industry offers the second. When new builds dried up, so did the pipeline of people who knew how to do them, and restarting means skills shortages and delays. Drifting into that outcome is a real risk. It might even suit those of us who are already well paid, but it would hurt the industry.

The third path is the one I want. We keep refining collaboration practices such as mobbing so junior colleagues add real value in teams. I've been on many teams where someone in their first year contributed a great deal because they saw what the rest of us couldn't. If we become atomized individuals, each paired with an agent, we lose that. If we protect group practices, companies have a reason to hire juniors because of what they bring. It won't be easy, and I can't tell you where the industry will land.

What does the future look like when code is cheap?

Cloning gets cheap 

Imitation is something coding agents do well. Point one at a working system, tell it to build something that behaves identically and keep going until it does. That erodes the moat around complicated software built up over years.

Two examples show what's possible. The maintainer of chardet, a Python library that detects file encodings, used a clean-room reimplementation to rebuild it from scratch with the help of Claude and then released it under a different license. The original author, Mark Pilgrim, disputed its legitimacy, but technically it worked.

Elsewhere, maintainers of the JavaScript runtime Bun used coding agents to rewrite roughly 500,000 lines of Zig into about a million lines of Rust in 11 days. This, too, came in for criticism, this time from the creator of Zig, but again, the rewrite did work.

Now, I'll admit I don't know whether the doubling in size signals lower quality or reflects Rust's extra type checking. Either way though, the important point here is that owning complex software won't protect you if someone can rebuild it.

Novelty becomes the moat

If everything reproducible is cheap, the valuable thing is whatever can't be reproduced. Two of the clients I work with have data scientists building models from the company's own data and domain knowledge, then handing them to software teams who put that knowledge into practice. The resulting software does something others can't easily copy.

In Team Topologies terms, I think this looks like a new team type alongside stream-aligned, platform, enabling and complex-subsystem teams. A team whose job is to produce new knowledge can't be held to deadlines the same way, and it hands over its output differently. I expect more companies to build teams like this.

Software will be regenerated, not updated

The more ambitious idea is to escape the cycle of accumulating technical debt and rebuilding by regenerating software from specifications. You write specs and guardrails complete enough that new behavior means changing the spec, and the change cascades through.

Several platforms do versions of this today. People who love working directly with code often dislike the idea because it takes away control over quality. It remains contested. But if it works at scale, software production will look much like a 19th-century factory: sensors detect the state of the running system, a controller adjusts, and control theory, which runs from Watt's engine to self-driving cars, becomes part of how we build.

Wirth's law comes for quality 

Hardware has become dramatically faster over our careers, but software hasn't felt faster, because we've written more wasteful software to use up the gains. Wirth's law says the limit isn't how fast we can make things but how slow users will tolerate. I fear the same applies to quality.

In my experience, coding agents can lead to better software. You have time to add formal models, extra kinds of testing and scanning you'd otherwise skip. We could see fewer crashes and fewer baffling interfaces.

However, if companies answer a quality gain by asking for more speed, we end up where we started. Avoiding that takes a cultural shift, from craftspeople, from companies and from users who demand better. Otherwise the industry will drift toward the lowest quality it can get away with.

How do you judge code and software quality at this pace?

Someone recently asked me how you judge quality at this pace. My answer is that quality itself shifts. It stops being about what looks elegant to a developer and becomes whether a coding agent can keep working effectively in the code base. 

You can test that. Ask an agent to make a change and watch whether it burns through tokens or gets confused. As a bonus, an agent in a tidy code base uses fewer tokens, so cost and quality may pull in the same direction. I hope so, though I can't promise it.

Painful lessons may lie ahead

The most out-there prediction is the one most likely to be tried. CTOs often command huge budgets and hundreds or thousands of engineers, yet can't swarm them onto the company's top priority, because almost everyone is tied to a system they own. There's plenty of talent and very little liquidity. We tie people to systems because maintaining software has meant someone knows it intimately, with knowledge handed over through onboarding and pairing.

Now imagine scale-to-zero ownership: systems that, at a given moment, no human understands well enough to support. Get it wrong, and you've created extreme legacy code with nobody to maintain it. Get it right, and you keep a skeleton crew per domain. When an incident or a new request arrives, good harnesses and documentation help someone rebuild the knowledge fast. 

That works for simple cases. Companies will try it on bigger ones, because the incentive to free up engineering talent is enormous. Expect much lower baseline ownership over the next few years, and expect some painful lessons. I'd ask that nobody misuse this idea.

What you can do

Jevons paradox suggests software development won't disappear. If doing more with software gets cheaper, software becomes more valuable, and use cases that were too expensive become viable. That's the good news for our economic niche.

The harder news is that when a commodity this important changes value, categories get upset. Software development will matter more, but whether it looks the same as a career next year or the year after is far less certain. Product and engineering roles may merge. Teams may consist of architects directing agents.

Become a problem solver who understands code, rather than someone whose career is tied to a particular technology. That's a portable skill. It's also a more fulfilling way to work, because your satisfaction comes from solving the problem, not from the artifact along the way.

This article was adapted by humans and AI from a talk given by Chris at XConf 2026.