When Code Generation Gets Cheap, Which Skills Go Up in Value — What Depreciates and What Appreciates

Introduction — Asking the Right Question
The Mechanism — Bottlenecks Don't Disappear, They Move
What Depreciates — Things That Were Proxies for Value, Not Value
What Appreciates (1) — Verification: Not Skimming Diffs, but Supplying the Ground Truth
What Appreciates (2) — Debugging Production: When the Context Is Implicit
What Appreciates (3) — System Design and Taste in Tradeoffs
What Appreciates (4) — Requirement Archaeology: Knowing What to Build
What Appreciates (5) — Ownership: Being Someone Who Can Carry the Pager
The Counter-Argument — "Won't AI Just Do the Verification Too?"
Closing
References

Introduction — Asking the Right Question

"Will AI replace developers?" is the wrong question. It treats "developer" as a single skill. In reality a developer is a bundle of a dozen or so skills, and the items in that bundle are being repriced at different rates right now. Some are converging on zero. Some are going up.

So the real question is this — which items in the bundle are getting cheap, and where does their value go? That is not a matter of taste. It is a fairly boring question in economics, and the skeleton of the answer already exists.

The Mechanism — Bottlenecks Don't Disappear, They Move

When one stage of a process gets cheap and abundant, the bottleneck does not vanish. It moves to the next stage. And value accrues wherever the bottleneck sits. When generation gets cheap, value moves to what comes after generation — confirming the thing is correct, deciding what to build, wiring it into someone else's system.

Jason Wei has sharpened this intuition on the AI side better than anyone. His asymmetry of verification is simple — some tasks are far easier to check than to solve. Solving a sudoku takes a while; checking a finished grid is instant. From this he derives verifier's law — "the ease of training AI to solve a task is proportional to how verifiable the task is." Put more bluntly: all tasks that are possible to solve and easy to verify will eventually be solved by AI.

Most people read that law as a list of things AI will get good at. Reading it backwards matters far more. If everything easy to verify gets automated, then what is left for humans is precisely the work whose verification is expensive, slow, subjective, or has no answer key at all. That is not a consolation prize. It is a prediction.

And the bottleneck has, in fact, already moved.

DORA 2025 reports that roughly 90% of technology professionals now use AI. But the finding is a strange one — AI adoption has flipped to a positive relationship with throughput, while delivery instability keeps climbing. DORA's own summary is that AI acts as an amplifier, magnifying an organization's existing strengths and weaknesses alike. Raise speed without raising quality control and the bottleneck simply gets shoved downstream.
LinearB's 2026 benchmarks show exactly where downstream is, in numbers. Across 8.1 million pull requests from more than 4,800 organizations, AI-generated PRs wait 4.6x longer to be reviewed. PRs opened by agents have a pickup time 5.3x longer. Acceptance rates trail human code badly — 32.7% versus 84.4%. Generation exploded, and a queue formed in front of review.
Why that queue doesn't drain is explained by Stack Overflow 2025. 84% of developers use or plan to use AI tools, and more than half use them daily. Yet the number one frustration is "AI solutions that are almost right, but not quite" (66%), and number two is "debugging AI-generated code is more time-consuming" (45.2%). Only 3.1% report high trust in the accuracy of the output.

That last item is the hinge of this entire essay. Almost-right code is more expensive than wrong code. Wrong code gets filtered immediately. Almost-right code passes the glance, passes review, passes staging — and then detonates in production. The cheaper generation gets, the more of this arrives, and the faster. Verification cost scales with volume generated. Verification capacity does not.

What Depreciates — Things That Were Proxies for Value, Not Value

Let me name them plainly.

Memorized framework APIs. The model has read the docs more accurately and more completely than you have. The premium attached to remembering signatures is gone.
Boilerplate throughput. CRUD scaffolding, DTO mapping, config files, test fixtures — the arena where people competed on output per minute.
"I type fast" productivity. Typing speed was never actually the bottleneck, but there was a time it still got priced.

Here is what matters: these skills were never value in themselves. They were proxies for it. They were priced because they were scarce back when generation was the bottleneck. Remove the scarcity and you remove the price.

But depreciating is not the same as worthless. You cannot review code you cannot read. If you don't know the language and don't know the framework, none of the appreciating skills below can even start. The floor is still required. The floor is just an entry ticket now, not an advantage.

What Appreciates (1) — Verification: Not Skimming Diffs, but Supplying the Ground Truth

Clear one misconception first. The verification skill that appreciates is not "the diligence to read a diff carefully." Machines already do a great deal of that. Linters, type checkers, static analysis, AI review bots — a missing null check and an obvious race condition are on the easy-to-verify side of the line, and by verifier's law that side keeps getting automated.

What goes up in value is the part machines cannot supply — the ground truth itself. Deciding what "correct" even means for this system, in this business, at this scale. A model can make the tests pass. It cannot decide which tests should exist, because that is a fact about the business, not a fact about the code.

How to build it deliberately:

Write the pass condition before the model writes the code. If you cannot state the pass condition in a sentence, you don't have a requirement. You have a wish.
Review with a hypothesis. Before you open the diff, write down three ways this change could break production. Then go hunting for those. Reviewing without a hypothesis is spellchecking.
Keep a bug ledger. For every production bug, write one line: what check would have caught this? That list is the set of tests you don't have.
Train yourself to separate "passes the tests" from "is correct." Designing an evaluation is a skill in itself, and it is exactly the problem covered in separating signal from noise in coding evals — only a difference bigger than the noise is signal.

What Appreciates (2) — Debugging Production: When the Context Is Implicit

METR's randomized controlled trial is the most useful evidence here. Sixteen experienced open-source developers worked 246 real issues in their own repositories (averaging 22,000+ stars and over a million lines of code). Going in, they forecast a 24% speedup. Coming out, they felt they had been sped up by 20%. In fact they were 19% slower.

The reason is the decisive part. A mature repo you have worked in for years is close to a worst case for AI — the requirements are entangled with context that lives outside the repo, and the human is carrying an enormous store of local knowledge that was never written down. The model does not have it.

That is the shape of the moat. AI is weakest where the context is implicit and the failure is emergent. Production is exactly such a place. The bug is not in the diff. It is in the interaction between the diff and six years of accumulated decisions nobody ever recorded.

From my own experience — in the postmortem of KubeVirt GPU passthrough VMs that went 112 days without being scheduled, the cause was not in the repository. Nothing that only reads the repository could have found it. Same story with spinning up Postgres on CloudNativePG and killing it — you do not learn what failover actually does by reading about it. You learn it by killing the primary and measuring the 23 seconds.

How to build it deliberately:

Own an incident end to end and write the postmortem yourself. The learning happens in the writing, not in the firefighting.
Break things on purpose somewhere safe. Kill the primary. Fill the disk. Sever the network. Predict the outcome first, then measure. The gap between your prediction and the measurement is the error in your model of the system — and that model is the thing you are actually paid for.
Practice reading the system, not the code. Metrics, traces, kernel logs, events. Drill the loop: observe, hypothesize, experiment.
Debug code you did not write. This is the default now. The model wrote it. You own it.

What Appreciates (3) — System Design and Taste in Tradeoffs

A model will produce a plausible answer to any design question you ask. What it cannot do is pick which tradeoff your organization can live with for the next five years. That judgment depends on facts that are not in the repository — team size, on-call maturity, the migration you cannot afford, the vendor contract about to expire, the person who is leaving in six months.

Taste is not mystical. It is compressed memory of what blew up last time — a prior built out of consequences you personally absorbed.

How to build it deliberately: Read other people's postmortems (plenty are public). In every design doc, state explicitly what you are giving up. Write down at least two rejected alternatives and why you rejected them. Then reopen your own decisions twelve months later and grade them — without that feedback loop, taste does not grow; only stubbornness does.

One rule — a design doc with no rejected alternatives is not a design. It is a preference.

What Appreciates (4) — Requirement Archaeology: Knowing What to Build

The most expensive bug is the wrong thing, implemented perfectly. AI drives the cost of building down. Which also means you can now build the wrong thing much faster, and at much greater scale. So the ability to know what to build appreciates in exact proportion to how cheap building becomes.

Requirement archaeology is the work of excavating what people actually need out of what they said. Most real requirements are not written down anywhere. They are fossilized inside a 2019 if-statement nobody dares delete, inside a strange piece of exception handling, inside a default value in the system you are replacing.

For some roles, handling that ambiguity is the job itself — as I laid out in preparing to become a Forward Deployed Engineer, ambiguity there is not a side effect. It is the work.

How to build it deliberately: Sit next to users and watch what they actually do (it differs from what they say). Ask "what do you do when this fails?" — the real requirement usually lives in that answer. Pick the ugliest branch in the codebase and dig until you know why it exists (it is usually a requirement, not a mistake). Write a one-page problem statement before you write a design doc. And when you are going to be wrong, be wrong early, cheaply, and out loud.

You cannot put a model on the pager. Not because it isn't smart enough — because accountability requires a party that bears the consequences. Organizations want a name attached to a decision. They need someone who will wake at 3 a.m. and say "I'm rolling this back."

Be honest about what kind of claim this is. It is a social and legal fact more than a capability fact. The institutions could change. But social facts are stubborn, and they really do price labor.

Communication belongs here too. If you cannot explain a tradeoff to someone who cannot read code, you cannot get the decision made. The scarcer generation-adjacent work becomes, the more the scarce act is deciding — and deciding is inherently social.

How to build it deliberately: Take the pager. Raise your hand for the migration nobody wants. Ship something and stay attached to it for a year. The feedback loop where consequences actually reach you is the only place judgment grows.

The Counter-Argument — "Won't AI Just Do the Verification Too?"

This deserves a serious hearing. Building a weak version and beating it is self-deception.

The strongest form goes like this. Verifier's law says AI takes everything that is easy to verify — and a large share of review is easy to verify. Type errors, null dereferences, obvious races, style. AI review tools already do this well. Add test generation, fuzzing, and agents that actually execute the code and observe it, and a large share of verification does get automated. On top of that, even the METR result I cited above has been qualified by METR themselves — in their February 2026 update they announced they are changing the experiment design, and stated that as of early 2026 developers are likely more sped up than their early-2025 estimate suggested (while conceding their evidence for the magnitude is weak). So do not carry "19% slower" around as a permanent law. It was a measurement of a moment.

I concede all of that. Mechanical verification will be automated, and mostly it should be. If your "verification skill" amounts to catching a missing null check, that depreciates right along with the rest.

And yet a boundary remains. Verifying correctness requires a ground truth to check against. Where does that ground truth come from? Competition math and LeetCode have answer keys. Your company's billing system does not. Someone has to decide what correct means.

The cleanest evidence that this boundary is real comes from the DeepMind result — intrinsic self-correction, where a model revises its own answers with no external feedback, did not improve accuracy and at times made it worse. Improvement showed up only when the model was handed an oracle: the correct labels. That result is from 2023-era models, and models have improved enormously since — do not apply the specific numbers to today. But the structural point is not a function of model strength. A system checking its own beliefs against its own beliefs cannot manufacture a ground truth it does not possess.

Let me mark the uncertainty honestly. I do not know how far this boundary will move. If a model becomes better than you at deciding what "correct" means for your business, this essay's advice expires. I don't think that is close — I think the binding constraint is access to consequences, not intelligence. But "I don't think so" is a belief, not evidence. Hold it loosely.

If I had to bet, I'd bet here — even in a world where AI verifies most things, somebody still has to be accountable for the verdict, and accountability is what a job is.

Closing

Reject both poles.

"Developers are done" is wrong. It assumes the whole bundle repriced to zero, when in fact it repriced unevenly. "Nothing has changed" is also wrong — because the items many people built their careers on are precisely the items that got cheap.

Let me leave the uncomfortable part in, too. This repricing is especially harsh on juniors, because the depreciating skills were the bottom rungs of the ladder. Learning a codebase by grinding through boilerplate is a path that is closing. I do not have a clean answer for that. The best I have is get closer to consequences, faster — own something small in production and put yourself where you get paged when it breaks, earlier than feels comfortable.

The appreciating skills all share one property. Every one of them demands contact with consequences. Verification requires knowing what blows up. Debugging requires having been paged. Taste requires having been wrong. That is why you cannot download them. And for the same reason, they are hard to train into a model that has never once been paged.

One line — the price of writing code has fallen. The price of knowing whether the code is right has gone up.