# AI Fluency for Builders --- # Lección: Welcome to AI Fluency for builders (Introduction and AI Fluency framework) ## Welcome to AI Fluency for builders ## What you'll learn By the end of this lesson you'll be able to: - Define AI Fluency and explain how it applies to your role as a builder - Build a reusable brief that gives AI your values, constraints, and context - Decide if, when and where to delegate to AI in the builder process ## Introduction to AI Fluency for builders (4 minutes) This video introduces builders — product people, designers, and makers — to the course, explains what AI Fluency actually means in practice, and previews the 4D Framework that will anchor every lesson that follows. [VIDEO — transcripción] Hi, I'm Michael, the CEO of CodePath. And I'm Kristen from the education team at Anthropic. Welcome to the AI Fluency for builders course. If you have ever shipped software, you already know that writing code is only a small part of the job. You have to figure out what problem was actually worth solving. You have to make hundreds of small decisions about how it should work, and then you have to get it into people's hands and learn from what happened next. That full process, from understanding a customer problem to shipping a solution that reaches them, is what we mean by being a builder. And AI is changing almost every part of that process right now. Most of what gets called AI training focuses on one narrow slice, writing better prompts to get better code out of a language model. That's useful, but it's not enough to develop lasting AI Fluency. You need to know what to build in the first place. And you need to evaluate whether the thing AI produced is actually right, not just technically functional, but solving the real problem, working with real users, and not creating unexpected new problems. AI Fluency is the ability to work with AI systems in ways that are effective, efficient, ethical, and safe. AI Fluency isn't a prompt library. It's a set of interconnected competencies that empower you to make great decisions regardless of the model or feature at your disposal. At the center of this course is the 4D Framework, developed by professors Joseph Feller and Rick Dakan in collaboration with Anthropic. It consists of four competencies: Delegation, Description, Discernment, and Diligence. Think of them as the operating system underneath every collaboration you have with AI. Delegation is about decomposing a problem into parts and deciding what role AI plays at each stage. Delegating implementation to AI is usually fine. Delegating judgment, the call about whether something is actually good and ready, is usually not advised. The best builders know the difference. Description is a builder's ability to ensure that every input, from user voice to product requirements to technical specs, make it into the implementation. Most AI training hyper-focuses on ensuring code is built where the test passes. That's important, but insufficient. Any missing input or context cascades downstream. A user complains that the tool doesn't work for them. You trace it back and discover the issue wasn't in the code. It was in how you understood and described the user problem. Builders must own every aspect of Description. Discernment is how you evaluate what AI gives you. Not just does it run, but does it run well? Does it solve the right problem? Is it actually good to use and is it responsible? AI has real blind spots. It can produce code that's locally correct, but breaks under load. It can generate UX that's functional, but confusing. Discernment is the skill of catching those gaps before your users do. Diligence is full ownership of the outcome, not just the output. Shipping is a skill with its own technical realities that AI rarely surfaces proactively. Migrations, rate limiting, monitoring. What happens when something breaks at 2 a.m. and you're the one who built it? Prototype freely, ship selectively. And be willing to veto something you built when the evidence says it isn't right. Think of AI as a capable but very literal collaborator. It's fast, it's knowledgeable, it doesn't get tired, but it needs clear tasks, real context about why you're building something, and specific feedback when it gets something wrong. Managing that collaborator well, knowing when to step in, when to let it run, how to give it the right brief is the core skill this course develops. By the end of this course, you'll approach AI with confidence and intentionality. You'll know how to leverage it to move faster without losing the judgment that makes what you build actually good. And you'll own the full building process, not just the coding slice in the middle. Let's get started. Course roadmap 4D Framework for AI Fluency Delegation, description, discernment, and diligence—the four competencies behind every productive AI collaboration. AI capabilities and limitations What today’s AI can and can’t do reliably, and why that shapes how you put it to work as a builder. Delegation & the Builder’s Toolkit How to decompose a problem, decide what AI handles at each stage, and define done before you write a line of code. Discernment for code and UX Evaluating AI output against what actually matters: correctness, quality, fit, experience, and responsibility. Shipping and next steps Taking full ownership of what you build with AI, and where to keep building your fluency. ## Key takeaways - Builders own the full arc from customer problem to shipped solution. - AI Fluency means working with AI effectively, efficiently, ethically, and safely. - The 4D Framework (Delegation, Description, Discernment, Diligence) anchors every lesson in this course. - Delegating implementation is usually safe. Delegating judgment is usually not. - Most AI failures trace back to description, discernment, or diligence failures made earlier. ## Exercise ## Build your builder brief This exercise creates a reusable context document you'll give AI at the start of any project. Think of it as onboarding your AI collaborator — you'll reference it in exercises throughout the course. ## Part I: Self-Reflection Before opening any AI tool, write down your answers to these four questions: - What are you building right now, or planning to build? Name the product, the users, and the problem it solves. - What’s your role — and what are you personally responsible for shipping? - Where do you already use AI? Where have you avoided it, and why? - Complete this sentence: “If AI could handle _______, I could spend more time on _______, which is where the most important decisions get made.” ## Part II: Build your brief with AI Open Claude (or any AI assistant). Tell it you’re a builder and you want to create a reusable context document for future AI collaboration. Share your Part I answers and ask it to draft a brief you can paste into future sessions. Key areas to cover: what you’re building and who it’s for, your role and what you own, your constraints (team size, stack, timelines, non-negotiables), and where you want AI involved — and where you don’t. Review it together and add anything missing. Request a format that’s easy to copy and reuse. This is your builder brief for the course. ## Lesson reflection - When you completed the sentence “If AI could handle ___, I could spend more time on ___” — what did that reveal about where your energy is going versus where it should be? - In your builder brief, what constraints or values did you name that most AI interactions have been missing? ## What's next In the next lesson, we introduce the 4D Framework — four interconnected competencies that will shape every AI collaboration in this course: Delegation, Description, Discernment, and Diligence. ## Feedback As you progress through the course, we’d love to hear from you about how you are using concepts from the course in your work, plus any feedback you may have. Share your feedback here. ## Acknowledgments and license Copyright 2026 Anthropic. This course was developed in partnership with CodePath, building on the AI Fluency Framework developed by Prof. Rick Dakan (Ringling College of Art and Design) and Prof. Joseph Feller (University College Cork). Released under the CC BY-NC-SA 4.0 license. --- # Lección: The 4D Framework (Introduction and AI Fluency framework) ## The 4D Framework ## What you’ll learn Estimated time: 20 minutes By the end of this lesson you’ll be able to: - Define all four 4D competencies and how each shapes your AI collaborations - Tell the inner loop from the outer loop and know when to apply each - Map your current work to the 4Ds and find your biggest opportunity ## The 4D Framework for AI Fluency (7 minutes) This video introduces the 4D Framework — Delegation, Description, Discernment, and Diligence — and explains how each competency applies to your daily work. [VIDEO — transcripción] We want you to build lasting AI Fluency. That means giving you the tools to use AI efficiently, ethically, and safely, no matter what challenges you might face. In this video, we'll walk through the 4D Framework, four interconnected competencies that, when combined, transform how you work with AI. To help you apply this framework, we'll look at two modes of interaction with AI. The first mode is likely the one you're familiar with, how to engage with AI effectively on a day-to-day basis. This is the inner loop of Description and Discernment. You describe what you want AI to help you with, and then you discern if it meets your expectations. This is a critically important skill set when learning AI, but it's not sufficient on its own. In addition to everything that happens within your interactions with AI, there's also an outer loop of Delegation and Diligence. This is everything that happens in your workplace, community, and life around the use of AI. Should you be using AI at all? And if you do, what are your ethical responsibilities to ensure you're proceeding intentionally and responsibly? We'll be doing a brief overview of all of this today. But if you'd like a deeper understanding, check out the AI Fluency Framework and Foundations course on Anthropic Academy. Let's begin with a close look at the inner loop of Description and Discernment. Again, this happens during your day-to-day interactions with AI. Description just means communicating effectively with AI systems. This goes beyond writing good prompts. It starts with defining what you want, your outputs, format, audience, and style. Instead of "Write a summary of this report," try getting specific. "Summarize this report for a non-technical executive audience, focusing on the three highest impact findings in under 300 words." But you can also define how the AI approaches your request. Think of it like giving instructions to a collaborator, specifying the steps, the order of operations, or the reasoning approach you want the AI to follow. And you can shape the AI's behavior during your collaboration as well. Do you need a critical reviewer who pushes back on weak arguments? A brainstorming partner who builds on every idea? A fact checker who flags uncertainty? You can ask for all of it. In our research, we found that Description skills are the ones people pick up most naturally. Things like specifying what you want, giving examples, and refining your requests. Most people are already doing some version of these, and that's a great starting point. As you iterate and collaborate with AI, it's likely you'll get more comfortable and effective at Description. Discernment, the companion to Description, asks you to thoughtfully and critically evaluate your AI collaborator. Start with the output itself. Are these statistics accurate? Does this language reflect how your audience actually talks about this topic? Then look at how AI got there. Did it consider all relevant factors? Importantly, Discernment doesn't just mean accepting or rejecting AI outputs. It involves iteration to get where you want to go. And while most people describe what they want fairly naturally, Discernment is much rarer. In our research, skills like questioning AI's reasoning, checking facts, and identifying missing context were among the least common behaviors we observed. And that's where there's room to grow. It can be an easy step to miss, but it's critically important. It's what drives true AI collaboration. That's why Description and Discernment work together in a loop. You describe what you need, evaluate what you get, and then refine your Description based on that evaluation. It's like working with a human teammate. You build a shared understanding through conversation. Using AI well in day-to-day interactions is only one piece of the puzzle. It's critical to understand all the ethical and social implications of AI use in your context. This is where the Delegation-Diligence loop comes in. Delegation is deciding what work should be done by humans, what work should be done by AI, and how to distribute tasks between them. Good Delegation starts with understanding the work itself. Before drafting an email, ask yourself, "Is this a routine status update where AI can handle a first draft?" Or is this a sensitive negotiation where tone and nuance need to come directly from you? You need to understand your tools as well. If you're working with confidential data, for example, you'd want to consider the privacy and security features of the AI system you're using. When you understand both the work and the tools, you can thoughtfully split tasks to leverage the strengths of each. We pair Delegation with Diligence, taking responsibility for how you use AI. That means being thoughtful about which AI systems you use and how you interact with them. Maybe you use AI to draft a project proposal, but you're intentional about which sections it works on and which require your own expertise. It means being honest about AI's role in your work with the people who need to know. Your colleagues and stakeholders deserve to understand when and how AI has been involved. And it means taking responsibility for verifying and vouching for the outputs you use or share. You check every claim, confirm accuracy, and make sure any final deliverable generally represents your goals and standards. You're always accountable for the final result. Delegation and Diligence work together as a loop. The thoughtful choices you make about what to delegate to AI must be matched by ongoing responsibility for how you use it, and your diligent practices inform smarter Delegation decisions over time. The 4Ds come alive when you use them together. Writing a strategic plan? Use Delegation to decide what AI handles, versus what you bring yourself. Use strong Description to guide the AI's work. Apply Discernment to evaluate the results. And practice Diligence throughout by choosing appropriate tools, being transparent about AI's role, and taking responsibility for accuracy. This framework is about making you more effective at the work that matters, work that requires human judgment, creativity, and deep understanding of your context. Throughout this course, you'll apply these competencies to real challenges: drafting communications, analyzing complex information, automating routine tasks, and building sustainable AI workflows. The skills you take away will serve you as AI continues to evolve. You can learn more about AI Fluency in Anthropic Academy, and we'll continue to share our research on this topic on Anthropic's blog. ## Key takeaways - The inner loop (Description and Discernment) guides daily AI interactions. The outer loop (Delegation and Diligence) guides bigger decisions about when and how to use AI. - Delegation means deciding what AI handles and what stays with you. - Description means communicating clearly what you need and how you want AI to approach it. - Discernment means evaluating what AI gives back before acting on it. - Diligence means owning the final result fully, regardless of AI’s role. ## Exercise ## Map your builder brief to the 4Ds Pull out the builder brief you created in the previous lesson. This exercise uses it to show you which competencies you’ll need most — and gets you into a real interaction before the next lesson. Part I: Tag your document Read through your builder brief and mark each goal, concern, or task with the competency it most relates to: - Delegation: decisions about what AI should and shouldn’t handle in your builds - Description: questions about how to communicate requirements and intent clearly - Discernment: concerns about evaluating or trusting what AI produces - Diligence: questions about responsibility, testing, and accountability for what you ship Which competency shows up most? That’s where your attention is already focused — and usually where you’ll see the fastest gains. Part II: Try one From your builder brief, pick one task that came up — something real and waiting for you. Before opening AI, write down: - Which competencies apply? (Most real tasks involve more than one.) - What does “good enough” look like for this output? Then take one round with AI on that task. Don’t aim for a finished product — just get a useful starting point. Part III: Reflect Look at what you got back. Which competency felt natural? Which caught you off guard? Note one thing you’d do differently on the next pass. ## Lesson reflection - Were you surprised by which competency dominated your mapped questions? What does that tell you? - How might the two loops have changed a recent AI interaction you had? ## What’s next In the next lesson, we’ll look at how generative AI works — what it can and can’t do — so you can put the 4D Framework into practice with clear-eyed expectations. ## Feedback As you progress through the course, we’d love to hear from you about how you are using concepts from the course in your work, plus any feedback you may have. Share your feedback here. ## Acknowledgments and license Copyright 2026 Anthropic. This course was developed in partnership with CodePath, building on the AI Fluency Framework developed by Prof. Rick Dakan (Ringling College of Art and Design) and Prof. Joseph Feller (University College Cork). Released under the CC BY-NC-SA 4.0 license. --- # Lección: AI capabilities & limitations (How AI works) ## AI capabilities & limitations ## What you'll learn Estimated time: 25 minutes By the end of this lesson you'll be able to: - Define generative AI and explain how it differs from other AI types - Explain the three developments that made modern LLMs possible - Identify what current AI does well and where it reliably falls short ## What is generative AI (12 minutes) This video covers how large language models like Claude are built and trained, and what that means for what they can — and can’t — reliably do when you put them to work in your business. [VIDEO — transcripción] [snorts] [music] >> Hi. My name is Kyra and I'm on the education team at Anthropic. Welcome to our exploration of generative AI. In this video, we'll dive into what generative AI actually is and the technological breakthroughs that made these systems possible. Then we'll look at what generative AI does well and how it falls short. You might interact with generative AI daily without fully understanding what's happening behind the scenes. Let's change that. Generative AI refers to artificial intelligence systems that can create new content rather than just analyzing existing data. For example, while traditional AI might classify emails as spam or not spam based on patterns, generative AI can write a completely new email for you. The first approach analyzes and categorizes. The second creates something new that didn't exist before. This represents a fundamental shift in AI capabilities. Large language models or LLMs, like Anthropic's Claude models, are a prominent type of generative AI. 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 synaptic connections in your brain. The path to today's generative AI wasn't sudden. It involved three crucial developments coming together at the right time. First, there were algorithmic and architectural breakthroughs that fundamentally changed how AI systems learn. While neural networks have been around conceptually for decades, the development of the transformer architecture in 2017 was a game-changer. This architecture excels at processing sequences of text while maintaining relationships between words across long passages, which is critical for understanding language in context. Second, the explosion of digital data provided the essential raw material for training. Modern LLMs like Claude learn from diverse sources such as websites, code repositories, and other text that represent human knowledge and communication. This vast tapestry of information helps models develop a broad and nuanced understanding of both language and concepts. And third, massive increases in computational power made it possible to train these complex models on all that data. Specialized hardware like GPUs or graphics processing units and TPUs or tensor processing units, along with distributed computing networks often called clusters, enable processing that would have been impossible just a few years earlier. The combination of these three factors led to an important discovery known as the scaling laws. These empirical findings showed that as models grew larger and trained on more data with more computing power, their performance improved in predictable ways. More surprisingly, researchers found that entirely new capabilities began to emerge as these models grew larger. Abilities no one explicitly programmed like reasoning through problems step-by-step or adapting to new tasks with minimal instruction. Generative AI is trained in two phases. During the first phase, also called pre-training, LLMs like Claude analyze patterns across billions of text examples. Imagine reading every website and piece of text you could find. Not just to absorb information, but to understand the statistical relationships between words, phrases, and concepts. At this stage, the model essentially builds something like a complex map of language and knowledge. This pre-training process involves showing the model text and asking it to predict what comes next. Through many iterations, the model gradually refines its predictions, learning the patterns that make language coherent and meaningful. At the end of pre-training, the model is a very competent literal document completer. After pre-training, models undergo additional training called fine-tuning, where they learn to follow instructions, provide helpful responses, and importantly, avoid generating harmful content. This often involves human feedback to improve the model's performance, as well as reinforcement learning, which uses rewards and penalties to shape the model's behavior toward being more helpful, honest, and harmless in the case of Anthropic's models. Once models are trained, they are then deployed for you to interact with. When you interact with Claude or another LLM, you're providing a prompt, which is a text that the model reads and then continues from based on patterns it learned during training. The model isn't retrieving pre-written answers from a database. Instead, it's generating new text that statistically follows from what you've written. There's also a practical limit to how much information an LLM can consider at once, known as the context window. Think of this as the AI's working memory. The context window includes your prompts, the AI's responses, and any other information you've shared in your conversation. While AI companies continue to grow the context window to allow for longer documents and conversations, these limits remind us that these systems don't have unlimited access information and cannot use content beyond their current context window without specialized tools like web search. Bringing this together, three characteristics make modern generative AI so powerful. Its ability to process vast amounts of information during training, its in-context learning ability that lets it adapt to new tasks from instructions or examples in your prompt, and emergent capabilities that arise from scale and sometimes surprise even their creators. Now that you have a sense for how these systems work, let's look at what that means in practice. Think of this as getting to to a new colleague. Understanding their strengths and limitations helps you collaborate more effectively. You might be amazed at how versatile modern language models can be. They're skilled at language in ways that seemed impossible just a few years ago. Crafting emails that capture your voice, condensing lengthy reports into clear summaries, translating between languages, and even explaining complex topics across countless fields from microbiology to marketing strategy. What's particularly notable is how these models can shift between different tasks without needing additional training. The very same system that helps you write poetry or brainstorm ideas for your birthday party can turn around and help you understand quantum computing concepts or analyze quarterly business trends, all through simple conversation. These models can also maintain the thread of a conversation, remembering what you discussed earlier and building upon it. If you mention your project deadline in passing and refer back to it later within the conversation, AI typically understands what you're talking about, much like a human conversation partner would. Many modern LLMs can now also reach beyond their own knowledge by connecting to external tools and information sources, allowing them to search the web, process files, or even use other applications to enhance their capabilities. This dramatically expands what they can help with. However, just like any technology, LLMs as they exist today also have certain limitations. And notice how each one connects back to how the system works. First, AI models are bounded by their training data. LLMs have a knowledge cutoff date based on when they were trained, the point after which they have no innate knowledge of the world. For example, a model with a cutoff date of November 2024 wasn't trained on any data after that point. Imagine someone who went into a retreat without internet access at a specific date. They wouldn't know about the events that happened after they left. Models need tools like web search to learn about recent developments. Additionally, the training process doesn't verify every fact in the training data. This means models can sometimes learn and reproduce inaccuracies that were present in their training data. They can also make mistakes when trying to piece together information they've learned. This leads to what is often called a hallucination. AI confidently stating something that sounds plausible, but is actually incorrect. Unlike search engines that simply retrieve existing documents, LLMs generate responses based on statistical patterns, sometimes producing hallucinations. Imagine a friend who tells a story with absolute confidence only to have the details completely wrong. AI can sometimes be like that. There's also the context window limit we discussed earlier. If a conversation or document exceeds it, the AI won't be able to consider information that falls outside the window, usually on a first-in, first-out basis. Depending on the model, this can limit its ability to process large documents or remember an entire conversation. Furthermore, unlike traditional software that produces identical outputs given the same inputs, LLMs are somewhat unpredictable by default, also known as non-deterministic. Ask the same question twice and you might get slightly different responses each time. This variability stems from the nature of how these models generate text. They're making probabilistic decisions about what text should come next based on patterns in their training data and certain settings that developers can tweak. This creative variability can be great for brainstorming and generating diverse ideas, but requires awareness when consistency or accuracy are critical. Some LLM interfaces offer settings to control this randomness when needed, often referred to as temperature. Additionally, while these models are improving rapidly, they've historically shown limitations with complex reasoning tasks, particularly mathematical or logical problems requiring multiple steps. The good news is that the newer reasoning or extended thinking models specifically designed to think step-by-step are showing strong progress in these areas. And finally, while models like Claude can now access external tools, they may still lack access to specific data sources or specialized tools that would be needed for certain tasks. It's like having a brilliant colleague who can't access your company's internal database. Their ability to help will be limited no matter how smart they are. If a model doesn't have access to a piece of data or a tool that's needed to answer a question, then it should not come as a surprise that it won't be able to help. The field of generative AI is a rapidly evolving. Researchers are working to address current limitations through techniques like retrieval augmented generation, which connects models to external knowledge and data sources, as well as expanding their ability to use tools and improving their reasoning capabilities. That said, some limitations will likely remain for the foreseeable future, even if we don't know exactly what those limitations will be. Understanding what AI can and cannot do is essential for AI fluency and helps you determine when and how to best incorporate these systems into your work and daily life. The most effective applications will leverage the complementary strengths of humans and AI. We bring critical thinking, judgment, creativity, and ethical oversight that AI may struggle to replicate. AI offers speed, scale, pattern recognition, and the ability to process vast amounts of information. These complementary strengths will evolve as the technology evolves. That's why continued learning and experimentation are so valuable. They help you stay abreast of these changes and discover new possibilities. In the exercises across this course, you'll have a chance to explore these concepts firsthand through conversations with AI. This direct experience will help help an intuitive feel for what generative AI can do, can't do, and how to best work with it. ## Key takeaways - Generative AI creates new content rather than analyzing existing data. - Three developments made modern LLMs possible: the transformer architecture, vast training data, and massive compute. - Training has two stages. Pre-training learns patterns from billions of examples. Fine-tuning teaches the model to follow instructions helpfully. - Current strengths include versatility across tasks, conversational fluency, and tool use. - Current limits include knowledge cutoffs, hallucinations, and unreliable complex reasoning. - The best applications pair your judgment, creativity, and oversight with AI’s speed and scale. ## Exercise ## Testing the edges This exercise gives you firsthand evidence of what generative AI does well and where it falls short, using a coding problem you already know cold — so you have a concrete gut check, built from your own observations, when deciding what to trust AI with. Part I: Self-Reflection (on your own) Pick a coding domain you know well, where you’d immediately spot an error. Jot down: - The topic (e.g., your rate-limiting logic, how you handle async state, the DB query you optimized last quarter) - Two or three things about it any competent engineer should get right - One common misconception or tricky implementation detail - One thing that’s changed recently — a library update, a deprecation, a new best practice Part II: Collaboration (with AI) Open a conversation with Claude (or any AI assistant you prefer) and run three quick chats. Write down what you notice after each one. - Versatility test. Ask the AI to explain your topic three different ways in a single response: once for a non-technical PM, once for a mid-level engineer joining your team, and once for a senior engineer doing code review. Did the shifts in depth actually land, or did it just change vocabulary? Which version was strongest? - Hallucination test. Ask the AI to recommend specific libraries, packages, or documentation for your coding problem. Spot-check at least one: does it exist? Is the API accurate? Is the version current? - Knowledge cutoff + reasoning check. Ask something time-sensitive about your domain: a recent framework update, a deprecated pattern, or a security patch. Does it flag that its information might be outdated — or present stale info as current? Then ask it to work through the tricky implementation detail you wrote down in Part I. Did it actually resolve the confusion, or just restate the correct answer? Part III: Reflection Which capability from the video showed up most clearly? Which limitation surfaced — and would you have caught it if this weren’t a domain you know well? Based on this, what’s one task you’d feel fine handing to AI, and one you’d want to keep a closer eye on? Stretch goal: Run the same topic through a second AI tool. Were the errors and strengths the same? ## Lesson reflection - How does knowing how these systems are trained change the way you’ll work with them? - What ethical considerations come to mind given how generative AI works and where it falls short? ## What's next Now that you’ve tested AI’s edges firsthand, in the next lesson we go deep on the first D: Delegation. You’ll frame a real problem, map it across the builder’s toolkit, and make deliberate choices about where AI plays a role — before writing a single line of code. ## Feedback As you progress through the course, we’d love to hear from you about how you are using concepts from the course in your work, plus any feedback you may have. Share your feedback here. ## Acknowledgments and license Copyright 2026 Anthropic. This course was developed in partnership with CodePath, building on the AI Fluency Framework developed by Prof. Rick Dakan (Ringling College of Art and Design) and Prof. Joseph Feller (University College Cork). Released under the CC BY-NC-SA 4.0 license. --- # Lección: Delegation & the builder's toolkit (The 4D framework for builders) ## Delegation & the builder's toolkit ## What you'll learn Estimated time: 45 minutes By the end of this lesson you'll be able to: - Introduce the builder's toolkit and where AI adds value at each stage - Explain why delegating implementation is safe and delegating judgment is not - Write acceptance tests that define done before a single line of code exists ## Delegation & the builder's toolkit (5 minutes) Before you write a single line of code, you make a dozen decisions that shape whether what you build will matter. This lesson reframes delegation: it’s not “should I use AI here?” but “I have a customer problem — how do I break it down, and what role does AI play?” [VIDEO — transcripción] If you've spent any time building with AI, you've probably noticed something. The hard part isn't getting AI to write code, the hard part is knowing what code you want an AI to write. Many people think of delegating something to an AI as a simple yes or no question. But for builders, knowing exactly what and how to delegate is much more complex. Your customer comes to you with a problem. How do you decompose it into something that you can actually build? And what role does AI play at each stage of that work? Here's a useful frame. Imagine yourself as the lead on a project and AI as your team. A great lead doesn't just assign tasks. They frame the problem so everyone understands what they're solving. They set goals so the team knows what good looks like. They decide what to tackle first. And critically, they know which decisions to make themselves, and which ones to hand off. That's Delegation in the builder sense. And it starts well before any code gets written. Every builder carries a toolkit that they may not know that they have. You could boil it down to six capabilities you can reach for at any different moment in a build. AI can help with all six, but it's much stronger at some than others, and knowing the difference is a key part of AI fluency for builders. The first capability is empathy. What does the person we're building for actually need? Not what they said that they want, but what will actually truly help their work. This is where you talk to users and observe what frustrates them. AI can help you organize what you learn here, but it can't sit with a clinic receptionist and notice that she checks her phone 40 times a day because patients keep calling to ask about wait times. That observation is all you. The second is design. What should we build, and why? This is where you weigh trade-offs, make bets, and decide what matters. Should it be a text message or a web page? Should it show exact wait times or ranges? Those are judgment calls. All AI can do is generate options, but the judgment about which option fits is yours. Third is architecture. How should the thing be structured? What are the pieces, and how do they fit together? AI knows patterns. It's seen a thousand systems like the one you're sketching, but it doesn't know your constraints, your team skills, or what you need to change six months from now. 'Human plus AI' works really, really well here. Fourth is implementation, writing the actual code. This is where AI is the strongest. Once you know what you're building, and how it should be structured, AI can write working code effectively. This is the capability you should delegate most aggressively. If you've entered this stage without clearly defined tests and success checkpoints, you've probably skipped a step. Fifth is judgment. Does it actually work? Is it actually good? Would you put your name on it? AI will tell you the code runs, but it won't tell you if the experience feels right, whether the edge cases matter, or whether you've solved a real problem at hand. Judgment requires your expertise, standards, and perspective. Last is shipping. Getting it to real users and learning from what happens. This means communication, measurement, iteration. AI can draft release notes, but it can't read the room when your user hesitates before clicking. Now look at the shape of that list. Implementation sits right in the middle, and that's where AI is the strongest. Empathy, judgment, and shipping sit at the edges, and that's where AI is the weakest. That's the key insight for this course. AI is the strongest in the middle of the toolkit, and weakest at the edges. The edges are where the human work lives. The edges are where the value is. So what does good Delegation look like in practice? It looks like spending real time at the beginning of a project getting clear on who you're building for, and defining what success means. It looks like inspecting the results skeptically, and keeping judgment calls in your own hands. There's a temptation, once you have a tool that can write code instantly, to skip straight to building, to treat empathy and design work as overhead. Resist that feeling. The faster AI makes implementation, the more your value shifts to everything around it. The builders who thrive in this era won't be the ones who prompt the fastest. They will be the ones who frame problems clearly, who know what good looks like before they start, and who can tell the difference between code that runs and code that matters. The work starts now. Let's get into it. The Builder’s Toolkit Click any capability to see where AI fits in your build process. ▼ AI is strongest here Empathy Design Architecture Implementation Judgment Shipping Step 1 of 6 Empathy AI weak Understanding who you’re building for. AI can surface data and personas — it can’t feel the gap. Step 2 of 6 Design AI moderate Translating user needs into an experience worth having. AI generates patterns quickly; you bring taste and context. Step 3 of 6 Architecture AI moderate Structuring a system that holds up under real conditions. AI knows common patterns; your constraints are yours to specify. Step 4 of 6 Implementation AI strong Write, debug, and iterate on code. This is where AI genuinely excels — delegate freely here. Step 5 of 6 Judgment AI weak Deciding what’s right, good enough, and worth shipping. AI can list options; it can’t own the call. Step 6 of 6 Shipping AI moderate Getting it in front of users and iterating. AI automates steps; responsibility is yours. ← ← ← ← ← → → → → → ## Key takeaways - Delegation means decomposing the problem first, then deciding what AI handles at each step. - Write acceptance tests before code. They give you and AI a shared definition of done. - As AI accelerates implementation, your value shifts to framing problems and raising the bar. ## Exercise ## The Clinic Wait Time Project, Part 1 This project threads through the entire course. You’ll return to it in every lesson, and by the end you’ll have built something real. But in this lesson, you write zero code. That’s intentional. The scenario: A community health clinic needs a way for patients to check wait times before coming in. That’s all you’ve been told. Your job this session is to do the work that comes before building. You’ll produce three deliverables. ## Deliverable 1: A Problem Brief (one page max) Answer these questions in plain language: - Who are the users? Be specific. Patients, yes — but which patients? What about staff? Who else touches this? - What do they actually need? Not “a wait time checker.” What outcome are they hoping for? - What does a great solution feel like to use? Describe the experience, not the features. - What are the real constraints? Think budget, technical skill at the clinic, patient access to devices, privacy requirements. ## Deliverable 2: A Delegation Plan Map the build to the six toolkit capabilities. For each one, decide which AI collaboration mode fits best: Automation (AI does it, you check), Augmentation (you and AI work it together), or Agency (AI operates with latitude inside boundaries you set). Make a simple table — six rows, one per capability. ## Deliverable 3: Acceptance Tests Write five to seven statements that define “done.” Each must be concrete enough that a stranger could tell you whether the finished product passes or fails. Good: “A patient with a basic smartphone can find the current wait time in under 30 seconds without creating an account.” Bad: “The system is easy to use.” ## Lesson reflection - Where did you spend most of your time across the six capabilities on a past project? Where should you have spent more? - If implementation became effectively free tomorrow, where would your value as a builder come from? ## What's next In the next lesson, we move from delegation to description. You’ve decided what to build and who’s doing what — now you need to communicate that clearly enough that AI can actually execute it. ## Feedback As you progress through the course, we'd love to hear from you about how you are using concepts from the course in your work, plus any feedback you may have. Share your feedback here. ## Acknowledgments and license Copyright 2026 Anthropic. This course was developed in partnership with CodePath, building on the AI Fluency Framework developed by Prof. Rick Dakan (Ringling College of Art and Design) and Prof. Joseph Feller (University College Cork). Released under the CC BY-NC-SA 4.0 license. --- # Lección: Description & building great things (The 4D framework for builders) ## Description & building great things ## What you'll learn Estimated time: 45 minutes By the end of this lesson you'll be able to: - Translate a user need to precise AI instruction using the Description Chain - Spot when a description failure cascades and trace it back to the link that broke - Express intent through tests that tell AI exactly what success looks like ## Describing what users need (5 minutes) Most AI training teaches you to write better prompts. That’s necessary but not sufficient for building great products. This lesson maps the full Description Chain: the path from a messy human need to a precise instruction AI can act on, with the builder as the translator at every step. [VIDEO — transcripción] So in the last module, you spent real time understanding the problem before touching any tools. You wrote the problem brief. You wrote acceptance tests. You decided what you keep, and then what you delegate to AI. But now, you have to turn all of that into something, something that AI can actually act on. Most AI training treats 'Description' as prompt engineering. We're going to approach this task differently by considering all the aspects of Description that will help you solve the problem you've clearly defined. Description is a high-level competency that will remain relevant, outlasting tips and tricks that may change from model to model. Recall the six capabilities in the builder's toolkit. Before implementation, we have to define the user need. Here's the full picture. Four steps directly tied to the capabilities in your toolkit, with the builder as the translator and the heart of each step. Let's use the project you're already working on. The first step is user voice. This is what a real person actually says. For example, "I want to see wait times before I go to the clinic." Notice the tone, the emotion. It carries context the speaker didn't say out loud. That it's been two hours already. They have a kid in the car, and they're deciding between this clinic and urgent care across town. Use your own empathy to connect and observe with what goes unsaid by the user. User voice is just raw material. It's true, and it's not yet buildable. So the second part is product requirement. This is where you take that raw user need, and you scope it into something measurable. Patients, for example, can view estimated wait times via a mobile-friendly webpage, perhaps updated every five minutes. You see what you did there? You've made decisions. Mobile-friendly, not an app. Estimated, not exact. Every five minutes, not real time. Each is a key judgment call that you made based on what you learned in your own empathy work. Ensuring that there are very clear, concrete criteria helps the AI do its job better when it gets to the implementation step. The third piece is the technical spec. Now you're getting into the real building. A web app, for example, that pulls a clinic API for wait data and displays it with a responsive UI, refreshing on a five minute interval. That is implementable. An engineer could actually read that and start building. So could an AI. But notice it still leaves room. Which stack? How errors get handled? What happens when the AI goes down? The fourth step is AI instruction. Specific, contextualized with constraints, and edge cases clearly defined. The stack you're using and the shape of the data. What to do when there's no data. The test that it has to pass. It's critical that you give the AI specific things it can verify. This helps it work more effectively, and for longer. So here's why this matters. Builders who think about carefully describing all aspects of the problem get the best results with AI. The more thoughtful the Description, the better the output. AI can't hear what the user didn't say. AI can't decide that estimated is the right requirement, because exact times would make the clinic staff anxious about being held to them. It can't know that responsiveness matters because patients are checking wait times while they're en route. You know those things. Your job is to carry them intact as you describe what you need to the AI. Sometimes the translation breaks, and when it does, you get a specific type of failure. Code that works, but the product doesn't. The test might pass, but the user is still frustrated. That's not a bug, that's a Description failure, and it usually lives upstream of the prompt. So a big part of your job as a builder is actually forensic. When the thing you built misses the mark, you trace it back. Was it a user understanding failure, where you never really heard what they needed in the first place? Was it a requirement failure, where you heard them, but then you scoped it wrong? Was it a spec failure, where the requirement was actually right, but the technical translation lost something? Or a prompt failure, where everything upstream was solid, and you just instructed the AI poorly? So one more idea before we build. Your acceptance tests from the last module are a form of Description too, maybe the most powerful kind. A well-written test is a description of intent that can't be misread because it either passes, or it doesn't. When you hand AI a set of tests alongside your prompt, you're not just telling it what to build, you're telling it how you'll know if it succeeded. That changes what you get back. So in this module, you're going to write detailed descriptions for AI with your clinic project. Product requirements, technical specs, tests, prompts, and then for the first time in this course, we're going to build. You'll demo what you build to someone playing a clinic patient, and you'll ask two questions. First, did the test pass? And second, is the user satisfied? If the answer to the first is yes and the second is no, that's not a failure. That's the most useful thing that can happen to you in this module. It means your test described the wrong thing, and now you know exactly where in the chain to look. Let's get to it. ## Key takeaways - The Description Chain connects user voice to requirement to technical spec to AI instruction. Prompt engineering is only one link. - The builder is the translator at every step. AI cannot hear what the user did not say. - Code that works but the product doesn’t is a description failure. Find which link broke upstream. - Tests are the most precise form of description. A passing test with an unhappy user means you described the wrong intent. - Every step involves judgment calls the previous phase did not make for you. ## Exercise ## The Clinic Wait Time Project, Part 2 You’re picking up exactly where the last lesson left off. Pull out your problem brief, your delegation plan, and your acceptance tests. ## Step 1: Write the product requirement One paragraph. Take the user need from your problem brief and scope it into something measurable. Every adjective should be a decision you can defend. If you write “fast,” write how fast. If you write “simple,” describe what simple means for a patient checking from a phone in a parking lot. ## Step 2: Write the technical spec Half a page. Describe what gets built and how it’s structured. Name the pieces. Name how they talk to each other. Use AI in augmentation mode here: share your product requirement, ask it to propose a technical approach, then push back on anything that doesn’t fit your constraints. ## Step 3: Tighten your tests Revisit your acceptance tests from the previous lesson. Rewrite them so each one is something code could pass or fail. Add at least two edge cases: what happens when the clinic is closed, when there’s no data, when the wait time is zero. ## Step 4: Write your AI prompts and build Write the instructions that turn your spec into working code. Include your constraints, your stack choices, and your tests. Build the first version. ## Step 5: Demo it Find a partner. They play a clinic patient — they’ve got a sick kid and ten minutes. Hand them your build and watch them use it. Don’t explain anything. Don’t help. Did the tests pass? Is the patient satisfied? If those answers don’t match, which link in the chain would you go back to? ## Lesson reflection - Which translation in the Description Chain feels most natural? Which do you tend to rush through? - In your Clinic demo, where was the biggest gap between what you intended and what your partner experienced? ## What's next In the next lesson, we move from description to discernment. You’ve built something and the code runs — now the question is whether it’s actually good. ## Feedback As you progress through the course, we’d love to hear from you about how you are using concepts from the course in your work, plus any feedback you may have. Share your feedback here. ## Acknowledgments and license Copyright 2026 Anthropic. This course was developed in partnership with CodePath, building on the AI Fluency Framework developed by Prof. Rick Dakan (Ringling College of Art and Design) and Prof. Joseph Feller (University College Cork). Released under the CC BY-NC-SA 4.0 license. --- # Lección: Discernment for code (Discernment for builders) ## Discernment for code ## What you'll learn Estimated time: 30 minutes By the end of this lesson you'll be able to: - Evaluate AI-generated work across five lenses: correctness, quality, fit, experience, and responsibility - Raise your quality bar beyond "it works" by learning failure modes specific to AI-built products - Catch AI's predictable technical blind spots before they reach production ## Discernment for code (5 minutes) When AI can spin up a working product in minutes, “working” stops being the bar. You’ll learn where AI-built products typically fail, the technical blind spots that surface in production but not in development, and how to build the taste that AI doesn’t have. [VIDEO — transcripción] You've now built something with AI. It runs. The tests pass. But so what? Think about the project we've been building. Did it handle a scenario where a patient's estimated wait time suddenly jumps from 10 minutes to 90? Did it account and solve for different patient needs? Did it build in historical biases from the existing data? A working product and a good product are not always the same thing. And when AI can produce a working product in minutes, your ability to tell the difference becomes the most valuable skill in the room. This module gives you a structure for that judgment. Five lenses and five questions to ask of anything that AI builds. The first lens is functional integrity. Does it actually work? Bugs, errors, security holes. This is where most code review stops. It's necessary, but it's not close to sufficient. In our project example, AI built sound logic to display wait times, but did it account for patient priority? What about conflicting data points and determining which one to display? When building, consider the full gamut of functional tests: unit tests, integration tests, regression tests, edge cases, end-to-end. And here's a habit that matters. AI should be building tests alongside the code, not after it. When you prompt, ask it to write test cases in the very same pass, then build in regular checkpoints. A test suite that hasn't been run is not a safety net. It's just a false sense of security. The second lens is production readiness. Does it actually work well? Performance, scalability, reliability, what happens under load? What happens when hundreds of people try to refresh at the same time? AI has specific blind spots here. So how do you verify this in your building process? A few concrete moves: ask AI to stress test its own output, have it generate production scenarios, and check how the code handles them. Ask it explicitly, "What production assumptions does this code make?" You'll surface things that were missed in the first pass. In your project, did the code account for when the API call takes five seconds too long? Does the display freeze, show stale data, or fail gracefully? AI doesn't think about that. That's with you. The third lens is problem fit. Is it the right thing? Does it solve the user's actual problem? Or the problem the user thinks they have? Those can diverge, as you saw in the last lesson. The patient asked about wait times, and at face value AI can build an estimated wait time display, but what the patient really needed to know was if there was a pediatrician available in the next 20 minutes, so they could assess if their child's fever is critical or not. AI solved the stated problem, but you need to check whether that's the real problem. The fourth lens is experience quality. Is it actually good? Is the experience clear, intuitive, accessible? AI doesn't have taste, it has patterns. It will give you a competent interface that no one enjoys using. For a clinical wait time tool, that's not just an aesthetic problem, it's a patient safety issue. It's your job as the builder to notice this, and translate it into something concrete and fixable. We'll talk more about Experience Discernment in the next lesson. The fifth lens is responsible impact. Is it responsible? Bias? Privacy? Unintended consequences? Who could this harm? What does it assume about the user that might not be true? Let's look back at the clinical wait time tool. Is the algorithm estimating wait times trained on historical data. If that data reflects existing bias, systemic inequities contributing to longer wait times for certain demographics, the model may reproduce that same pattern. It won't flag it, it will just display a number. Build guardrails. Ask AI to name its bias as it builds. And most importantly, question all assumptions. Most engineering education stops at the first two lenses, but builders need all five. And here's what you'll find when you start applying them. The biggest problems are almost never at lens 1. AI is good at producing code that runs. It needs your oversight to produce a product that matters. One more thing, when you find something that isn't good enough, notice your own instinct. Do you reach in and fix it yourself, or do you go back and describe better what you needed? Neither is wrong, but the pattern tells you something about how you're working with AI, and whether you're building Discernment, or just building. Alright, it's time to apply these lenses. Let's go. The Five Lenses of Discernment Lens 1 is easy to test — run it and see. By Lens 5, you’re making judgment calls AI can’t make for you. Lens 1Functional Integrity Lens 2Production Readiness Lens 3Problem Fit Lens 4Experience Quality Lens 5Responsible Impact Lens 1 Functional Integrity Does it work? ✓Produces correct output for real inputs, not just test data Common AI failure Code that passes unit tests but breaks on real data the prompt never covered Lens 2 Production Readiness Does it work well? ✓Handles concurrent users without race conditions Common AI failure Smooth in dev, broken under load or behind a real infrastructure stack Lens 3 Problem Fit Is it the right thing? ✓Solves the user’s actual need, not just the literal spec you wrote Common AI failure Technically complete feature that addresses the prompt but misses the underlying need Lens 4 Experience Quality Is it good? ✓Users can complete the core task without help or instruction Common AI failure Generic UI patterns that technically work but feel uninvested — confused or frustrated users Lens 5 Responsible Impact Is it responsible? ✓Transparent about AI’s role — doesn’t present generated content as verified fact Common AI failure AI-generated content presented as authoritative, or a demographic left out by default ## Key takeaways - Code that runs can still fail. The default AI output is technically complete but often misses the point. - AI has predictable blind spots in concurrency, security, and anything that only breaks at scale. - Taste is a builder skill. AI delivers functional. Making it worth using is on you. ## Exercise ## User testing the Clinic project Put your build in front of a partner playing a patient or clinic admin — don’t explain, don’t help. Watch where they get confused, what they ignore, and what they wanted that you never built. Write down three things you’d change and which lens each falls under. ## Lesson reflection - Which of the five lenses do you naturally apply, and which do you have to remind yourself to check? - When AI produces something that isn’t good enough, what’s your instinct: fix it yourself, or describe it better? ## What's next You’ve stress-tested the Clinic Wait Time Checker through the lenses you tend to skip. Next, you’ll look at the same tool through a different lens: how does it actually feel to use? ## Feedback As you progress through the course, we'd love to hear from you about how you are using concepts from the course in your work, plus any feedback you may have. Share your feedback here. ## Acknowledgments and license Copyright 2026 Anthropic. This course was developed in partnership with CodePath, building on the AI Fluency Framework developed by Prof. Rick Dakan (Ringling College of Art and Design) and Prof. Joseph Feller (University College Cork). Released under the CC BY-NC-SA 4.0 license. --- # Lección: Discernment for user experience (Discernment for builders) ## What you'll learn Estimated time: 45 minutes By the end of this lesson you'll be able to: - Apply hierarchy, user flows, accessibility, and feedback patterns when specifying what AI should build - Critique AI-generated designs using feedback specific enough to act on - Make intentional tradeoff decisions between speed, polish, and user needs ## Discernment for user experience (2 minutes) As AI speeds up implementation, design becomes the differentiator. This lesson covers the UX principles that matter most when working with AI, why “make it look good” produces nothing useful, and how to close the gap between a critique you’d give a colleague and a description AI can execute. [VIDEO — transcripción] As implementation gets faster, design and user experience become even more important. You don't need to become a designer, but you do need to recognize good experience, spec for it, and iterate towards it. A few principles here to guide you. One is clarity. If users can't tell what your product does, or how to get started, they're gone. Clarity means unifying form and function while respecting people's mental models. Users arrive with expectations, shaped by other software and by the world. Keep it simple and map your interface to concepts they recognize. A patient checking wait times expects it to work like every other status checker. Two is hierarchy and progressive disclosure. Make it easy for people to scan and find the information that is needed. Don't overwhelm them. Use text size and weight to create good headers. Minify the amount of unneeded elements, and allow people to find the information they need as they need it instead of cramming it all into one space. Three, accessibility is a baseline, not a nice to have. Screen reader compatibility, color contrast, keyboard navigation, you should ask the AI for these explicitly every single time and build test cases to validate. Four, feedback and responsiveness. When the user does something, the interface should acknowledge it, not lead the user to question if something might be broken. Loading states, confirmations, and error messages that explain what to do next, all in simple human language, help build trust. The gap between making it look good and a good experience is enormous. Make it look good is a wish. Put the wait time in the largest text on the page, use a single color to indicate status, and make the refresh time visible so the patient knows how stale the number is, is an actionable, strong Description. This is Description and Discernment working together. You describe the experience precisely, AI builds it. You evaluate what comes back against what you intended. You describe the gap, repeat. One thing you'll notice in the exercises, the critique that you'd give a colleague and the description AI needs are not the same document. This feels cluttered is a fair critique, but it's useless instruction for AI. Part of design literacy is learning how to translate your own taste into something that is executable. Let's put it to work. UX Lab: Apply the four principles Each tab shows a food delivery screen with common UX problems AI generates by default. Hover over any element to discover what’s wrong — then click Show Fix to see how it should be built. Clarity Hierarchy Accessibility Feedback Principle 1 of 4 Clarity Every element should instantly communicate its purpose. Users shouldn’t have to guess what a button does or what a field means. Show Fix↻ Reset ←No destination label — users can’t tell where “back” goes AppGeneric title — what screen is this? ⋮Unexplained icon — what does this open? Burger12.00No currency symbol — is this dollars? Fries4.50 Total16.50 SubmitVague action — submit what? For how much? ← Back to menu Order review Help Burger$12.00 Fries$4.50 Order total$16.50 Place Order — $16.50 Principle 2 of 4 Hierarchy Visual weight should match information priority. The most important thing should look the most important. Show Fix↻ Reset Order total: $16.50Most critical info buried in a flat list — nothing stands out Arriving by 1:10 PMSame size as the order number — hard to find fast Order #1284 123 Main St, Apt 4B Subtotal $14.00 + Delivery $2.50 $16.50 Arriving by 1:10 PM Order #1284 · 123 Main St, Apt 4B Subtotal $14.00 + Delivery $2.50 Principle 3 of 4 Accessibility About 1 in 5 people has a disability — visual, cognitive, or neurological. AI generates for the median user. Small text, color-only signals, and jargon quietly exclude everyone else. Show Fix↻ Reset Order #1284 Color only — no text label. Colorblind users cannot tell if this means confirmed or failed. Item9px header text — unreadable for low vision users without screen magnification. qty“qty” is an abbreviation — creates friction for users with cognitive disabilities or limited literacy. Price Burger1$12.00 Fries1$4.50 Total$16.50 ETA: 35 min · Cancellation per T&C9px text. “ETA” and “T&C” are jargon — neurodivergent users often need plain language to process confidently. Order #1284 ✓ Order confirmed Item QuantityPrice Burger1$12.00 Fries1$4.50 Order total$16.50 Arrives in approximately 35 minutes · Free cancellation — see details Principle 4 of 4 Feedback When something breaks, users need to know what happened, what to do next, and how to get help. A raw error code answers none of those questions. Show Fix↻ Reset ← Order Review ⋮ ⚠ No explanation — users don’t know if their order went through, failed, or is still pending. Error 503“503 Service Unavailable” is a server code. It means nothing to a user trying to order lunch. ← Back Order Review Help ✕ We couldn’t place your order Our payment system hit a snag. Your cart is saved — try again in a moment. Try again → Still having trouble? Chat with support → ## Key takeaways - When implementation is fast, experience is the differentiator. Design literacy is a core builder skill. - “Make it look good” is a wish, not a spec. Describe experience with the same precision as a function. - AI does not get accessibility right by default. Specify it, then audit what you get back. - A good critique and an actionable AI description are different artifacts. Learn to translate between them. ## Exercise ## The Clinic Wait Time Project, Part 3 Write a design spec for your clinic app — user flows, information hierarchy, interaction patterns — then rebuild it with AI against that spec. Critique the result: where did AI nail it, and where is it technically correct but experientially flat? Run a quick accessibility audit and document what AI missed. - Clarity & Mental Model — Does the output use language and patterns a clinic admin would recognize? - Information Hierarchy — Is the most important information the first thing users see? - Accessibility — Does it pass color contrast, screen reader, and keyboard navigation checks? - Feedback & Error Handling — Does the interface acknowledge user actions and explain what to do when something goes wrong? ## Lesson reflection - How much of your design spec describes what the interface does versus how it should feel to use? - After running the accessibility check, did you build with accessibility in mind from the start, or add it at the end? ## What's next You’ve looked at your Clinic Wait Time Checker through both a code lens and a UX lens. In the next lesson, you’ll tackle the hardest question: what does it mean to actually stand behind what you build? ## Feedback As you progress through the course, we'd love to hear from you about how you are using concepts from the course in your work, plus any feedback you may have. Share your feedback here. ## Acknowledgments and license Copyright 2026 Anthropic. This course was developed in partnership with CodePath, building on the AI Fluency Framework developed by Prof. Rick Dakan (Ringling College of Art and Design) and Prof. Joseph Feller (University College Cork). Released under the CC BY-NC-SA 4.0 license. --- # Lección: Stand behind what you build (Tying it all together) ## Stand behind what you build ## What you'll learn Estimated time: 45 minutes By the end of this lesson you'll be able to: - Articulate what you own when you ship something AI helped build - Identify the technical realities that surface at ship time and build feedback loops that catch them - Make the call: ship it, fix it, or stop it ## Diligence & sharing your work (3 minutes) Diligence in the builder model is full ownership: you’re responsible for the product from whether it should exist to whether it’s serving users after launch. This lesson covers what it means to ship, the technical realities AI won’t warn you about, why tests become your safety net the moment something is live, and the underrated skill of deprecating your own work. [VIDEO — transcripción] Hi there, my name is Martina, and I'm an engineer at Anthropic. Throughout this course, you've delegated, described, and discerned. You have a clinic app that works. It's almost time to ship it. In the 4D Framework, Diligence means taking responsibility for what you build with AI. Essentially, making sure your use of AI is transparent, ethical, and accountable. This includes being transparent about your AI use and disclosing it, taking ownership of the outputs that AI creates, verifying work before you ship, considering the impact of what you built on others, and honoring policies, privacy, and professional standards that govern AI use in your organization or industry. Rather than tell you what to value, I'm going to show you what Diligence looks like in my day-to-day as an engineer. With AI, you can end up being the owner of code you didn't write. Diligence is how you catch up to your own code. Understand it, stress it, test it, and put the systems in place that catch what you miss. For me, that comes down to three habits. When you're writing code yourself, it becomes apparent as you go that there are things you hadn't thought of. Some edge case, some decision you hadn't realized needed to be made. With AI, sometimes those end up getting decided without ever being surfaced to you. So I try to recreate that step on purpose, get those questions out in the open where I can actually weigh in. When an edge case pops into my head, I'll just say to the model, like, "Can you double check that users can't view other users' files?" After Claude builds something substantial, I ask directly, "What assumptions and trade-offs did you make?" What security risks should I be aware of? That ensures that you're looped in on the important decisions. When Claude writes most of a pull request, I make sure to say so in the Description, not as a disclaimer, as information. This is relevant because AI makes a different shape of mistake than humans do. Deprecated APIs used confidently, code that's locally clean but inconsistent with the codebase, invented behavior for cases you never specified. A reviewer who knows that can better tailor their review. It's easy to feel out of your depth when AI does the building. You can end up with working code you don't understand, which wasn't really possible before. But it's not that you can't understand it, it's just a separate step now, and AI can help with that too. Claude is more than happy to sit with you and patiently explain. It takes a bit of time, but that's what puts you back in the loop. Here's the thing, the engineering best practices that existed before AI still apply after, maybe even more so, because now you're shipping faster, and you understand a smaller fraction of what you shipped. Tests are still the easiest way to make sure you don't break something while moving this fast. A solid test suite pins down the behavior you care about, so you can keep iterating without fear. Observability hasn't gone anywhere either. Some things only show up when real users have it: so you want logs, error tracking, dashboards. You find out from your own data, not from a user email. And feature flags remain useful for when something does slip through. Having these safety nets in place is what lets you move fast safely. Verification, transparency, understanding. Tests on one end, observability on the other. None of this is new to engineering. AI is just a new tool under your belt to get there. ## Key takeaways - You own the outcome, not the output. “AI wrote it” explains nothing and excuses nothing. - Shipping has its own technical vocabulary (migrations, versioning, rate limits, feature flags) that AI will not surface unless you ask. - Tests make post-launch iteration safe. The test-first habit is why you can keep changing things confidently. - Prototype freely, ship selectively. Cheap code creates value only when paired with honest evaluation. - Access is a design decision. Check who your assumptions exclude before you call something shipped. ## Exercise ## Ship the Clinic app Shipping is where diligence becomes real — before you deploy, answer each of these honestly. Once you’ve worked through these, deploy your app or host it as a prototype, share it with three real users, and make one iteration based on what you learn, with tests that verify the change. - Understanding — Can you explain what your code does, not just what it should do? - Testing — Do your acceptance tests still pass? Have you tested edge cases — closed clinic, missing data, zero wait time? - Access — Who does your build not serve well? - Responsibility — Could this output be misread or misused? Have you been transparent about AI’s role? - Feedback loop — How will you know if it’s working after it ships? ## Lesson reflection - How has your thinking about AI integration changed from the beginning of this course? - What’s one thing you’ll do differently in your work with AI based on what you’ve learned? ## What's next You’ve built, evaluated, and shipped the Clinic Wait Time Checker. In the final lesson, you’ll bring the full 4D Framework together and leave with a real task already in motion. ## Feedback As you progress through the course, we’d love to hear from you about how you are using concepts from the course in your work, plus any feedback you may have. Share your feedback here. ## Acknowledgments and license Copyright 2026 Anthropic. This course was developed in partnership with CodePath, building on the AI Fluency Framework developed by Prof. Rick Dakan (Ringling College of Art and Design) and Prof. Joseph Feller (University College Cork). Released under the CC BY-NC-SA 4.0 license. --- # Lección: Closure & looking forward (Wrapping up) ## Closure & looking forward ## What you'll learn Estimated time: 15 minutes By the end of this lesson you'll be able to: - Find resources to continue building your AI fluency after this course - Share what you learned with colleagues who could benefit from the 4D Framework - Collect your certificate of completion ## Looking forward (4 minutes) This closing video brings together everything you've learned across the course and challenges you to put it into practice immediately with real work that's already waiting for you. [VIDEO — transcripción] Kristen again from the education team at Anthropic. And I'm Chris, the chief product officer at CodePath. You've made it to the final lesson. Now let's talk about what happens next, the ways you can put AI Fluency to work when you build. You have real work waiting for you. Maybe it's a feature that users have been requesting for three months. Maybe it's a prototype you've been meaning to turn into something real. Or maybe it's that pile of user feedback sitting in a spreadsheet that you haven't had time to synthesize. So here's your final assignment. Pick one of those things and use what you've learned in this course to tackle it with AI support this week. Start with Delegation. Before you even open your laptop, think about what's actually in front of you. Break the problem down. What parts of this work genuinely benefit from AI? Implementation, scaffolding, boilerplate, first drafts of specs, these are strong candidates. But what parts need you? The judgment calls, the understanding of who your user actually is, and what they might be struggling with. The decision about whether the thing you built is actually the right thing. Those belong to you. Remember the builder's toolkit. You have six instruments. Empathy, design, architecture, implementation, judgment, and shipping. AI is strongest in the middle at implementation in parts of architecture. It's weakest at the edges. It can't feel what your user feels. It can't tell whether what you shipped actually made a difference. That's your job. Once you've made your Delegation decisions, move into Description. This includes so much more than just what to code. It includes everything from user voice to product requirement to technical spec to AI instruction to tests. So before you write a single prompt, be clear about what problem you're solving and for whom. What does done look like? What would a test for success actually measure? When you give AI a well-described task with clear acceptance criteria, you're treating it like a capable junior collaborator with a clear brief. And of course, as you work, apply Discernment. Does it work? Does it work well? Is it the right thing? Is it good? Is it responsible? Sometimes AI builds the thing you describe, but not the thing that solves the problem. Or it builds the thing that works, but one that people don't want to use. Find that out. Finally, practice Diligence. Prototype freely. That's how you learn. But ship selectively. Before anything goes to users, ask, "Do I understand what this does?" Can I explain it? And is there a way to know if it's working? And of course, be willing to veto something you built when the evidence says it isn't working. Sunk effort is one of the hardest things to walk away from. But the builder's job isn't to defend the software. It's to serve the user. The 4Ds are dynamic. You'll move from Delegation to Description, back to Discernment, and realize you want to delegate differently. That's your AI fluency developing through practice. In the resources section below, you'll find blueprints covering common builder tasks, from writing technical specs to structuring a build measure learn cycle with AI assistance. Use these as your starting points, adapt them to your needs, and then reflect on what you learned. You can also take a short quiz to earn your certificate of completion. Now that's something worth sharing with your other builders in your network to start a conversation about what this kind of fluency looks like on a team. Congratulations on completing this course. The builders who will do the most interesting things with AI in the next few years aren't the ones who automate the most. It's the ones who know when to delegate, and when to stay in the loop. These are the ones who care enough about their users to not just ship something because it compiles. That's who you are. Now go build something great. ## Key takeaways - AI is strongest in the middle of the toolkit. Delegate implementation freely. Keep empathy, judgment, and shipping in your hands. - Robust description means following the full chain: user voice to requirement to spec to AI instruction to tests. A failure at any link cascades downstream. - Prototype freely, ship selectively. Be willing to veto something you built when the evidence says it is not working. - Apply discernment before shipping. AI output often passes “Does it work?” but stumbles on “Is it the right thing?” Those gaps are where your judgment matters most. - The 4Ds are dynamic, not a sequence. Moving fluidly between them as you build is what fluency looks like in practice. ## Exercise ## Your next build Before completing this course, choose one real task from your current work to tackle with AI support this week. Pick something concrete and already waiting — not a hypothetical. Good candidates: - A feature request you've been putting off - User research or feedback that hasn't been synthesized - A technical spec that needs to be written before work can begin - A part of your codebase with no tests that makes you nervous to touch Work through it using all four competencies: - Delegation — Which stages are safe to delegate? Which require your judgment? - Description — Write the full chain: user need → requirement → spec → AI instruction → tests. - Discernment — Evaluate output through all five lenses. - Diligence — Before shipping: Do I understand what this does? Is there a feedback loop? Would I stand behind it? ## Lesson reflection - What task are you committing to this week — and which part of the 4D Framework will matter most? - What did you believe about working with AI at the start of this course that you now see differently? - Who on your team would benefit from the 4D Framework? ## What's next Next, take the short assessment to earn your certificate of completion. ## Feedback As you progress through the course, we’d love to hear from you about how you are using concepts from the course in your work, plus any feedback you may have. Share your feedback here. ## Acknowledgments and license Copyright 2026 Anthropic. This course was developed in partnership with CodePath, building on the AI Fluency Framework developed by Prof. Rick Dakan (Ringling College of Art and Design) and Prof. Joseph Feller (University College Cork). Released under the CC BY-NC-SA 4.0 license. --- # Lección: Course quiz (Wrapping up) ## Course quiz Este quiz aún no lo has presentado en Skilljar. Las preguntas solo se muestran al iniciarlo en la plataforma (cuenta como intento oficial), por eso no está guardado aquí.