Jevons paradox and the demand explosion
When a technology makes something dramatically cheaper to produce, demand for that thing tends to explode, not collapse. When web development replaced thick-client programming in the 1990s, it didn’t eliminate developer jobs — it expanded them by orders of magnitude because the addressable market for software grew faster than the productivity gain.
The same dynamic is already visible in AI-assisted development. Code generation is getting cheaper. The result isn’t fewer projects — it’s more projects that previously couldn’t justify the development cost. The demand for people who can architect those projects, understand their constraints, and make the judgment calls that AI won’t is growing with it.
What frontier models measure on benchmarks is pattern recognition. What novel problems require is judgment. Those are different things — and the models that score highest on standard benchmarks fail at roughly one-tenth the rate on genuinely unseen problems.
System-level thinking is what compounds
An AI can generate a working function. It can’t reason about whether that function belongs in the architecture you’re building, whether the interface it exposes will create maintenance problems in six months, or whether the constraint it assumes is actually guaranteed by the calling code. That’s system-level thinking, and it’s what separates the developers AI makes more productive from the developers AI makes overconfident.
The discipline that builds it: write small, focused, single-purpose methods. Be explicit about input contracts and return values. Name things for what they do, not what they contain. A codebase that AI can navigate correctly is also just a good codebase.
The best use of AI in development is as a thinking partner, not an answer machine
There’s a meaningful difference between asking an AI to generate a solution and asking it to pressure-test your thinking. “Here’s my approach to this problem — what’s the failure mode?” produces more durable work than “write me a function that does X.” The first use builds your understanding while generating useful output. The second generates output that may or may not fit the problem you actually have.
What this means practically
Use AI heavily for the mechanics: code generation, refactoring, writing tests for a behavior you’ve already specified, searching the codebase for relevant patterns. These are tasks where the AI is fast and accurate and the cost of a wrong answer is low because you have the judgment to catch it.
Stay in the seat for the judgment calls: architecture decisions, constraint identification, the question of whether the solution to the stated problem actually solves the real problem. These are the tasks where the AI is fast and confident and the cost of a wrong answer is high because it compounds into the codebase.