In early 2025 I published a list of eight AI skills I thought would separate people. It was read widely and I still get mail about it. Going back to it now, roughly half has aged badly, and the half that held up has become more valuable than I expected.
That seems worth writing down honestly, because the parts that aged are the parts most people are still being sold.
What aged badly
Four of my eight were tool proficiencies wearing the word "skill". Here is what became of them.
Prompt mastery was the first to go soft. I told people to study prompting as a discipline. The models then got substantially better at interpreting ordinary requests, and the gap between a carefully engineered prompt and a clearly written one narrowed to something small. The prompt is rarely the bottleneck now. What you are asking for usually is.
API alchemy lasted about a year. Stitching tools together through APIs was a real edge in 2025. It has become something the model does for you in an afternoon, and the remaining difficulty sits in deciding what should connect to what, which is a design question wearing technical clothes.
The named creative tools dated fastest of all. I listed specific products for images, video, music and editing. Several have been displaced, folded into something larger, or repriced beyond what they were worth. Anyone who invested in learning an interface, as opposed to the craft underneath it, paid for a skill with an eighteen-month shelf life.
No-code agent building got easier, exactly as predicted, and that was the problem. What I missed is that the difficulty moved without disappearing. Building an agent is now straightforward. Knowing whether it should exist, and noticing when it has quietly started producing confident nonsense, is where the work went.
The pattern across all four is the same. I named the thing you touch and skipped the judgment that makes touching it worthwhile. That is the easier article to write and the less useful one to read.
What survived, and got harder to fake
Four things held up. They share a property: a model can assist with each one without ever completing it for you.
1. Specifying the work before you automate it
You cannot automate a mess. Every team that has tried has produced the same result, which is a faster mess with better formatting.
The skill is unglamorous. It means describing a piece of work precisely enough that someone else could do it: what triggers it, what counts as done, what the edge cases are, who decides when it is ambiguous. Most processes inside most companies have never been written down at that resolution. They live in one person's head as a set of habits and exceptions, and that person has stopped noticing they are making judgment calls.
Process first, agent second. When an automation project fails, the post-mortem usually finds that the team could not state what the process actually was before it got automated. The model then filled the gap with something plausible, and plausible is where the damage starts.
The test: take something you do weekly. Write it down so completely that a competent stranger could run it on Monday without asking you a question. If you cannot, the process is not ready to automate, and no tool will rescue that.
2. Judging output you did not produce
This is the one I underweighted most, and it has become the daily texture of the job.
The volume of work arriving for review has gone up sharply while the time available to review it has not. A colleague sends twelve pages that took four minutes to generate. A model returns a function that looks right. A report arrives with forty citations. In each case you have to decide whether it is good, and you did not watch it being made, so the usual signals are missing: how long it took, where they hesitated, what they chose to leave out.
Reviewing work you did not produce is a genuine skill with its own technique. It means knowing which three sentences carry the decision and checking those first, instead of reading linearly from the top. It means noticing an absence, which is far harder than noticing an error, because an error sits on the page and an omission does not. Plausible and correct are not the same thing, and fluent output has made the difference invisible to a casual read.
The test: the last time you approved something a model generated, what specifically did you check? If the answer is that you read it and it seemed fine, you reviewed the prose and left the claim alone.
3. Knowing what evidence a claim actually needs
Related to the above and worth separating, because it fails in its own way.
Everything a model produces arrives in the same confident register. A fact it has seen ten thousand times and a figure it has essentially inferred are delivered in identical prose, with identical punctuation and no hedging between them. The model is not concealing its uncertainty from you. It has no reliable way to show it.
So the burden moves to you, and it is a calibration question more than a research one. Which claims in front of you would be expensive to get wrong? Which would a reasonable person want a source for? Which are load-bearing for the decision, and which are decoration? People who have this skill check two things carefully and let forty go. People who lack it either check everything, which is unsustainable, or they check at random, which is how bad numbers end up in board decks.
The test: given a page of model output with one load-bearing number in it, can you find that number without being told which one it is?
4. Knowing when not to use the model
The least discussed of the four and, in my experience, the strongest signal that someone has used these tools in anger.
Some tasks cost more to delegate than to do. If you would have to verify every line, the checking exceeds the writing. If the answer already sits in one authoritative place, a generated summary adds a layer of risk over a lookup. If the thinking is the deliverable, outsourcing the first draft means you never form the view yourself, and you will notice the hollowness later when someone questions it. And anything carrying a human relationship inside it reads as exactly what it is.
Judgment here looks like restraint, which is why it rarely gets taught. The people who are genuinely fast with these tools are noticeably selective about when they pick them up.
The test: name the last task where you deliberately chose to do it yourself, and say why. If nothing comes to mind, you are probably paying a verification tax you have not counted.
What this looks like when it goes wrong
A concrete version, because the four above can read as abstractions.
A team automates its weekly client report. The old process took a person half a day: pull the numbers, notice anything odd, write three paragraphs of interpretation, send. The new process takes four minutes and produces something that looks better than the original, with cleaner charts and tighter prose.
It runs for two months before anyone realises that the "notice anything odd" step disappeared. It was never in the brief, because it was never written down. The person doing it had been doing it on instinct for three years and would have described their job as pulling numbers and writing paragraphs. The automation faithfully reproduced the described process and dropped the valuable part, which lived in the gap between the description and the work.
Every skill above would have caught this. Specification would have surfaced the hidden step. Reviewing the output properly would have noticed the absence of interpretation. Calibration would have flagged that the anomaly check was the load-bearing part. And restraint would have asked whether this particular task wanted a human in it at all.
Six questions to work out where you are
Answer honestly. There is no score at the end.
- Could a stranger run your weekly work from your written description? If it needs a conversation with you first, the process still lives in your head and is not yet automatable.
- When you last approved model output, what did you verify? A specific claim, a number, a source: good. A general impression of quality: that was a reading, and a review is something else.
- Can you spot what a document leaves out? Absences are the expensive failure mode, and seeing them takes deliberate effort.
- Do you know which claims in your own work are load-bearing? If every sentence feels equally important, your checking becomes either exhausting or arbitrary.
- When did you last decide against using a model? A recent, specific example suggests calibration. Silence suggests habit.
- Can you tell a good output from a plausible one in your own field? This is domain expertise doing the work. Your expertise is the GPS coordinates; the model is the car.
Four or more honest yeses suggests your constraint is scope. Two or fewer and the highest-return move is to narrow: pick one process, specify it properly, and build the review habit on that before touching anything else.
Why the gap is widening
The common expectation was that better tools would level the field. Something closer to the opposite happened.
AI is an amplifier, not an equaliser. Give a strong operator a capable model and they move faster, because they can tell when it is wrong and correct course early. Give the same model to someone without that judgment and they also move faster, in whatever direction the model picked. Speed with no steering mechanism carries you away from the target as efficiently as toward it.
This is why "learn the tool" advice keeps disappointing people. The tool is the part that commoditises. What stays scarce is knowing what good looks like in your own domain, which is the one thing the model cannot supply, because that judgment is precisely what it is approximating.
Taste is the last human moat. It is also the least teachable thing in a weekend course, which is why so few people try to sell it.
Where I was right
Worth saying, since I have spent most of this piece correcting myself.
The generalist argument held up. People who can move across domains with a model beside them do outperform narrow specialists on a wide class of work, and the gap is real. One person can now do what used to take a small team, and that has reorganised how a lot of small companies operate.
What I got wrong is the reason. I framed it as range: knowing a bit of marketing, design, code and copy. The generalists who actually won were not collecting tools. They could judge the output of four domains well enough to catch the failures in each, which is a much higher bar and a much more durable one. Range was the visible part. Judgment was the engine.
I would also defend the urgency, with one correction. The pressure is real and it is still building. What I framed as a race to acquire capabilities turned out to be a slower, less dramatic process of learning to supervise work you did not do. That is harder to sell and considerably more useful.
Common questions
What AI skills are most in demand in 2026?
Specifying work precisely enough to delegate it, reviewing output you did not produce, calibrating what evidence a claim needs, and recognising when a model is the wrong tool. These hold their value because a model can assist with each one without completing it. Tool-specific proficiencies move faster than you can learn them.
Is prompt engineering still a useful skill?
Much less than it was in 2025. Models got better at interpreting ordinary requests, so the gap between an engineered prompt and a clearly written one narrowed considerably. Clarity about what you want still matters enormously, but that is thinking, and it transfers to every other part of the work.
Will AI replace my job?
A more useful question is which parts of your work are specifiable. Work that can be written down completely is the work most exposed. Work that requires judging quality, holding context that was never written down, or deciding what should happen is considerably safer, and those are the skills above.
How do I know if I am actually good with AI tools?
A reasonable proxy: how often you catch the model being wrong. If you rarely do, either you are working below your own expertise or you are not checking. People with real fluency correct the output constantly and are specific about why.
What should a beginner learn first?
Pick one process you run weekly and write it down completely, to the point where someone else could run it. That single exercise teaches specification, surfaces the edge cases you have been handling by instinct, and leaves you with something concrete to automate. It beats a tour of twelve tools.
Do I need to learn to code to work with AI?
No, and that was true in 2025 too. What helps is understanding what software can and cannot do, so your requests are achievable and you can tell when a result is wrong. That understanding is available without writing code yourself.
How long does it take to build these skills?
Weeks for the habits, longer for the judgment, because judgment comes from being wrong in a domain repeatedly and noticing. You can shorten it by working somewhere that reviews output seriously, which is worth more than any course.
What I would do
If I were rewriting my 2025 advice for someone starting now, it would run to three sentences.
Pick one process you own and specify it until a stranger could run it. Build the habit of checking the two claims that carry each decision, instead of skimming the whole document and hoping. And get deliberate about when you decline to use the model, because that choice is where most of the compounding happens.
The eight-item list was more fun to write. This one has a better chance of still being true in two years. If you want the longer version, including how to position yourself around judgment as the roles themselves change shape, that is what the AI Career Accelerator is built around.
Charafeddine Mouzouni
