AI skills: from awareness to useful autonomy

Two people can write the same word in the same section of a profile and mean two unrelated things. "RAG" can describe the ability to explain the principle in a meeting, or ownership of a production system whose retrieval quality is measured every week. The word carries no depth, and that is why most skill lists are unreadable.

This guide is not another list of technologies to learn. It offers a scale for thinking about the depth of any AI skill, and for answering a question few people settle for themselves: at what point can I say I actually have this skill?

A five-level progression scale

What follows is not an official framework or a recognised standard: it is a teaching scale, useful because it separates things everyday vocabulary merges. It applies to any AI skill, technical or not.

1. 1

   Level 1 — Understand

   explain

   Being able to say what the technology does, what it does not do, its main use cases and its important limits. Enough to follow a conversation without misidentifying the problem.

2. 2

   Level 2 — Use

   apply

   Being able to use it correctly in a defined context, obtain a usable result, and recognise the situations where the output is not trustworthy.

3. 3

   Level 3 — Build

   produce

   Being able to produce something reproducible and justify your choices: why this approach, why not the other, and under what conditions it holds.

4. 4

   Level 4 — Evaluate and diagnose

   measure

   Being able to say why a system works or fails, measure its quality with a defensible protocol, and locate the cause of a regression.

5. 5

   Level 5 — Design, decide, operate

   own

   Where the role requires it: arbitrating between quality, cost, latency, security and integration, keeping the system running, setting governance rules and owning the limits you chose.

No job needs level 5 on every skill. A role is defined as much by the skills it requires in depth as by the ones where level 1 or 2 is plenty.

The same skill at five different depths

The scale becomes useful when applied to words that genuinely appear in profiles and job ads.

Prompting

Understand: knowing why phrasing changes the output and why reproducibility is not guaranteed. Use: reliably getting a usable result on a repeated task. Build: producing versioned instructions, tested on representative cases. Evaluate: measuring regressions when a model or an instruction changes. Design: embedding those instructions in a system whose cost, latency and refusal cases you control.

RAG

This is the most revealing example, because all five levels hide behind one acronym: explaining the principle; assembling a demo that answers correctly on a few documents; designing chunking and retrieval for a real corpus; diagnosing whether a failure comes from retrieval or from generation; operating the system, with data freshness, access rights and cost under control.

Agents

Understand: telling a chain of calls apart from real autonomy. Use: getting a tool-using agent to work on a scoped task. Build: defining tools, permissions and stopping conditions. Evaluate: measuring failure rates and behaviour when a tool errors. Operate: handling idempotency, retries and side effects on real systems.

Evaluation

Understand: knowing that an occasional human judgement is not a measurement. Use: applying an existing protocol. Build: assembling a representative set of cases, including hard ones. Diagnose: interpreting a gap and tracing it back to a cause. Decide: setting the bar above which a feature can be put in users' hands.

AI literacy and copilots, for a non-technical role

Understand: knowing what an assistant can produce and what it fabricates. Use: fitting it into your work without delegating verification to it. Build: documenting a way of working that a team can reuse. Evaluate: observing where the tool saves time and where it costs time. Decide: setting usage rules around sensitive data. Level 5 exists here too — it simply is not about code.

Build a progression plan instead of accumulating

The scale is mostly a way of deciding what to do next. The reasoning fits in six questions, in this order, and it is redone whenever the objective changes.

1. 1

   Target role

   1

   Which responsibility am I actually aiming at? Without a destination, every kind of progress looks equally justified.

2. 2

   Required skills

   2

   Which ones does that role genuinely need? The list is shorter than expected, and often contains non-technical skills.

3. 3

   Expected depth

   3

   For each, which level is enough? The most frequently skipped step, and the one that avoids the most wasted effort.

4. 4

   Current level

   4

   Where you honestly stand, judged by what you could demonstrate under questioning.

5. 5

   Missing evidence

   5

   What is missing for that level to be visible from the outside?

6. 6

   Next step

   6

   One single action, chosen to close the most blocking gap — not the most interesting one.

"Learn more" is rarely the right next step

The usual reflex when facing a gap is to consume more content. Sometimes that is right, especially at level 1. Beyond it, the gap is almost never a knowledge deficit: it is a deficit of practice, measurement or evidence, and reading more does not close it.

• Practise, when you understand the theory but have never produced a result yourself.
• Measure, when you produce results without being able to say whether they are good.
• Diagnose, when you know a result is poor but not why.
• Document, when you can do the work but nobody can observe it.
• Explain, when the skill exists but stays uncommunicable in an interview.
• Ship to production, when the target role requires operational responsibility.
• Work with another function, when the gap is about context rather than technique.

Training and certifications: what they prove, and what they do not

A certification is neither a false signal nor sufficient evidence. It attests to a structured path, which has real value, particularly for organising learning or crossing level 1. The misunderstanding starts when it is presented as equivalent to professional practice.

• Having taken a course: time invested in a given programme.
• Knowing a concept: being able to explain it and name its limits.
• Being able to use it: getting a usable result in a defined context.
• Having professional evidence: having held an observable responsibility, with decisions you can defend.

All four statements can be true at once. Presenting them in order, without merging them, is what separates a precise profile from an overstated one.

• Progression
• Skill levels
• Learning