AI Fluency and the 4D Framework: what I learned from Anthropic's course

I use AI every day for my work, and for a long time I thought I was already “good” at it. I had my prompts, my tools, my workflow. Then I took the AI Fluency course from Anthropic and I realized that I was good at one small part of it, and I was almost ignoring the other parts. 🤔

I completed the course and you can verify my credential here. In this post I want to share the main idea of the course, the 4D Framework, and expand on it with examples from my own work as a mobile engineer. This is not a summary of the course, it is more like my notes and how I apply it.

What is AI Fluency?

The course is called AI Fluency: Framework & Foundations and it is free in Anthropic Academy. The framework was created by Prof. Rick Dakan and Prof. Joseph Feller together with Anthropic.

The definition of AI Fluency is simple: being able to work with AI systems in an effective, ethical and safe way. Notice that it says nothing about prompts or about a specific tool. Tools change every month, and this is the reason why I like the framework: it is about how you think, not about what button you click.

The framework has four competencies. All of them start with the letter D, so it is easy to remember:

Look at the arrows in the diagram. They go in every direction, and this is important. The 4Ds are not steps that you do one after the other. You move between them all the time: you delegate, you describe, you discern, and then you go back and delegate differently.

Let’s go one by one.

1. Delegation

Delegation is deciding what work you do with AI, and what work you keep for yourself.

This is the competency I underestimated the most. Before you write any prompt, you have to answer a previous question: should I use AI for this at all? The course splits it in three parts:

• Problem awareness: you understand the goal and the work before you involve AI. What exactly do I need to achieve?
• Platform awareness: you know what the AI tools can do well, and where they are weak.
• Task delegation: you divide the work and decide who does each part, you or the AI.

Example from my work

Let’s say I have to migrate a UIKit screen to SwiftUI. This is a good ticket to think about delegation, because it has many different parts:

• Converting the layout code from UIKit to SwiftUI: I delegate this. It is mechanical and easy to review.
• Writing the first version of the unit tests for the view model: I delegate this too, and I review the cases.
• Deciding how this screen fits in the navigation of the app: I keep this one. It depends on product context and architecture decisions that the AI does not have, and I do not want to give them away.
• Deciding what happens with the old Objective-C code that still talks to this screen: I keep this one, at least the decision.

Without this step, I would just paste the whole ticket and hope for the best. With it, I use the AI where it is strong and I keep my attention for the parts that really need a human. For me, the main reason to think about delegation first is to save my own energy. 💡

2. Description

Description is how you communicate with the AI so it understands what you want.

This is the competency that most people already know as “prompt engineering”, but the course has a more complete view. You describe three different things:

• Product description: what you want as a result. Format, audience, style, constraints.
• Process description: how the AI should approach the work. Steps, what to consider, what to avoid.
• Performance description: how the AI should behave during the collaboration. Should it ask questions first? Be direct? Challenge my ideas?

I think the third one is the one that almost nobody uses, and it makes a big difference.

Example from my work

A weak description:

Write tests for my network layer.

A better description, using the three parts:

Product: Write unit tests for UserRepository using Swift Testing. Cover success, decoding error and no-internet cases.

Process: First read the existing tests in the Networking folder and follow the same naming and mocking style. Do not add new dependencies.

Performance: If something is not clear about how the mock works, ask me before you write code. Do not guess.

The second version takes one minute more to write, and it saves me a lot of back and forth later. And that last line, about asking before guessing, avoids many of the confident-but-wrong answers. 😅

3. Discernment

Discernment is evaluating what the AI gives you, with a critical eye.

The AI can sound very confident when it is wrong, and this is the reason why this competency is so important. The course uses the same three lenses as in Description:

• Product discernment: is the result good? Is it correct, relevant, complete?
• Process discernment: how did the AI get there? Is the reasoning logical, or did it skip steps?
• Performance discernment: how did the AI behave during our work? Did it follow my instructions, or did it drift?

Example from my work

Imagine I ask for help with a Combine pipeline and the AI gives me a solution that compiles and looks clean. Product discernment says: does it really do what I asked? I run it and I find that it works in the happy path, but it never cancels the previous request when the user types fast. The result looked good, but it was not good.

Process discernment is when I read how it reasoned and I see that it assumed all the code runs on the main thread, which is not true in my project. Performance discernment is when I notice that, after 20 messages, the AI forgot my rule about not adding new dependencies and suggested a third-party library. That is a signal to start a fresh conversation. ✨

The rule that I follow now: the more confident the answer sounds, the more I verify it.

4. Diligence

Diligence is taking responsibility for how you use AI and for what you deliver with it.

For me this is the “grown-up” competency. It has three parts:

• Creation diligence: being thoughtful about which AI systems and tools you choose, and how you set up the work.
• Transparency diligence: being honest with the people who need to know that AI was part of the work.
• Deployment diligence: taking responsibility for the output you share or ship. You verify it, and you own it.

Example from my work

Creation diligence: before I give a codebase to an AI tool, I think about what is inside. API keys, customer data, private SDK code. I check what the tool does with the data before I connect it.

Transparency diligence: when I open a pull request and an agent wrote a big part of it, I say it in the description, so the reviewer knows to look with more attention. I also do this for writing and documentation. It is not about feeling guilty, it is about giving the other person the context they need.

Deployment diligence is the simplest one to explain: if it goes to the App Store, it is my code. It does not matter who typed it. If it crashes in production, I cannot say “the AI wrote it”. So I read it, I run it, I test it. ✅

Why I like this framework

After finishing the course, there are three things that I keep in my head:

• Only one of the 4Ds is about talking to the AI. Description is the interaction. The other three (Delegation, Discernment and Diligence) happen before, after, and around it. Most of the advice that I see online is only about the first one.
• It does not depend on the tool. Today I use Claude Code, tomorrow it can be something different. The questions are the same: should I delegate this, did I explain it well, is the answer good, am I responsible for it?
• It is a loop, not a checklist. When the result is bad, the problem can be in any of the four places. Sometimes I did not describe it well, but sometimes I should not have delegated that task at all.

Final thoughts

If you use AI in your work, I recommend you take the course. It is free, it is not very long, and it made me more intentional about things that I was doing by habit. You can start in Anthropic Academy, and if you want to see my certificate, here is the credential. 🚀

And if you want a quick exercise for this week: take one task you do with AI, and ask yourself the 4 questions. What did I delegate? How did I describe it? How did I check the result? Am I ready to own it? You will probably find one D that you are skipping.