Last February I spent the better part of a week getting good at a prompt-orchestration pattern. Chained agents, a hand-tuned router, the works. I wrote it up. I was proud of it. By April the framework underneath had shipped a feature that did the same job in one config line, and my clever pattern was a museum piece. Nobody told me. I found out because a function I depended on threw a deprecation warning at 11pm.
That's the part nobody warns you about. The AI dev skill half-life in 2026 is short — and I mean short. From where I sit, after about a year of tracking my own re-learning, half of what you know about any specific tool goes stale in roughly six weeks. Wrong, deprecated, or quietly beaten by some new default you didn't read the changelog for.
I want to be honest about that number before we go further. It's my own logbook, not a study. An n of one, me, sitting at this desk, writing things down when they bite me. Treat it as a working estimate, not a finding. But it's been close enough, often enough, that I now plan around it.
What half-life actually means here
I'm using the physics sense. Half-life doesn't mean the thing disappears. It means half of it decays in a fixed window. Your tooling knowledge behaves the same way. You don't wake up stupid. You wake up partially wrong, and the cruel part is you can't tell which half went bad until something breaks.
Over one quarter last year I kept a rough tally. Every time I hit a wall because something I "knew" was no longer true, I jotted it down. I counted maybe nine of these — nine confidently-held facts about Claude Code, an MCP server, or a Cursor workflow that had rotted under me. In thirteen weeks. And those are only the ones that bit hard enough to notice. The silent decay, the better way I never learned because my old way still technically worked, I have no count for that. Nobody could.
Not everything decays at the same speed
Here's the part that actually saves your quarter. The decay isn't uniform. Some knowledge is half-gone by next sprint. Some barely moves in a year. If you can't tell the two apart, you'll pour your best hours into the fast-rotting stuff, feel busy, and learn nothing that lasts. Most of the dozen-odd builders I've asked about this had the same blind spot. They were studying surfaces.
Study layers instead.
The slowest-decaying layer is concepts. What a context window is, and why it costs you. Why retrieval beats stuffing everything into the prompt. How a tool-use loop actually reasons through a problem. What an eval even is and what it's measuring. This stuff has a half-life measured in years. Learn it once, properly, and it pays rent for the whole decade. When a new model drops, you understand why it's better instead of just noting the benchmark went up.
The middle layer is interfaces and protocols — MCP, the shape of a tool definition, how agents hand work off to each other. These shift, but slowly, and usually with announcements. Decay measured in quarters. Worth real investment.
The fast layer is specific versions of specific things. This model's current pricing. The flag on this CLI this month. Which of four competing wrappers is winning right now. The exact name of the function that's been renamed twice since March. This is the six-week stuff. And here's my actual stance: don't bother memorizing it. Know it exists, know where it lives, look it up fresh every time. Memorizing a decaying fact is how a quarter quietly disappears.
How to decide which AI dev skills are worth learning
When something new lands on my desk screaming "learn me," I run it through three questions before I give it a single hour.
- Which layer is it? Concept, interface, or version-specific detail? Concepts get deep time, no hesitation. Version details get a hard cap — enough to use today, nothing I try to retain.
- How load-bearing is it? Is this thing sitting underneath five other things I do daily, or is it a leaf? Foundations earn deep time even when they're boring. Leaves get the minimum and not a minute more.
- Can I look it up faster than I can memorize it? For the fast layer the answer is almost always yes. When it's yes, memorizing is the wrong move.
That third question reorganized how I work. I stopped trying to hold the current state of nine fast-moving tools in my head. I'd be wrong about a third of them by Thursday anyway. I lean on looking things up instead.
The tax nobody quotes you
But looking things up has a cost, and this is where I want you to actually feel it.
Last month I went to confirm one thing. The current rate-limit behavior on a tool I use every day. I opened the official docs, which were half a step behind reality, as usual. So I opened a GitHub issue. Then a Discord thread where someone swore it had changed. Then two blog posts, one of them confidently, gorgeously wrong. Then a changelog I had to diff by eye. By the time I had an answer I half-trusted, I'd burned most of a morning, had eleven tabs open, and a low-grade headache behind one eye.
For one fact. One I'll have to re-verify in six weeks.
Now multiply that by nine decay-events a quarter. The learning was never the expensive part. The re-verifying is. The cross-checking of a Discord rumor against a stale doc against a blog post from someone who might have tested it or might have made it up — that's the tax. It compounds, quietly, every week, and it never lands on any invoice.
So plan like the clock is six weeks. Spend deep on the concepts that don't move. Skip memorizing the things that do. And the next time you've got eleven tabs open trying to pin down one moving fact across a dozen half-trustworthy sources, count the minutes. Then ask yourself how many mornings a quarter that adds up to.
That number is the real cost of building in 2026. Not the learning. The checking.