Career Risk: Which AI Skills Will Age Badly

Nobody can tell you how many years a skill has left. What can be observed today is what a skill is attached to, and the durability of the attachment is a much better predictor than any forecast — because it is a fact about the present rather than a guess about the future.

A skill lasts as long as what it is attached to

Every technical skill sits on top of something. Knowing a particular library’s API is attached to that library. Knowing why retrieval returns plausible-but-wrong passages is attached to a property of vector similarity that no release changes. When the underlying thing moves, the skill moves with it; when the underlying thing is stable, so is the skill.

This is why “half-life in years” is the wrong unit. It implies a smooth decay when what actually happens is that a layer gets replaced and everything attached to it goes at once, or the layer persists and nothing goes at all. The useful question is not “how long does this last” but “what would have to change for this to stop being true” — and that question has an answer you can look at today.

One honest caveat before the layers: this is a framework for reasoning about risk, not a prediction. It has been wrong before, in a direction worth knowing about, and there is a section below that says where.

Five layers, most volatile first

Layer 1 — Attached to a specific product’s interface

Knowing where a setting lives in a particular console, the exact argument names of one framework, the quirks of one vendor’s response shape. These evaporate on a redesign and they are the layer most likely to be listed on a CV.

They are not worthless — they make you productive today — but they should never be the thing you are known for. The cost of relearning them is days, which is also why nobody will pay a premium for them.

Layer 2 — Attached to a current model’s behaviour

Prompt tricks that work on one model generation. Knowing which model currently handles which task best. Workarounds for a limitation that the next release removes.

This layer turns over fastest of all, and it is the layer that “keeping up” mostly consists of. The important implication: knowledge here should be stored in your systems — in an evaluation set, a config, a documented decision — rather than in your head, because that way its expiry is somebody’s ticket rather than your skill decaying.

Layer 3 — Attached to an API-level concept

Tool calling, structured output, streaming, prompt caching, embeddings as an interface. These are conventions across the industry rather than one vendor’s idea, so they change by accretion rather than by replacement. The specific parameter names move; the concept persists, and knowing the concept makes learning the next dialect an afternoon.

Layer 4 — Attached to a property of the problem

Why retrieval fails and how to tell which stage failed. Why a fluent wrong answer is a high-probability continuation rather than a malfunction. How to design an evaluation that detects a real difference. What a failure costs and how that changes a design. Why a verifier must be cheaper than the thing it verifies.

These are attached to the structure of the problem, not to any implementation of it, and they have survived several complete generations of models. This is the layer to be deliberate about, and it is the one that is hardest to acquire because it mostly comes from having been wrong in production.

Layer 5 — Attached to nothing technical at all

Deciding what is worth building. Writing so that a decision is legible to somebody who was not in the room. Estimating with visible assumptions. Saying no to a plausible feature. Debugging under uncertainty. These outlast the field entirely and they are what seniority actually consists of.

Sorting your own skills

Take an honest inventory — the things you would put on a CV or would be called into a meeting for — and for each one ask a single question: what would have to change for this to stop being useful?

If the answer is...                       then the layer is...

"a vendor redesigns their console"              1
"the next model release"                        2
"the industry adopts a different convention"    3
"the nature of the problem changes"             4
"nothing in this field"                         5

Healthy inventory: most of your identifiable value
sits at 4 and 5, and layers 1-2 are things you happen
to know rather than things you are known for.

If everything you can name sits at layers 1 and 2, that is not a crisis — it is where most people start, because those layers are what you learn first and what job adverts ask for. It is a signal about where to spend the next year. The conversion is usually cheap: each time a layer-2 workaround stops working, spend an hour on why it worked at all, and you have moved a piece of knowledge down to layer 4.

Where this framework has been wrong

Three failure modes, stated because a framework presented without them is being oversold.

• Layer 1 knowledge is worth more than the framework suggests, in the short run. Being immediately productive in the tools a team actually uses is what gets you hired and trusted. Someone who has optimised entirely for durability can be simultaneously wise and unemployable.
• Some layer-2 knowledge has proved unexpectedly durable. Ideas that looked like temporary coping strategies for weak models — decomposing a task into steps, giving worked examples, asking for structure — turned out to be about how to specify a task clearly, which is a layer-4 property wearing layer-2 clothes. The lesson: ask whether a trick works because of a defect or because of a property of the task.
• A layer can disappear entirely. Skills built around a constraint vanish when the constraint lifts — a great deal of careful context-squeezing craft became irrelevant as windows grew. The framework tells you a skill is fragile; it cannot tell you when the constraint will lift.

Holding a portfolio rather than a bet

The sensible position is not to abandon the volatile layers. It is to hold them knowingly, in proportion, the way you would hold a risky asset:

• Enough layer 1 and 2 to be useful this quarter. Refresh it cheaply and without sentiment, and do not defend a tool because you invested in learning it.
• Deliberate accumulation at layer 4, which happens mostly through operating something over time and reading the failures. This is the argument for staying somewhere long enough to see the consequences of your own decisions.
• Continuous investment at layer 5, which is the only part that compounds across a whole career and the part most neglected by people who identify strongly as technical.

A practical test of whether the balance is right: if the tool you use most were discontinued tomorrow, how much of what you are valued for would go with it? If the answer is “most of it”, the portfolio is concentrated — and the fix is not to panic about the field, it is to write down why the things you do work, which converts practice into the layer that lasts.