Anthropic's 4 Ds: The AI Fluency Framework

Generative AI is a type of artificial intelligence that creates new content, instead of just analyzing existing data. The difference from traditional AI is key: a spam classifier analyzes and categorizes an email that already exists; a generative model can write a new email from scratch. The first approach analyzes and classifies; the second creates something that didn’t exist.

Large language models (LLMs) are the best-known type of generative AI today. They’re called “language” models because they’re trained to predict and generate human language, and “large” because they contain billions of parameters — mathematical values that determine how the model processes information, somewhat like the synaptic connections in a brain.

How we got here

The leap wasn’t sudden. Three developments converged:

Architecture: the transformer architecture, introduced in 2017, changed how AI systems process text sequences by maintaining relationships between words across long passages — critical for understanding language in context.
Data: the explosion of digital data (websites, code repositories, text of every kind) gave models the raw material to develop a broad, nuanced understanding of language and concepts.
Compute power: specialized hardware (GPUs, TPUs) and distributed computing networks (clusters) made it possible to train models on all that data.

The combination of these three factors led to an important finding: scaling laws. As models grow and are trained with more data and more compute, their performance improves predictably — and, more surprisingly, emergent capabilities show up that nobody explicitly programmed, like step-by-step reasoning or adapting to new tasks with minimal instructions.

How a model gets trained

Training happens in two phases:

Pretraining: the model analyzes patterns across billions of text examples, predicting the next word over and over. By the end of this phase it has built something like a complex map of language and knowledge — but it’s, literally, a very competent “document completer,” nothing more.
Fine-tuning: the model learns to follow instructions, give useful responses, and avoid harmful content. This is where human feedback and reinforcement learning come in, rewarding and penalizing behaviors to make the model more helpful, honest, and harmless.

How an interaction works

When you write to an LLM, you’re giving it a prompt: text that the model reads and continues based on the patterns it learned during training. The model doesn’t look up prearranged answers in a database — it generates new text that statistically follows what you wrote.

There’s a practical limit to how much information an LLM can consider at once: the context window, something like its working memory. It includes your prompt, the model’s responses, and everything else you’ve shared in the conversation. Even though AI companies keep expanding it, it remains a real limit: the model doesn’t have unlimited access to information and can’t use content outside that window without specialized tools (like web search).

LLM strengths and limits

What it does well

Linguistic versatility: drafting emails in your voice, condensing lengthy reports, translating, explaining complex topics from any field.
In-context learning: it can go from helping you write poetry to explaining quantum computing, with no additional training — just what you give it in the conversation.
Conversational memory: it keeps the thread of the conversation, remembers what was said before, and builds on it.
Use of external tools: many LLMs can connect to the web, process files, or use other applications, which greatly expands what they can help you do.

Where it fails — and why

Each limit is explained by how the model works internally:

Knowledge cutoff. The model knows nothing about what happened after its training date. It needs tools like web search to learn about recent events.
Hallucinations. Training doesn’t verify every fact, so the model can reproduce inaccuracies or combine what it learned incorrectly, confidently stating something that sounds plausible but is wrong. Unlike a search engine, which retrieves existing documents, an LLM generates text based on statistical patterns — and that’s where it can hallucinate.
Context window limit. If a conversation or document exceeds it, the model stops “seeing” what fell outside (usually the oldest content first).
Non-determinism. Unlike traditional software, an LLM doesn’t always give the same answer to the same question — it makes probabilistic decisions about what text comes next. This is useful for brainstorming, but you need to account for it when you need consistency or precision. Some interfaces expose this control as “temperature.”
Complex reasoning. LLMs have historically struggled with multi-step math or logic problems, though extended-thinking models keep improving significantly here.
Access to specific data and tools. Even though a model can use external tools, if it doesn’t have access to a particular data source or tool, it simply can’t help you with that — like a brilliant colleague with no access to your company’s internal database.

The 4D framework for AI fluency

Using AI well isn’t just about knowing how to write a good prompt. It’s a set of habits you train, and it can be summarized in four interconnected competencies: the 4D framework.

The four competencies are:

Delineation
Discernment
Delegation
Diligence

They’re organized into two cycles that coexist at all times: an internal one, happening inside each conversation with the AI, and an external one, happening around that conversation — in your work, your team, your responsibility.

Internal cycle: Delineation + Discernment

This is the day-to-day mode of interaction: the one you already know, though you’re probably not exploiting it fully.

Delineation

Delineating is communicating effectively with the AI, and it goes well beyond “writing a good prompt.” It means defining:

the outcome you expect,
the format,
the target audience,
the style,
and the reasoning approach you want the AI to follow.

Asking “summarize this report” isn’t the same as asking “summarize this report for a non-technical executive audience, focusing on the three highest-impact findings, in under 300 words.”

You can also shape the role the AI plays in the interaction:

do you need a critic who challenges weak arguments?
a brainstorming partner?
a fact-checker who flags uncertainty?

You can ask for all of that — and combine it.

Delineation is the skill people pick up most naturally: specifying what they want, giving examples, refining the request. It’s a good starting point, and it improves with practice.

Discernment

It’s the complement to delineation: critically and thoughtfully evaluating what the AI hands back.

Are these statistics accurate?
Does the language reflect how your audience actually talks about this topic?
Did the AI account for every relevant factor?

Discernment isn’t accepting or rejecting the output wholesale. It’s an iterative process: you delineate, evaluate, adjust the delineation based on that evaluation, and try again — like fine-tuning understanding with a human teammate.

While most people already delineate fairly naturally, discernment is much harder to develop because it requires a much deeper understanding of the desired outcome. Questioning the AI’s reasoning, verifying facts, identifying missing context. That’s exactly where there’s the most room to grow, because it’s what sustains real collaboration with AI (not blind delegation).

External cycle: Delegation + Diligence

Using AI well in a single conversation is only part of the problem. The other part is understanding the implications of how and when you use it in your work, your team, and your context.

Delegation

Delegating is deciding what work humans do, what work the AI does, and how tasks get split. It requires understanding two things:

The work itself. Before drafting an email, ask yourself: is this a routine status update, where the AI can put together a first draft? Or is it a delicate negotiation where the tone needs to come from you?
The tools. If you work with sensitive data, you need to know the privacy and security characteristics of the AI system you’re using.

Once you understand the work and the tool well, you can split tasks intelligently, leveraging each side’s strengths.

Diligence

It’s the flip side of delegation: taking responsibility for how you use AI.

Being intentional about which parts the AI handles and which require your own expertise.
Being honest about the AI’s role with the people who need to know — your colleagues and stakeholders deserve to understand when and how it was used.
Verifying and standing behind every output before sharing it: confirming its accuracy and making sure the final product faithfully represents your goals and standards.

[!Don’t forget] You’re always responsible for the final result, whether or not you used AI to get there.

Delegation and diligence also run in a cycle: the decisions you make about what to delegate need to be paired with ongoing responsibility for how you use it — and that diligent practice, over time, leads to better delegation decisions.

The 4 Ds in action

Delegation — you decide which tasks the AI handles and which you do yourself.
Delineation — you use detailed descriptions to guide the AI’s work.
Discernment — you critically evaluate the results.
Diligence — you choose the right tools, you’re transparent about the AI’s role, and you take responsibility for accuracy.

The 4D framework applied to building software

Delegation: the builder’s toolkit

If you’ve spent time coding with AI, you’ve already noticed this: the hard part isn’t getting the AI to write code, it’s knowing what code you want it to write. Delegating isn’t a yes-or-no decision — it’s far more granular.

Picture yourself leading a project where the AI is your team. A good leader doesn’t just assign tasks — they frame the problem so everyone understands what they’re solving, define what a good outcome looks like, and decide which tasks to delegate and which to keep for themselves. That starts well before writing the first line of code.

Every builder has a six-capability toolkit, and the AI doesn’t perform equally across all of them:

👀 Empathy — what does the person you’re building for actually need? Not what they say they want, but what will genuinely serve them. This comes from talking to users and observing, not from the AI.
📝 Design — what should we build, and why? Judgment calls (text message or web page? exact times or ranges?). The AI can generate options; the decision is yours.
🏗️ Architecture — how is it structured? The AI knows patterns from thousands of similar systems, but it doesn’t know your constraints or where your team is headed. This is where human+AI combined works really well.
💻 Implementation — writing the code itself. This is where the AI is strongest, as long as you already know what to build and how to structure it. It’s the capability most worth delegating.
⚖️ Judgment — does it actually work? Is it good? Would you put your name on it? The AI tells you the code runs, not whether you solved the real problem.
🚀 Deployment — getting it to real users and learning from what happens: communication, measurement, iteration. The AI can draft release notes, but it doesn’t interpret why a user hesitates before clicking.

The shape of this list matters: implementation sits in the middle, and that’s where the AI is strongest. Empathy, judgment, and deployment sit at the edges, and that’s where the AI is weakest — and where the value of human work lives.

The builders who stand out aren’t the fastest ones — they’re the ones who frame the problem well, know what a good outcome looks like before they start, and can tell the difference between code that works and code that matters.

Delineation: translating what users need

Describing isn’t “prompt engineering.” It’s a higher-level competency that stays relevant even as the tricks for any given model change. You can think of it as a four-step chain, where the builder acts as translator:

User’s voice — what a real person says, with their tone, their emotion, and all the context they don’t say out loud. E.g.: “I want to see wait times before heading to the clinic” — behind that might be a two-hour wait, a sick kid in the car, indecision between this clinic and the ER across town. It’s real raw material, but not yet buildable.
Product requirement — you take that raw need and turn it into something measurable: “patients can see the estimated wait time on a mobile-friendly web page, updated every 5 minutes”. Every word there is a judgment call (mobile-friendly, not an app; estimated, not exact; every 5 minutes, not real-time) based on your own empathy work.
Technical specification — now buildable: “a web app that queries the clinic’s API and displays wait times with a responsive UI, refreshing every 5 minutes”. An engineer (or an AI) can start building with that, though it still leaves gaps: which stack? How are errors handled?
AI instruction — specific, contextualized, with well-defined constraints and edge cases: the stack, the data shape, what to do when there’s no data, and the tests it needs to pass.

The AI can’t hear what the user didn’t say, or decide that “estimated” is better than “exact” because an exact time would make clinic staff anxious. You know that, and your job is to carry it intact through all four steps.

When the translation breaks down at some step, a specific kind of failure shows up: code that works, but the product doesn’t. Tests pass, the user is still frustrated. That’s not a bug — it’s a delineation failure, and it usually happened upstream of the prompt. It’s worth diagnosing where the chain broke: did you not understand the user? Did you understand them but define the requirement wrong? Was the requirement fine but the technical spec lost something? Or was everything above fine and you simply gave the AI the wrong instruction?

[!A detail worth noting] Acceptance tests are also delineation — maybe the most powerful form of it, because something that passes or fails can’t be misinterpreted. Giving the AI a set of tests along with the prompt doesn’t just tell it what to build; it tells it how you’ll know it succeeded.

Discernment: five lenses for evaluating code

A product that works and a good product aren’t the same thing. When AI can produce something functional in minutes, telling that difference apart becomes the most valuable skill. There are five lenses — most engineering training stops at the first two:

Functional integrity — does it actually work? Bugs, failures, vulnerabilities. This is usually where traditional code review ends: necessary, but not sufficient. Key habit: ask the AI to write tests alongside the code, not after — and run those tests, because a test suite that never runs isn’t a safety net, it’s a false sense of security.
Production readiness — does it work well? Performance, scalability, reliability under load. The AI has blind spots here. It helps to explicitly ask it to stress-test its own code and state what production assumptions it made.
Fit — is it the right thing? Does it solve the user’s actual problem, or the problem they think they have? The patient asked about wait times, but what they really needed to know was whether a pediatrician was available in 20 minutes. The AI solves the stated problem — verifying it’s the real one is on you.
Quality of experience — is it actually good? Clear, intuitive, accessible? The AI doesn’t have taste, it has patterns: it’ll give you a competent interface nobody enjoys using. In a clinical context, this isn’t just aesthetics — it’s patient safety.
Responsible impact — is it responsible? Bias, privacy, unintended consequences. If the wait-time algorithm is trained on historical data reflecting systemic inequities, it can reproduce that same pattern — and it won’t flag it for you, it’ll just show a number.

The biggest problems almost never show up at lens one. AI is good at generating code that runs; it needs your oversight to produce something that actually matters. And there’s a useful signal about your own process: when something isn’t good enough, do you fix it yourself, or step back and delineate better what you needed? That pattern tells you whether you’re developing discernment or just building.

With AI, you can end up owning code you didn’t write. Diligence means catching up with that code, understanding it, putting it to the test, and catching the errors that slip through.

Three habits of a good engineer:

Recreate the “what didn’t I think of?” step. When you code it yourself, you notice edge cases and decisions along the way that you hadn’t anticipated. With AI, those decisions sometimes get made without you noticing — so ask explicitly: “can you verify users can’t see other users’ files?”
Ask what assumptions and trade-offs it made. After the AI builds something substantial: “what assumptions did you make? what security risks should I be aware of?”.
Disclose AI use as information, not as a disclaimer. If the AI wrote most of a PR, say so in the description — because it makes mistakes differently than humans do (confidently using deprecated APIs, code that’s clean locally but inconsistent with the rest of the codebase, invented behavior for cases you never specified). A reviewer who knows that can adjust their review accordingly.

==Pre-AI engineering best practices still hold== — maybe more than ever, because you now ship faster and understand a smaller fraction of what you shipped. Solid tests, observability (logs, error tracking, dashboards), and feature flags haven’t gone away: they’re what lets you move fast safely.

Putting the 4 Ds together

Delegate first. Before opening the editor, break down the problem. Implementation, scaffolding, templates, first drafts: solid candidates for the AI. Judgment calls, understanding the real user, and deciding whether what’s built is the right thing: that’s yours.
Delineate carefully. It’s not just “what to code” — it’s the user’s voice, the product requirement, the technical spec, the instruction, and the tests. A well-delineated task, with clear acceptance criteria, treats the AI like a competent junior collaborator with precise instructions.
Apply discernment as you work. Does it work? Does it work well? Is it the right thing? Is it responsible? Sometimes the AI builds exactly what you described, but not what solves the problem.
Practice diligence before shipping. Prototype freely — that’s how you learn — but ship selectively. Before something reaches real users: do you understand what it does? Can you explain it? Is there a way to know if it works? And you have to be willing to stop something of your own when the evidence says it doesn’t work — sunk cost is one of the hardest things to let go of, but a developer’s job is to serve the user, not to defend the software.

The four Ds aren’t a linear checklist: they’re dynamic. You’ll move from delegation to delineation, from there to discernment, and end up delegating differently next time. That’s AI fluency developing in practice.

Why it matters

The point of the framework isn’t “learning to use AI” as an end in itself. It’s freeing up time and headspace for the work that actually matters: the kind that requires human judgment, creativity, and deep contextual knowledge. AI doesn’t replace that — you protect it by developing these four competencies.

Sources: Anthropic (Anthropic Academy) — “What is generative AI”, “The 4D Framework for AI Fluency”, “Delegation & the builder’s toolkit”, “Describing what users need”, “Discernment for code”, “Diligence & sharing your work”, and “Looking forward”.