Why Being a Programmer for Ten Years No Longer Guarantees You Anything

Software Judgment

Disclosure: I use GPT search to collection facts. The entire article is drafted by me.

Kent Beck once said something that stops most engineers cold the first time they read it: “90% of my skill is now worthless, and the remaining 10% has been amplified a thousandfold.”

Most people’s first reaction is: “AI writes code now, so coding skill is cheap.” But the sentence that actually stings isn’t about AI at all. It’s this: if a ten-year engineer and a two-year engineer are increasingly hard to tell apart, what exactly did those extra eight years accumulate? This isn’t a new problem AI invented. AI just made an old problem impossible to keep ignoring.

1. A counterintuitive pattern

Software has always operated on an assumption borrowed from other professions: experience compounds. Doctors get more valuable with age. Lawyers get more valuable with age. Fund managers get more valuable with age. Programmers assumed the same rule applied to them by default.

Reality has stopped cooperating with that assumption. Across the last few rounds of tech layoffs, the people cut hardest weren’t new graduates — they were mid-to-senior engineers. A Java engineer with ten years of experience often doesn’t find a job faster today than they would have five years ago. Some companies now describe an odd internal pattern: “we have more senior engineers than ever, and fewer people who can actually own a hard problem.”

Here’s the uncomfortable question worth sitting with: is age itself losing value, or is it the specific set of skills that used to accumulate with age that’s losing value? I’ve come to believe it’s the latter.

There’s a fair counterargument here — that this is just an economic cycle, cost-cutting, and hiring contraction, not a structural shift caused by AI or technology. That’s not an unreasonable read; every downturn amplifies age anxiety. But even setting AI aside entirely, looking at software engineering’s last fifteen years on its own reveals a clear trend: more and more engineering capability keeps migrating from “scarce skill” to “commodity infrastructure.”

2. What experience actually used to be made of

Break a decade of engineering growth into four layers, and the picture gets much clearer.

Layer one: knowledge. Knowing how to configure Spring Boot, deploy Kubernetes, or tune Redis parameters. This used to be a real barrier. Today a model produces the answer almost instantly. GitHub’s own research on Copilot shows AI-assisted development measurably speeding up coding, and a large share of what used to require memorized knowledge is now something you retrieve on demand instead of recalling from years of accumulated exposure. Memory, as a professional asset, is depreciating.

Layer two: coding fluency. Every veteran engineer has felt this shift directly. An endpoint that took thirty minutes to write shrank to ten minutes, then to five seconds with a tool like Cursor. What actually changed isn’t efficiency in the abstract — it’s that execution cost has essentially collapsed. The genuinely expensive activity moved somewhere else: reading. Google’s 2025 DORA report — built on nearly 5,000 survey responses and over 100 hours of qualitative research — found AI does raise reported productivity, with 59% of respondents reporting a positive effect on code quality, but the same body of research (and independent analysis of the same dataset) also documents a sharp rise in review time and incident rates alongside that throughput gain. Some teams end up spending more time understanding AI-generated code, not less. As one sharp summary of this tension put it: writing code keeps getting cheaper, reading code doesn’t. Plenty of teams today aren’t bottlenecked by “nobody can write this” — they’re bottlenecked by “nobody’s confident enough to change this.”

Layer three: experience. This is the layer most people misdefine. People love saying “I’ve hit a lot of walls.” Hitting a wall isn’t experience by itself. Experience is what forms after the wall — a transferable judgment you can apply somewhere else. Take a concrete example: two engineers face a production CPU spike. The junior one starts Googling. The senior one starts checking dashboards. But the genuinely excellent engineer’s first sentence might be: “did we ship a new caching strategy recently?” That’s not memorizing an incident — that’s having built a causal model. The valuable thing was never “I’ve seen this bug before.” It’s “I know why this category of bug tends to appear.” Those sound similar. They’re separated by an entire layer of abstraction.

Layer four: judgment. I increasingly think this is the layer AI struggles hardest to replace. Rich Hickey’s well-known distinction — easy is not the same as simple — applies directly here. AI can produce something that runs. It has no particular way of knowing whether a module shouldn’t exist at all, whether an interface should be deleted rather than maintained, or whether what looks like a database problem is actually a business-modeling problem in disguise. None of these questions have a standard answer. They depend on a judgment framework built up over years — not a lookup table.

3. A real team’s story is more convincing than any theory

Most engineers have heard some version of the Amazon Prime Video microservices story: a video-monitoring system was originally split into a large number of microservices, then later consolidated back — not because microservices are inherently bad, but because the business scale never justified carrying that much distributed complexity in the first place. The consolidation reportedly cut costs by roughly 90%.

That story gets cited constantly, usually just for the punchline. The more interesting question is why so many genuinely capable engineers made that “wrong” call in the first place. The honest answer probably isn’t skill deficiency — it’s that the entire industry, at the time, believed microservices were the advanced choice. Plenty of teams mistake “what’s currently fashionable” for “what’s actually best.”

AI can manufacture exactly the same failure mode today. If the internet is saturated with a particular architectural pattern, a model will disproportionately keep generating variations of it. What it hands you is the statistically dominant answer across its training distribution — not necessarily your best answer for your specific constraints.

AI-Generated Image

4. We may be overrating both AI and experience

There are two extreme takes floating around. One says AI will replace most programmers soon. The other says AI will always be “just a tool.” Reality sits somewhere uncomfortably between the two — and the data complicates both stories.

METR ran a randomized controlled trial in mid-2025 with sixteen experienced open-source developers, each working in codebases they’d personally maintained for years (some over a million lines, five-plus years of familiarity), using Cursor with Claude 3.5/3.7 Sonnet. Before the study, these developers predicted AI would cut their task time by about 24%. After finishing, they believed they’d been about 20% faster. The measured result: they were actually 19% slower. A 39-point gap between perceived and actual performance.

The cause wasn’t that the AI was unhelpful — its suggestions were frequently “directionally correct.” The time loss came from reviewing, correcting, and reverting suggestions that missed critical context the model had no way of knowing: undocumented tribal knowledge, architectural decisions never written down anywhere, edge cases specific to that codebase’s history. The study’s authors explicitly noted this slowdown pattern was tied to experienced developers working in familiar, mature codebases — they didn’t expect the same effect for juniors or unfamiliar code.

Meanwhile, Google’s 2025 DORA report — a much broader survey, not a controlled experiment — found the opposite headline: over 80% of respondents report AI improved their productivity, and a majority report a positive quality effect. But a closer read of the same underlying research also surfaces a “throughput up, stability down” pattern: one independent analysis of the DORA 2025 dataset found PR throughput up 98% alongside incidents per PR up sharply and review time up substantially. These two bodies of research aren’t strictly contradictory — self-reported productivity and rigorously measured task completion time are different things — but together they paint a picture more complicated than “AI makes everyone faster.”

There’s a real, almost paradoxical pattern hiding in here: juniors get faster, and veterans get more cautious — because veterans spend more time verifying model output, while juniors are more prone to trusting it outright. Whether that net effect is “efficiency loss” or “quality gain” doesn’t have a clean answer yet. But it proves one thing clearly: AI doesn’t just amplify capability. It amplifies whatever thinking habits you already had — good or bad.

AI-Generated Image

5. What’s actually being amplified isn’t code — it’s judgment

Kent Beck’s quote carries a second layer people usually skip past. AI isn’t a value creator. It’s a value amplifier.

If an engineer’s biggest advantage is writing CRUD endpoints slightly faster than the person next to them, AI erases that advantage almost immediately — that skill was never scarce to begin with, it just used to take longer to execute. If an engineer’s biggest advantage is knowing when a piece of code shouldn’t be written at all, AI amplifies that advantage instead, because it can execute everything downstream of a good decision — while contributing nothing toward the decision itself.

This is why a growing number of strong engineers are shifting their actual time allocation away from writing code and toward three specific questions: should this requirement exist at all, should this system exist at all, and can this complexity simply disappear? In a lot of real situations, one correct “we shouldn’t build this” is worth more than a hundred well-executed “yes, and here’s how.”

6. What age should actually be depositing

If I had to redefine programmer experience today, I wouldn’t describe it as “I’ve hit a lot of walls” anymore. I’d describe it as a continuous process of deleting bad judgment models.

There’s a decent analogy here in neuroscience — synaptic pruning. A developing brain doesn’t grow by adding more connections indefinitely; it grows by aggressively removing the connections that don’t help, leaving behind the fastest remaining paths. Engineers work the same way. What’s valuable isn’t knowing more and more things. It’s getting faster at recognizing which knowledge has already expired, which complexity was never worth carrying, and which “new” problem is actually an old problem wearing a different name.

AI is steadily absorbing more and more of the execution half of engineering. Which means a programmer’s real competitive edge is starting to sound a lot like an old line from management theory: the value isn’t knowing the answer. It’s knowing which question to ask.

Conclusion

So — back to the original question. Why does a career that’s supposed to reward long-term accumulation increasingly punish age instead?

Maybe the honest answer isn’t that age lost its value. It’s that a large share of what used to accumulate with age — memorized configuration knowledge, raw coding speed, pattern-matching against previously seen bugs — always belonged to the category of skill that technology eventually commoditizes. AI didn’t invent that vulnerability. It just made the timeline shorter and the exposure harder to hide from.

The ratio in Kent Beck’s line — 90% zeroed out, 10% amplified a thousandfold — isn’t really the point worth repeating. The point worth sitting with is the question underneath it: over your last ten years, which parts of what you built were the 90%, and which were the 10%? There’s no universal answer — it depends on your team, your business stage, even which company you’re at. But AI has made one thing unavoidable: whether you can still make better calls than the person next to you, now that generating code itself is nearly free, is quickly becoming the only competitive question that still matters.

If you’d like to show your appreciation, you can support me through:

✨ **Patreon ✨ [Ko-fi](https://ko-fi.com/jinlowmedium) ✨ [BuyMeACoffee](https://buymeacoffee.com/jinlowmedium)**

Every contribution, big or small, fuels my creativity and means the world to me. Thank you for being a part of this journey!