"AI Literate" Is in the Job Description. Now Someone Has to Grade It.

The job ad says "comfortable working with AI tools." It was added because everyone else's ad says it.

Then the first candidate arrives and someone has to decide whether they meet it. The recruiter cannot tell. The interviewer asks which tools they use, gets a list, and writes "yes, uses AI daily." That box is now ticked and it means nothing.

This post fixes that. Four behaviors, each with what it looks like at five levels, in words plain enough to put in a scorecard. You can screen against it, interview against it, and spend a training budget against it.

First, clear up three words

People use these as if they mean the same thing. They do not, and the mix-up is where training money gets wasted.

• Prompt engineering is how you phrase a request. It is a small skill and it goes stale every time a model ships.
• AI literacy is the whole thing: knowing when to use a model, getting a useful answer, checking that answer, and owning the result. This is your floor.
• AI fluency is doing all of that fast and by habit. It is a ceiling, not a different skill.

Most "AI training" on the market teaches the first and charges for the third. Buy against the middle one.

There is a real reason to be precise here beyond tidiness. If you deploy AI systems in the EU, Article 4 of the AI Act requires you to make sure staff who use them have enough AI literacy. That obligation started applying in February 2025. "We told everyone to try Copilot" is not evidence. A rubric is.

The four behaviors

These are the ones you can watch someone do. Everything else is trivia.

1. Deciding when to use it. Knowing which tasks a model speeds up and which it quietly slows down.

This matters more than people expect. A 2025 randomized study by METR found experienced open-source developers took 19% longer with AI assistance, while believing they had been faster. Google's 2024 DORA report found something similar at team level. The tools are not the problem. Reaching for them without thinking is.

2. Giving it what it needs. Not clever phrasing. Knowing what the model is missing and handing it over: the constraint, the existing pattern, the actual error, the shape of the answer you want. People who are good at this are usually good at writing tickets. It is the same skill.

3. Checking the answer. The heavy one. Generated code compiles, reads well, and is wrong in specific ways: a function that does not exist, an edge case dropped, an error swallowed. Someone with this behavior treats output as a draft from a fast, confident colleague who will not be around when it breaks.

4. Owning the result. Understanding that once you ship it, it is yours. Correctness, licensing, and what data you pasted into a third-party service. Teams usually get this wrong by never saying it out loud.

The rubric

Same four rows every time. Five levels. Write the level, not a score out of ten, because nobody agrees on what a seven means.

Deciding when to use it

1. Unaware. Does not use the tools, or uses them for everything without noticing the difference.
2. Copying. Uses them where they saw someone else use them.
3. Working. Has personal rules of thumb and can name a task where they would not use a model.
4. Deliberate. Chooses per task and can explain the trade-off. Notices when steering is costing more than doing it by hand, and stops.
5. Sets the pattern. Helps the team decide where models belong, and adjusts as the tools change.

Giving it what it needs

1. One line, then frustration.
2. Rewords the same request until something sticks.
3. Supplies the obvious context: the error, the file.
4. Supplies constraints and conventions up front, so the first answer is close.
5. Builds shared context others reuse, and knows when the task is too vague to hand over.

Checking the answer

1. Pastes and hopes.
2. Reads it, ships it if it looks right.
3. Runs it against the happy path.
4. Runs it against the real case, checks that the functions exist, walks the edges by name.
5. Has a routine, catches the quiet failures, and can say why the code is right, not just that it works.

Owning the result

1. "The model wrote it."
2. Aware there is a risk, vague about which.
3. Follows the company rule on what can be pasted where.
4. Refuses to ship code they cannot explain. Thinks about data and licensing without being asked.
5. Sets the norm for the team and raises the awkward cases early.

For most engineering roles, level 3 across the board is the hire bar and level 4 on "checking the answer" is what you actually want. Level 5 is a small number of people and you do not need four of them.

Using it in three places

In the job ad. Replace "comfortable with AI tools" with the behavior: "You can explain when you would not use a model, and you check generated code before it goes in." Candidates self-select on something real.

In the interview. You cannot grade any of these from a conversation. All four are things a person does. Give them a real task, allow the tools openly, and watch. The strongest single question at the end is: walk me through the parts you kept and why. Somebody who did not verify cannot do it. We wrote up the interview mechanics in how to test if an engineer knows how to use AI, and the wider question of allowing tools in is using AI in technical interviews acceptable.

In training. Score your existing team once. You will almost certainly find high scores on rows 1 and 2 and low scores on row 3, because verification is the part nobody was taught. Spend there.

Where EasyEnv is different

Most AI literacy products are a quiz or a course. A quiz measures whether someone can pick the right definition of a hallucination. None of the four behaviors above survive that format.

EasyEnv gives the person a real Linux machine with a real task and lets them use whatever tools they want, including a model. The session is recorded, terminal and screen. So when you score row 3, you are not asking whether they say they verify. You are watching whether they ran the code, checked the function existed, and noticed the dropped case. Written answers get an AI-graded first pass, so your reviewer starts from evidence rather than a blank page.

The honest limit: this needs a real task and a person to review it. It is heavier than sending a quiz to two hundred people. If all you need is a compliance record that staff completed AI awareness training, a course with a certificate is cheaper and we would not pretend otherwise.

The short version

Break "AI literate" into four behaviors: when to use it, what to feed it, how to check it, and who owns the result. Grade each on five levels. Hire at level 3, aim for level 4 on checking.

Then do the thing almost nobody does: score your current team on the same rubric. The gap you find is your training plan, and it will not be prompt tricks.