Give two people the same AI tool and the same task, and the results can be worlds apart. I see this every week across my teams: same model, same codebase, same deadline, and yet one session ends with a clean plan and a reviewable diff while another ends with an hour of back and forth and a result nobody is happy with. For a long time I assumed the difference was prompting skill. It turns out prompting is only about a quarter of the story.
The other three quarters have names too. Anthropic, together with Prof. Rick Dakan (Ringling College of Art and Design) and Prof. Joseph Feller (University College Cork), published the AI Fluency Framework: four interconnected competencies that make our interactions with AI effective, efficient, ethical, and safe. They call it the 4D framework, for Delegation, Description, Discernment, and Diligence. I took their course, AI Fluency: Framework & Foundations, and earned the certification, and what follows is the framework as I have come to use it in daily work.
One idea from the framework is worth holding onto before we start. It describes three modes of interacting with AI: automation, where AI executes a specific task you instruct it to do; augmentation, where you and the AI think through something together as partners; and agency, where you configure AI to perform future work on your behalf. Most of the frustration I see with AI comes from mixing these up: asking for a one-shot answer when the task needed a conversation, or giving an agent free rein on work that needed supervision. The four competencies below are what let you move between these modes on purpose.
Delegation: decide whether, when, and how
Delegation is about setting goals and deciding whether, when, and how to engage AI at all. That sounds obvious until you notice how rarely we actually do it. The tool is open, so we type into it. The framework asks for a small pause before that: what am I trying to achieve, which parts of this work need my judgment, and which parts can I hand over?
In my own work the clearest example is the split between planning and implementation. When I bring an agentic tool like Claude Code into a piece of work, I no longer start with "build the feature." I start by asking for a plan: break the deliverable into small stories, define acceptance criteria, list the risks and assumptions, and stop. The implementation gets delegated story by story afterwards. I wrote about this workflow in detail in my post on TDD in the age of agentic AI, and at its heart it is a delegation decision: the shaping of the work stays with me, the typing goes to the agent.
Delegation also means knowing what not to hand over. Decisions with long shadows, like architecture choices, naming things that a team will live with for years, or anything where accountability sits with me, get AI as an advisor, not as a decision maker. That is augmentation, and choosing it deliberately is a delegation skill as well.
Description: say what you actually want
Description is the competency people usually mean when they say "prompting": effectively describing your goals so the AI produces useful behavior and output. But the framework is broader than clever phrasing. You are describing three things at once: the product you want, the process the AI should follow, and the way you want it to behave while working with you.
The difference is easy to see in practice. Here is a description I would have typed a couple of years ago:
Create a todo app with Angular.
And here is what a fluent description of the same goal looks like:
Planning mode only. Do not edit files yet.
I want to create a todo app with Angular.
First, break the deliverable into small composable stories. For each story, define the goal, acceptance criteria, expected files to create or modify, dependencies, required tests, risks, and assumptions.
Stop after the plan.
The second version describes the product (a todo app, shaped as stories), the process (plan first, no file edits), and the behavior (stop and wait for review). Every sentence closes a gap the AI would otherwise fill with an assumption. Actually, that is the simplest test I know for a good description: read it back and count the guesses it still leaves open.
Discernment: the review is the work
Discernment is accurately assessing the usefulness of what the AI gives you, and it is the competency that separates using AI from benefiting from it. Models produce fluent, confident output whether they are right or wrong, therefore the confidence of the answer tells you nothing about its quality. Someone has to actually judge it, and that someone is you.
This matches what I see in engineering every day. For my teams the bottleneck has genuinely moved from writing code to reviewing and validating it. An agent hands back a summary of what it changed, and the real work starts there:
- Does this diff do what the story asked for?
- What assumptions did it quietly make?
- Do the tests prove the behavior, or do they just pass?
- Is this consistent with how the rest of the codebase works?
Discernment also applies to the process, not only the product. Sometimes the output looks fine but the way the AI got there is worrying, like reasoning that skipped a constraint you stated, or a step where it invented a fact to keep moving. Catching that changes what you do next, which is where discernment feeds straight back into description: you refine what you asked, the AI produces a better result, and you assess again. The course calls this the description and discernment loop, and it is a good name for what a productive AI session actually feels like.
Diligence: own what you ship
Diligence is taking responsibility for what we do with AI and how we do it. Of the four Ds this is the one I care about most, because I work in a regulated industry, and "the AI wrote it" is not a defense anyone will accept. If AI helped produce the code, the document, or the decision, the accountability still belongs to the human who shipped it.
In practice, diligence looks unglamorous. It is checking that the data you paste into a tool is data you are allowed to share. It is being transparent with colleagues about where AI was involved in a piece of work, so they can calibrate their own review. It is knowing what the systems you rely on do with your inputs. And it is refusing to let speed become the excuse for skipping the human check on anything that matters.
I find this framing kinder than the usual compliance language, because it makes responsibility a skill you practice rather than a policy you fear. The framework's own definition of fluency puts ethical and safe right next to effective and efficient, and in my experience the teams that treat those as one package are also the ones that get the most out of the technology, since trust is what allows an organization to say yes to more AI, not less.
Four skills, one loop
The four Ds are not a checklist you complete once. Delegation decides what to hand over, description hands it over well, discernment judges what comes back, and diligence makes sure the whole exchange is something you can stand behind. In a real session you cycle through all four in minutes, and each one you are weak in caps the value of the others. Amazing descriptions cannot save a task that should never have been delegated, and sharp discernment cannot fix responsibility that nobody took.
Also worth saying plainly: this is learnable. None of it requires a technical background, which is exactly the point, since the people who need these skills now include everyone whose work touches a model, not only engineers.
And you don't have to piece it together on your own. Anthropic offers free courses on working with AI, and the one this post is built on, AI Fluency: Framework & Foundations, ends with a final assessment and a certificate of completion. It is the course I took, it costs nothing, and it is a few well-spent hours. The trailer gives you a quick feel for it:
Which brings me back to the two sessions from the start, the clean plan and the hour of back and forth. The distance between them was never the tool. It was four skills with names, and you can start practicing every one of them in your very next session.