AI Economics and Staying Relevant as an Engineer
In March 2023, GPT-4 cost $30 per million input tokens. It was the smartest model you could buy, and if you were wiring it into anything real, you rationed it. You cached aggressively. You trimmed prompts. You thought twice before sending a request.
Three years on, several models beat that original GPT-4 on every benchmark that mattered, and they cost under a dollar per million tokens. Some cost cents. The capability didn't get a little cheaper — it fell through the floor. Call it 10x a year, give or take, and nothing in the trend line suggests it's slowing.
Here's the take I'll defend: most engineers are responding to this curve by trying to get faster at the exact thing the curve is making free. That's the wrong move. The skills worth your scarce attention are the ones that never show up on a pricing page.
The wrong question
"Will AI replace me?" is the wrong question. It's unfalsifiable, it's paralysing, and it treats your job as one indivisible thing that either survives or doesn't.
Your job isn't one thing. It's a bundle of tasks, and the cost curve hits each of them at a different speed. The useful question is narrower and answerable: which of the things I do every day are on that curve, and which aren't?
Ruben Hassid frames the same problem for knowledge work generally in his piece on beating AI — the short version is that you don't beat the curve by outrunning it. You beat it by standing where it isn't. For engineers, that means knowing precisely where it is.
What's on the curve
On the curve: writing code from a clear spec. Recalling an API. Boilerplate. Translating a known pattern into a new language. Knowing a framework's idioms. Producing the first working version of something well-understood. All of it is getting cheap fast — not because AI is brilliant, but because these are exactly the tasks with abundant training data and outputs you can verify mechanically.
Also on the curve, and this is the uncomfortable part: tool fluency itself. Getting 20% faster with your AI editor, learning this season's prompt tricks — that's effort spent polishing the part that's getting cheaper and easier anyway. Models get more forgiving every release. The prompt craft that felt essential in 2024 is half-obsolete now. The junior-hiring squeeze everyone's noticed is just the curve reaching the most commoditisable rung first.
Not on the curve: deciding what to build. Turning a vague business need into a specification precise enough that the implementation is mechanical. Knowing which trade-off actually matters here. Evaluating whether an output is correct — not "does it run" but "is this the right thing, and will it hold under load and under the next person who touches it." Owning the outcome when it ships.
Those tasks aren't on the curve because they don't come with abundant clean training data, and they don't have a cheap verification signal. They're judgment. Judgment is still expensive.
The four minutes were never the hard part
Take a concrete task: "Add rate limiting to our API."
In 2021 that was half a day. Read the docs, pick a library, write the middleware, test it, handle the edge cases. Today an agent does the generation in about four minutes.
But the agent doesn't know you need per-tenant limits, not global. It doesn't know the limit has to survive a redeploy, so it can't live in process memory. It doesn't know the Redis instance you'd reach for is already at 80% memory. It doesn't know legal asked for the 429 response to carry a specific Retry-After header because of a customer contract. It doesn't know that the last person who touched this middleware took down checkout for nine minutes.
The four minutes of generation was never the hard part. The hard part is the context — a dozen constraints that live in your head, your incident history, your contracts, and three Slack threads. That part didn't get cheaper. If anything it got more valuable, because it's now the only part that's scarce.
This is the whole game. The cost curve didn't delete engineering work. It moved the work from typing to specifying and verifying. The engineers who feel faster this year are the ones who noticed and shifted their weight. The ones who feel threatened are still measuring themselves by how fast they produce code.
A prediction you can disagree with
Within three years, "fast, fluent coder" will be worth roughly what "fast typist" is worth today: pleasant, occasionally handy, and entirely absent from the conversation about who gets hired and paid.
What replaces it on your CV isn't a tool. It's a verb. I can take an ambiguous problem and a fuzzy stakeholder and produce a specification precise enough that any competent implementer — human or model — builds the right thing on the first pass. And: I can look at a working output and tell you whether it's actually correct, before it becomes a production incident.
Disagree if you want. You might think a specific language or domain is deep enough to stay scarce on its own — embedded work, say, or anything with hard real-time constraints and thin training data. You might be right, for a while. But notice that's the same bet, not a different one: you're betting on a place the curve hasn't reached yet. That's a fine bet. Just make it deliberately, and keep watching the curve.
Because here's the honest part. Specification and evaluation aren't permanently safe either. There is no permanently safe skill. The strategy was never "find the rock the flood can't reach." It's "keep your weight on whatever is currently scarce, and notice the moment it moves." Right now, scarce is judgment — specification and verification. That will hold for a while. It won't hold forever.
What to do this week
Pick one task you finished this week and split it down the middle. How much was generation — the part an agent could have done in four minutes — and how much was the context and judgment around it? If the ratio surprises you, that's the curve talking.
Then change one habit. Next time you reach for the AI, don't open with "write me X." Open by writing the spec: the constraints, the trade-offs, the done-criteria, tight enough that the generation is mechanical. You'll feel slower for a week. You're practising the part that's getting more valuable instead of the part that's getting cheaper.
And stop scoring your week in lines shipped or tickets closed. Start scoring it in decisions made that turned out correct, and outputs you caught that would otherwise have broken. That's the scoreboard the cost curve is dragging you towards. Better to start keeping it before your manager does.
The cheap part will keep getting cheaper. Let it. Don't optimise the cheap part — spend your scarce hours on the part nobody can put a price on yet.
Sources I drew from: