Every time we’ve made it easier to write software, we’ve ended up writing exponentially more of it.

Every time we've made it easier to write software, we've ended up writing exponentially more of it. When high-level languages replaced assembly, programmers didn't write less code - they wrote orders of magnitude more, tackling problems that would have been economically impossible before. When frameworks abstracted away the plumbing, we didn't reduce our output - we built more ambitious applications. When cloud platforms eliminated infrastructure management, we didn't scale

Addy Osmani argues that every time writing software gets easier, people end up building vastly more of it, not less. He frames the pattern with Jevons Paradox: when the cost to start something falls, demand balloons. This thread (see the original at https://x.com/addyosmani/status/2005768629691019544) traces the story from assembly to high-level languages, frameworks, and the cloud, and says the same thing keeps happening.

Start small. When assembly gave way to C and then Python, developers did not vanish. They solved problems that were previously out of reach. Frameworks that hid plumbing didn’t shrink teams — they let teams attempt bolder products. Cloud platforms that removed ops burdens didn’t reduce output — they enabled services that never would have justified a physical server.

The central idea is simple: the friction removed is often the activation energy to start a project, not developer skill. Think of that internal dashboard sitting on a wish list because it needed two weeks of work. Lower the build time to a few hours, and suddenly it exists. Lower the cost tenfold, and an entire backlog becomes viable. Addy points out that AI-assisted development is lowering costs in a similar, but even more dramatic, way.

There are second-order effects too. More apps means more monitoring, more testing, more deployment tooling. Ecosystems multiply. For engineers, the real shift is in what’s scarce: not the ability to implement, but imagination and judgment about what to build (and what not to).

Readers who’ve shipped features in small teams will recognize this pattern (it’s one of those things you only notice after a few painful rewrites). The takeaway is optimistic: when tooling frees people, they don’t do less, they do more that matters. The question moving forward won’t be whether machines replace knowledge workers, it will be what new problems teams choose to solve now that cost is no longer the limit.

Kommentar abschicken