There's a growing consensus that the winner of the AI revolution will be the engineer with the best model.
The logic seems sound. Better models mean better code, which means faster delivery, which means more competitive advantage. So we're in an arms race for context windows, reasoning capability, and parameter counts, all on the assumption that the biggest model takes the prize.
I don't buy it.
I've watched mediocre engineers, armed with frontier models, generate thousands of lines of code in an afternoon. High-velocity, syntactically perfect, utterly disconnected garbage.
I've also watched experienced engineers, using much smaller local models, build resilient distributed systems that survive years in production.
The difference wasn't the quality of the output. It was the quality of the input.
Code is becoming a commodity
We're approaching a reality where code itself is a commodity.
When the cost of generating a function or a boilerplate microservice drops to near zero, the value of that output drops with it. If anyone can generate a working rate limiter in ten seconds, "writing the code" stops being an advantage. It's just the baseline.
If you're competing on the ability to produce lines of code, you've already lost.
That's a race to the bottom, and the winner is whoever can hit "generate" fastest. This is the same force I keep pointing at from other angles: AI didn't eliminate engineering, it changed the bottleneck. The typing got cheap. The cheap part is never where the advantage lives for long.
The real bottleneck is understanding
The industry is optimizing the wrong constraint. We're obsessed with the expression of logic when we should be obsessed with the intent of logic.
Writing code was never the expensive part of software engineering. The expensive part is understanding.
- Understanding the problem. Does this feature actually solve a user's pain, or are we just automating a broken manual process at high speed?
- Understanding the trade-offs. We can reach for a relational database here, but if we do, we give up a specific way of scaling horizontally. Does the business value of that scale justify the complexity of the distributed alternative?
- Understanding the failure modes. What happens when the network partitions? When a downstream dependency hits a micro-burst of latency? When the state goes inconsistent and nobody notices for an hour?
A frontier model can generate the feature. It can implement a gnarly algorithm. It can even pass the unit test.
What it cannot tell you is whether that feature should exist. It cannot tell you that you've just introduced a second source of truth that will quietly corrupt your data for the next two years. It cannot tell you that the architecture it just proposed will buckle when volume triples next quarter, because architecture is what happens after success, and the model has never been paged at 3am for a design that worked fine in the demo.
From writers to judges
As code gets cheap, the engineer's job shifts. We're moving from writers of code to judges of code.
The value is migrating upstream, away from the editor and into the design phase, the boundary definition, the system modeling. It's the same migration I've described from the review side, where the review moved up the stack from "is this code correct" to "is this the right thing at all," and where code review is moving upstream to the conversation before anyone opens an editor.
In the age of AI, the "senior" in senior engineer won't be measured by how much code they can review. It'll be measured by how much complexity they can prevent from being written in the first place.
The models will keep getting better. Smarter, faster, more capable. But they will never replace the person who understands why we're building what we're building, and more importantly, why we shouldn't.
The one-line version
The code is becoming a commodity. The understanding isn't. Bet on the second one.