Have you ever noticed that the more technology advances and saves resources, the more we seem to consume?
Well, this contradiction isn’t new. Back in 1865, British economist William Jevons noticed something: while steam engines became more efficient and used less coal, total coal consumption didn’t drop — quite the opposite. As energy became cheaper, the industry found lots of new uses for it, causing the demand for coal to skyrocket like never before. This phenomenon became known as the Jevons Paradox (or, more popularly, the rebound effect).
Fast forward to today, in the age of generative artificial intelligence, this same rebound effect governs software production. AI has drastically lowered the cost of generating code, creating boilerplates, and writing tests. However, Jevons doesn’t fail: with code becoming “cheaper,” the demand for it has exploded, and the volume of software and system complexity have soared. Projects that were previously shelved due to lack of budget or time - such as creating and testing entire microservices with small teams - have suddenly become viable.
The Developer’s Role
As a result, the true bottleneck of development has shifted. Writing code is no longer the hardest part. Today, the challenge of software engineering lies in orchestrating highly distributed environments, ensuring observability, handling security, and designing robust architectures.
The developer’s role has changed: we have become AI supervisors. But this comes with a high price, which we can call cognitive technical debt. When AI generates code that works on the first try, we tend to perform a superficial review, much like when we approve a colleague’s Pull Request without looking closely. Yes, I know you’ve done that too :P.
However, there is an important difference between producing software quickly and absorbing knowledge quickly. AI brutally accelerates the first process; the second remains limited by the human brain.
Previously, a developer spent hours transforming understanding into code. Now, they spend hours trying to transform automatically generated code into understanding. And this process is much slower, more tiring, and more treacherous.
By skipping the stage of “cracking your head” to design the solution, you lose the conceptual model of the system. Then, when things break in production, you are forced to reverse-engineer your own codebase to understand why that abstraction exists, what the original intention of that intermediate layer was, or why there are three different classes doing practically the same thing.
The most dangerous part is that, most of the time, the code isn’t even “wrong.” It compiles, passes the tests, and delivers the feature. The problem is different: no one really understands the system as a whole.
The Explosion of Disposable Software
There is another curious side effect to all of this: when the cost of creating software drops drastically, we start creating software for problems that perhaps shouldn’t even be solved with software.
We automate irrelevant tasks because now “it’s fast to do.” We create skills to clock in with a prompt, where before clicking a few buttons was enough. Internal tools emerge that live for only a few weeks, experimental APIs, and integrations that no one knows if they are still relevant, but stay there because “what if something breaks?”
Before, creating a new service required planning, alignment between teams, implementation, testing, infrastructure, and a dose of suffering. Today, a relatively good prompt and half an hour of refining responses is enough, and boom, another service candidate for technical debt is born.
The New Scarce Resource
For decades, development was primarily limited by the human capacity to write code. Now, the limit has shifted to our capacity to comprehend, maintain, and operate the absurd amount of code we can generate. We are entering an era where software is no longer scarce, and the scarce resource becomes understanding.
In this scenario, the value of a developer changes. The differentiator is no longer “who writes code faster” but “who can control complexity without losing understanding of the system.” Architecture, modeling, observability, debugging skills, and systems thinking are no longer secondary skills — they become the true core of modern software engineering.
In the end, code was never the final product. Code is just the mechanism that transports human understanding to the machine. And understanding is still expensive.
Jevons Paradox shows that efficiency rarely reduces consumption — it only shifts the scale of the problem. AI is not eliminating software complexity; it is allowing us to produce complexity at an unprecedented speed.