AI

2026-11-06 · open the original ↗

• A next-word predictor can be built just by counting word pairs. The interactive piece starts from the phone game of writing a text using only suggested words, then "trains" on five messages by tallying which word follows which, producing a transition matrix whose normalized rows are probability distributions over the next word.
• Sampling strategies formalize the gut feel of picking a word. Always taking the top word maps to temperature → 0 or top-k with k = 1; sampling faithfully is temperature = 1; boosting likely words is temperature < 1; top-k keeps the N best; top-p keeps the smallest set summing to a threshold and, unlike top-k, adapts to how confident the model is.
• LLMs sample the same way but compute the distribution differently. A Markov chain reads one row of a table keyed on the last word; an LLM runs a forward pass over the whole conversation through billions of parameters, giving up the table's explainability for far more context and capability.
• The technique is over a century old. Markov published the idea in 1906; n-gram models drove phone prediction around 2010 (SwiftKey, then Apple's QuickType); RNNs from around 2015 and transformers in 2017 replaced table lookup with a learned function.

2026-11-06 · open the original ↗

• Generative AI composes answers; it does not look them up. David of Anthropic's safety team calls it closer to "an extraordinarily sophisticated autocomplete than a search engine," so a citation-shaped string satisfies the pattern just as well as a citation to a paper that actually exists.
• How well-worn the path is decides how reliable the output is. Summarizing a well-known essay lands cleanly because the model has seen the task thousands of times; asked for three papers with publication years by a mid-level researcher in a niche subfield, it answers in the same confident tone while some results may be fabricated.
• Fluency and hallucination are the same property. Listed strengths are fluent text in any register, synthesis across fields and coherent continuation; failures are hallucination, confabulation (filling gaps instead of flagging them), inconsistency from sampling, and misplaced confidence.
• Fabrication concentrates in specifics, and tone says nothing about accuracy. Names, dates, statistics, citations, quotes and URLs need checking, more so when stakes are high or the domain is unfamiliar; "smoothness and correctness are independent variables."
• Product features exist because the underlying behavior is always generative. Citations and source grounding, trained uncertainty signaling, constrained generation and skills, and generator-verifier loops are presented as ways to push the limit out; the lesson ties this property mainly to Discernment, and secondarily to Delegation.

2026-11-06 · open the original ↗

• Pretraining alone produces a document completer, not an assistant. Maggie, who leads Anthropic's education team, says a pretrained-only model asked "What is the capital of France?" may just continue the pattern ("Paris. What's the capital of Germany? Berlin…") because it has seen quizzes, and has no concept of helping anyone.
• Fine-tuning layers trained assistant behavior on top. Curated examples and reward signals from human preferences teach the model to treat input as a request, answer instead of rambling, and decline harmful asks; politeness and caution are presented as trained results, not emergent ones.
• Human-preference training leaves four predictable shadow traits. These are sycophancy (validating and backing down under light pushback), verbosity (thoroughness scored well), over-caution (conservative safety training refusing safe requests) and loose confidence calibration, which she singles out as genuinely hard to train.
• These traits appear in all models but vary with fine-tuning. She says how they show up depends on each lab's fine-tuning, and points to Claude's published constitution as Anthropic's account of how it shapes Claude's personality.
• Naming the trait tells you how to read the output. A model that caves when you push back is showing sycophancy, essays where you wanted bullets are verbosity, and heavy caveats on a harmless question are over-caution; the exercise tests each by priming a wrong assumption or asking for a one-sentence answer.

2026-11-06 · open the original ↗

• Most AI isn't generative; this course covers only the kind that is. Spam filters, recommendation engines, fraud models and call routing sort, rank and classify existing content; generative AI produces new text, images, code, audio or video, and is built by pre-training on large data followed by fine-tuning for safety and helpfulness.
• AI's strengths and weaknesses come from the same mechanism. The lesson argues a model writes compellingly and hallucinates for the same reason, being a prediction engine; the mechanism doesn't change, only where a given task lands between the capability and limitation zones.
• Four properties each answer one question about the machine. Next token prediction: where answers come from, since without an external source the model writes rather than looks up. Knowledge: what it knows, broad but uneven and frozen at a cutoff. Working memory: what it attends to, which is only what's in the context window. Steerability: how much control you have, with a gap between intent and result.
• The goal is calibrated trust, not distrust or full delegation. Learners are to ask where a task sits on each continuum, whether it's well-trodden or near an edge, and what the stakes are if the output is wrong.

2026-11-06 · open the original ↗

• This course is the machine-side companion to the 4D Framework. Kristen of Anthropic's education team presents Delegation, Description, Discernment and Diligence as human competencies, and this course as an explanation of the machine properties they respond to; you can't delegate without knowing where the model is weak, or judge output without knowing how it was produced.
• Generative AI has four core properties, each a continuum. The properties are next token prediction, knowledge, working memory and steerability; for each, the learner is taught to judge whether a task sits in the capability zone or drifts toward the edge, after first covering the two training stages (pre-training, fine-tuning) that give a model its character.
• Most real-world failures are two properties meeting. Her examples: a hallucinated citation is next token prediction meeting a knowledge gap, and drift over a long conversation is working memory meeting steerability; naming the combination tells you the cause and the fix.
• The mental model is meant to outlast model releases. Context windows grow and hallucination rates drop, but the course argues the properties themselves stay put: there will still be a knowledge cutoff and the context window will still have an edge, even as the boundaries move.
• The exercises only work on your own expert domain. Learners are told to bring real tasks, listing 4–6 things they used AI for in the past two weeks, because they need to be able to tell when an output is off; that list is reused in every later lesson.

2026-11-06 · open the original ↗

• Hooks run every time; instructions in a prompt only usually do. The lesson's example is a CLAUDE.md line telling Claude to run Prettier after each edit, which it follows most of the time, against a hook that fires without exception. Listed uses are auto-formatting after edits, logging every command for compliance, blocking dangerous operations and notifying you when Claude finishes.
• A hook pairs a lifecycle event, an optional matcher and a command. Hooks are configured by editing settings.json directly; /hooks only shows a read-only list to confirm a new one registered. Common events named are PreToolUse, PostToolUse, UserPromptSubmit, Stop and Notification, with more in the hooks reference; the standard example is a PostToolUse hook matching "Edit|Write" that runs the formatter for the file's extension (Prettier for TypeScript, gofmt for Go).
• Pre-tool hooks can veto an action, and the exit code decides. A PreToolUse hook gets the tool name and input as JSON on stdin: exit 0 proceeds, exit 2 blocks and feeds stderr back to Claude so it can adjust, and any other code is a non-blocking error shown only to you. This is presented as the way to guarantee rules such as no writes to a production config directory, no rm -rf, no commits to main.
• Project-level hooks travel with the repo to the whole team. Hooks in .claude/settings.json can be checked in so everyone gets them automatically. Commands should reference project scripts through the CLAUDE_PROJECT_DIR environment variable so they work whatever Claude's current working directory is.

2026-11-06 · open the original ↗

• MCP brings in context that lives outside your codebase. Model Context Protocol is an open standard that gives Claude Code tools — the ability to take actions rather than just return text — against databases, productivity apps and public repositories. Examples given are a Linear server for issue details and Context7 for up-to-date dependency docs.
• Servers are either remote over HTTP or local over stdio. HTTP servers are hosted by the provider; stdio servers are processes on your machine. Both are added with claude mcp add, and /mcp inside a session shows what is connected, its status, and lets you disable servers.
• Scope decides who gets a server. Local is this project for you only, user is all your projects, and project uses a .mcp.json checked into version control so everyone on the codebase gets identical servers.
• Every connected server costs context, even when unused. Each adds its tool names and instructions to the window, so the advice is to disable idle ones; tool search, on by default, keeps full tool definitions out until Claude needs them. Where a CLI equivalent exists (gh, aws), the lesson calls it more context-efficient because it adds no per-tool listing.
• Pairing a server with a skill teaches Claude to use it well. A skill puts only its name and description in context and loads the full contents when Claude decides it is needed.

2026-11-06 · open the original ↗

• Skills replace instructions you keep repeating to Claude. A skill is a markdown file — more broadly a folder of instructions, scripts and resources — that teaches Claude a task once, such as your coding standards, PR feedback structure or commit message format. The lesson's test: if you keep explaining the same thing, that is a skill waiting to be written.
• The description is what makes a skill fire. Claude compares each request against the descriptions of all available skills in their SKILL.md files and activates those that match, so a "review this PR" request finds a PR-review skill.
• Where a skill is stored decides who gets it. Personal skills in ~/.claude/skills follow you across projects and hold your own preferences; project skills in the repo's .claude/skills come with every clone and hold team standards such as brand guidelines, fonts and colors.
• Skills load on demand; CLAUDE.md loads into every conversation. Only a skill's name and description sit in context until it matches, so a PR checklist stays out while you debug. Always-on rules, such as TypeScript strict mode, belong in CLAUDE.md instead.
• Skills apply automatically, where slash commands must be typed. The lesson positions them for specialized, task-specific knowledge Claude should pick up when it recognizes the situation.

2026-11-06 · open the original ↗

• Subagents keep exploration work out of your main context. Each runs in its own window with two inputs — a custom system prompt from its configuration and a task description written by the parent — and its file reads, edits and tool calls never reach the main conversation. Only a summary returns, and the subagent's conversation is then discarded entirely.
• You get the answer without the journey, but lose the journey. The example is finding which service handles refunds in an unfamiliar payment system: unaided, Claude might read 15 files and trace several calls to learn one fact. The trade-off the lesson names is that the main window no longer sees how the subagent reached its conclusion or what else it found.
• Built-in subagents cover common exploration and planning work. The general-purpose subagent handles multi-step tasks needing exploration and action, explore does fast codebase search, and plan does research and analysis during plan mode.
• Custom subagents are Markdown files Claude can write for you. They use YAML frontmatter, and the easiest route is describing one, e.g. a read-only code reviewer in .claude/agents/; Claude generates the name, description and prompt, and the description governs when it gets called. .claude/agents/ is per-project, ~/.claude/agents/ is global, and a folder created mid-session needs a Claude Code restart.
• Subagents can keep memory and carry preloaded skills. Persistent memory lets one retain knowledge across conversations on the same projects. Skills listed under the skills key are loaded in full, unlike in the main conversation, where only their name and description load.

2026-11-06 · open the original ↗

• Without CLAUDE.md, every session rediscovers your project from scratch. Claude re-explores the codebase, dependencies and existing features, and its assumptions make it harder to steer. A CLAUDE.md in the project root is read automatically each session and appended to your prompt — the lesson calls it an onboarding script for the codebase.
• A useful file states the stack, the commands and the conventions. The example names a Next.js 15 App Router app with Tailwind and Drizzle, pnpm dev/test/lint, and rules such as 2-space indentation, named exports and server actions over API routes. With that, a request for a React component already follows those conventions.
• Project-level files are shared; user-level files are personal. The project CLAUDE.md lives in the repo root and should be committed so the team benefits; the user-level one lives in your configuration folder and applies across all your projects.
• Turn repeated corrections into saved rules. If you keep correcting Claude, ask it explicitly to save the rule to memory so the next session knows it. Project docs can be pulled in by reference with @ and a path, e.g. @README.md.
• Start without a CLAUDE.md so it captures only real corrections. The recommendation is to work first, note where you constantly course-correct, and keep the file compact; /init then has Claude generate one.

2026-11-06 · open the original ↗

• The session that wrote a change is not its best judge. The lesson advises reading every change yourself, then having Claude review it from a clean context. /diff opens an interactive viewer of uncommitted changes, including per-turn changes; it and /code-review require git, though on other version control you can still review in your own tool, ask for a review in plain words, and use /rewind.
• A true summary can still leave out changes that matter. The three things to check every time are unrequested changes, weakened tests, and new packages or hard-coded values. In the signup-form exercise, Claude's accurate summary covered eight changed files that hid a skipped test and a loosened assertion (the real reason "all tests pass"), a new package for one email check, and an edit redirecting signups to localhost; /rewind (or Esc twice) restores code and conversation but not files changed by shell commands such as package installs.
• A clean-context reviewer lacks the session's accumulated bias. /code-review runs in the background for seconds to minutes, counts against usage, and edits nothing unless asked. low effort reports only high-confidence findings, high casts a wider net, and the chosen level persists until changed.
• Sort every finding into fix now, ask why, or leave it. Reviewers reading cold can be wrong — the exercise's "doesn't trim spaces" finding missed a trim() on line 4, so you quote it back and ask Claude to recheck. Every fix request should demand evidence, such as running the tests and showing output; small style findings get batched for later, and a fix that grows large gets reviewed again.
• Full human-plus-Claude review is for big, sensitive or handed-off changes. A one-line change needs a glance at the diff; review in depth when a change exceeds what you can hold in your head, touches something sensitive or destructive, or is going to a teammate. An issue flagged repeatedly is a candidate for a CLAUDE.md rule.

2026-11-06 · open the original ↗

• Everything in a session draws on one finite context window. Prompts, file reads, tool calls and their results all take space; near the limit Claude Code auto-compacts, summarizing key details and dropping tool results, which can lose detail. /context shows total size, the largest categories and a visual breakdown.
• Compact to keep going on a feature; clear to start another. /compact summarizes everything so far while keeping a memory of the work; /clear wipes it so a previous conversation doesn't bias something new. Anything that must survive across sessions belongs in CLAUDE.md.
• Vague prompts end up costing more context than specific ones. A short, unclear prompt forces Claude to explore the codebase and reason on its own, which consumes far more space than a detailed prompt would.
• Unrelated MCP servers still occupy context. Each connected server loads its tool names and instructions, with full tool details only on use, so servers unrelated to the current project are worth turning off.
• Delegate answer-only tasks to subagents. A subagent has a separate context window and returns just a summary, so a question like "where are the authentication endpoints?" doesn't fill your main context with the search.

2026-11-06 · open the original ↗

• Skipping straight to code buys more course-correction later. The lesson calls explore → plan → code → commit the single thing to take from the course, because most people otherwise ask for code first.
• Plan mode is the cheapest place to course-correct. Entered with Shift+Tab, it lets Claude read files and run shell commands but not edit, then present a plan you can approve or ask to revise in specific areas — before any code exists. The example prompt asks where WebP conversion fits in an image upload pipeline and whether it needs new dependencies; the explore subagent alone suffices for a codebase summary with no changes planned.
• Coding goes smoother with success criteria, tools and a trustworthy test suite. Claude needs an explicit definition of "correct" in the plan, tools such as the Claude in Chrome extension to test web UIs directly, and tests to validate against — checked first so they don't yield false positives. Permission mode governs how execution proceeds, and recurring problems should be saved to CLAUDE.md.
• Get a fresh subagent review before committing. After testing the changes yourself, a code-reviewer subagent looks at the work without the bias the main agent built up during the session; then have Claude write the commit message in your style.

2026-11-06 · open the original ↗

• Permission mode sets how much oversight you keep. Shift+Tab cycles modes: manual asks before every edit or command; auto-accept approves file edits and common filesystem commands (mkdir, mv, rm) but asks for others; auto runs without routine prompts while a background safety check screens most actions. The lesson says there is no right choice, only your comfort level.
• Plan mode researches and asks questions before touching your source. It reads files and runs shell commands without editing source files, asks clarifying questions, and returns a detailed plan it can execute; the lesson recommends it for complex multi-step changes and safe code review. The worked example is a plan-mode prompt for an app-wide dark mode with a header toggle and a contrast color matched to the existing light theme.
• Descriptive prompts get better results. The recap's advice is to be as detailed as possible about what you want, then let plan mode dig into the details before any code is executed.

2026-11-06 · open the original ↗

• One command installs it; package-manager installs don't auto-update. On macOS, Linux or WSL a single curl command installs it; on Windows, Invoke-RestMethod in PowerShell or curl in CMD. Homebrew and winget also work but don't auto-update by default; first run asks for a theme and sign-in via a Pro, Max, Ultra, Team or Enterprise account, or an API key.
• Claude Code can reach whatever directory you launch it in. Running claude grants access to that directory and all its subfolders, so you start it from the project root.
• The IDE, desktop and web versions mirror the terminal experience. VS Code uses the Anthropic-published extension (opened via "Claude Code Open in New Tab"), JetBrains a marketplace plugin giving a terminal pane beside the editor, and Claude Desktop a "Code" tab with folder, permission and cloud-environment options. The web version at claude.ai/code works like desktop but only with GitHub repositories.
• Choose by need, knowing features ship to the terminal first. The lesson recommends the terminal for the newest features, IDEs for tighter editor integration, desktop for leaving Claude running in the background, and web for remote work on GitHub repos.

2026-11-06 · open the original ↗

• Claude Code works in a loop: gather context, act, verify, repeat. After your prompt it gathers context, takes an action such as an edit or command, and checks whether the result achieves the goal, looping until it does. You can add context, interrupt or steer at any point.
• Tools are what separate it from text-in, text-out assistants. File reading, web search and other tools let it execute steps toward a task, and it uses semantic understanding to decide when to call one and how to use the output.
• A finite context window is managed by automatic compaction. The window holds conversation, file contents and command output; at the limit Claude Code decides what to remove or summarize to get back to a usable size.
• Permission modes trade oversight for speed, and skipping them is risky. Manual asks before edits and shell commands, auto-accept passes edits and common filesystem commands, plan mode explores without editing, and auto mode uses a background classifier aimed at irreversible, destructive or out-of-environment actions. The starting mode depends on version and settings, and the lesson warns that free rein makes mistakes harder to catch.

2026-11-06 · open the original ↗

• Claude Code does the work directly instead of trading pasted snippets. Unlike Claude.ai, it has access to your files, terminal and whole codebase, so it can explain features and trace bugs, refactor across every referencing file, run builds, tests and installs and act on their output, and search the web for docs. It runs in the terminal, VS Code, JetBrains IDEs, Claude Desktop and the web.
• It is an agent: a language model acting in a loop. The lesson defines an agent as software that interacts with its environment to reach a defined goal, optionally using tools, external services or other agents.
• Limited working memory means it searches rather than loading everything. The context window holds a lot but not a whole codebase, so Claude finds strategic ways to locate answers.
• You choose how hands-on its permissions are. It can ask before commands or changes, or run in auto mode with a background safety check screening most actions instead.
• It makes mistakes, so stay in the loop. The lesson names misreading intent, introducing bugs and over-engineering as failure modes that close attention catches early.

2026-11-06 · open the original ↗

• Horizontal scaling breaks MCP's dual-connection model. A client holds a GET SSE connection for server-to-client requests and sends tool calls as POSTs; behind a load balancer these can land on different server instances, so a tool that needs sampling forces the POST-handling server to coordinate with whichever server holds the client's SSE stream.
• stateless_http=True removes that coordination at a steep functional cost. With it, clients get no session IDs and the GET SSE pathway disappears, so there is no sampling, no progress reports and no resource subscriptions; the only gain is that clients can skip the initialization handshake and send requests directly.
• json_response=True only turns off streaming of POST responses. The client gets the final tool result as plain JSON, with no intermediate progress messages or log statements during execution.
• Choose the flags by what your tools need, not by default. The lesson recommends stateless HTTP when you need load-balanced scaling and your tools need no server-to-client calls or sampling, and JSON response when you don't need streaming or are integrating with systems that expect plain JSON.
• Develop on the transport you will deploy with. The lesson says stateful and stateless modes can behave very differently, so a server built against stdio locally should be tested over HTTP before it ships. It also notes that the 2026-07-28 MCP spec revision drops session IDs entirely, while version 1 of the Python SDK used here still behaves as described.

2026-11-06 · open the original ↗

• StreamableHTTP uses Server-Sent Events to let servers reach clients. Sampling, notifications and logging all need the server to start requests, which plain HTTP doesn't allow; after initialization the client opens a GET request whose SSE response can be held open indefinitely, giving the server a channel to push messages at any time.
• A session ID from the handshake must accompany every later request. The server returns an mcp-session-id header in its Initialize Result, the client echoes it in the Initialized Notification, and it identifies the client on all subsequent calls, including the SSE GET and tool-call POSTs.
• Each tool call opens a second, short-lived SSE stream. The primary SSE connection stays open for server-initiated requests, while a tool-specific one is created per call and closes when the result is sent. Progress notifications travel over the primary stream; log messages and the tool result travel over the tool-specific one.
• stateless_http and json_response can break the SSE workaround. Setting either to true trades away the MCP functionality that depends on server-to-client communication. The lesson notes the 2026-07-28 spec revision drops the handshake and session ID, though version 1 of the Python SDK still works this way.

2026-11-06 · open the original ↗

• StreamableHTTP makes remotely hosted, public MCP servers possible. Unlike stdio, which needs client and server on the same machine, it carries MCP over HTTP so anyone can connect to a server elsewhere.
• Restrictive transport settings explain most stdio-works, HTTP-breaks failures. stateless_http and json_response both default to false, but some deployments force them to true, which can disable progress notifications, logging and server-initiated requests.
• HTTP cannot easily carry server-initiated messages to clients. Clients have no known URL, so servers can answer requests but not start them. That puts Create Message and List Roots requests, and progress, logging, initialized and cancelled notifications, among the message types plain HTTP handles badly.
• Forcing the restrictive flags means living inside HTTP's limits. The transport normally works around those limits, but with the flags on it doesn't; the lesson advises reconsidering the transport or using other communication patterns if a server depends heavily on server-initiated requests or real-time notifications. It describes the pre-2026-07-28 spec, which version 1 of the Python SDK still follows.

2026-11-06 · open the original ↗

• The stdio transport runs the server as the client's subprocess. The client writes to the server's stdin and the server writes to stdout; it only works with both on the same machine. Because a server run with uv run server.py just reads stdin, you can paste JSON messages into a terminal to test it without writing a client.
• Every connection opens with a fixed initialization handshake. In three messages, the client sends an Initialize Request, the server answers with an Initialize Result carrying its capabilities, and the client sends an Initialized Notification that gets no reply; only then can tool calls or prompt listings follow. The lesson notes the 2026-07-28 spec revision drops this handshake, but version 1 of the Python SDK still uses it.
• Stdio is the baseline where every communication pattern is easy. Of the four patterns, client requests and client responses go over stdin, server responses and server-initiated requests over stdout, so either side can start a message at any time. The lesson presents this as the ideal case against which HTTP's limits on server-initiated requests will be measured, good for development but not for client and server on different machines.

2026-11-06 · open the original ↗

• The MCP specification repository, not the SDKs, defines the messages. It lives at github.com/modelcontextprotocol/modelcontextprotocol, separate from the Python and TypeScript SDK repos; its message types are written in TypeScript only because that is a clear way to describe data structures, not because the code runs.
• Messages are either paired request-results or one-way notifications. Examples of pairs are Call Tool, List Prompts, Read Resource and Initialize request/result; notifications such as Progress, Logging Message, Tool List Changed and Resource Updated expect no response.
• MCP is bidirectional, and that is what constrains transport choice. The spec groups messages by sender, and servers send their own requests and notifications to clients; some transports, such as streamable HTTP, limit which messages can flow which way.

2026-11-06 · open the original ↗

• The user, not the server, should choose which paths are accessible. The example client takes paths as CLI arguments and converts each into a Root object whose URI begins with file://, as the spec requires.
• The server pulls roots from the client when it needs them. The client registers a callback on its ClientSession that returns a ListRootsResult; the server calling ctx.session.list_roots() sends a request back to the client that runs it.
• Roots serve both access checks and helping Claude resolve paths. For the second use, such as finding where "todos.txt" lives, the walkthrough suggests either a tool that lists the roots or injecting them into a prompt.
• The SDK does not enforce roots; your tools must. The walkthrough recommends a function such as is_path_allowed that compares a requested path against the roots, called in every tool that touches files.

2026-11-06 · open the original ↗

• Roots give Claude the context to find files from bare filenames. Asked to "convert biking.mp4 to mov format", Claude can't search the whole filesystem; with roots it calls list_roots, then read_dir on those directories to locate the file, then the conversion tool with the full path, so users never have to type full paths.
• Roots also bound what a server may touch. Granting only the Desktop keeps the server out of Documents or Downloads; access outside the roots returns an error Claude can relay to the user.
• Enforcing roots is the server author's job, not the SDK's. The lesson's pattern is an is_path_allowed() helper that checks a requested path against the approved roots, called in every file-accessing tool before the operation. It notes that the 2026-07-28 spec revision deprecates roots, though they still work in version 1 of the Python SDK.

2026-11-06 · open the original ↗

• Server tools emit logs and progress through the injected Context. Tool functions receive Context as their last argument and call info(), warning(), debug() or error() to log and report_progress() to estimate remaining work.
• Clients register logging and progress callbacks in different places. The logging callback goes to ClientSession and the progress callback to each call_tool() call; both should display what they receive to the user.

2026-11-06 · open the original ↗

• Log and progress notifications tell users a slow tool hasn't stalled. Without them a user sees nothing until a long tool call such as research finishes; with them they see status messages and progress as it runs.
• Servers send them through the Context object tools receive. The example research tool calls context.info("About to do research...") and context.report_progress(20, 100), then again at 70 of 100 before writing its report.
• The client decides presentation, via callbacks attached separately. A logging callback is passed when creating the ClientSession, and a progress callback, which gets progress, an optional total and an optional message, is passed per call_tool(). A CLI can print them, a web app push them over WebSockets, SSE or polling, and a desktop app update its UI.
• Handling these notifications is entirely optional. The lesson calls them pure user-experience enhancements that a client may ignore or show selectively. It notes the 2026-07-28 spec revision deprecates logging, which still works in version 1 of the Python SDK.

2026-11-06 · open the original ↗

• The server requests generation; the client's callback actually performs it. During a tool call the server runs create_message() with its messages, and a sampling callback passed into the client's ClientSession receives them and returns a CreateMessageResult with the generated text.
• MCP's message format needs converting for your LLM SDK. The messages aren't guaranteed to match any SDK's format, so with the Anthropic SDK the callback needs a little conversion logic.
• The server is free to use the returned text however it likes. It can feed it into the tool's workflow, make another sampling call, or return it directly.

2026-11-06 · open the original ↗

• Sampling lets a server use Claude through the connected client. Rather than calling Claude itself, the server sends a prompt and asks the client, which already has a Claude connection, to make the call and return the text; in the example, a research tool fetches Wikipedia articles and has the client summarize them.
• It moves complexity, credentials and token cost off the server. The alternative, direct access, means the server needs its own API key, authentication, cost management and Claude integration code; with sampling the client pays for its own tokens.
• Sampling matters most for publicly accessible servers. The lesson's reasoning is that a public server shouldn't let arbitrary users generate unlimited text at its owner's expense.
• Implementation needs a server call and a client callback. The server tool calls ctx.session.create_message() with SamplingMessage objects, max_tokens=4000 and a system prompt in the example, raising if the result isn't text; the client passes a sampling_callback into ClientSession that calls Claude and returns a CreateMessageResult. The lesson notes the 2026-07-28 spec revision deprecates sampling, logging and roots, all of which still run on version 1 of the Python SDK.

2026-11-06 · open the original ↗

• Each MCP primitive is controlled by a different party. The review's summary is that tools serve the model, resources serve your app and prompts serve your users. It offers this as a high-level guideline rather than a hard rule.
• Tools are model-controlled: Claude decides when to call them. Use them to give Claude new capabilities. The example is Claude choosing a JavaScript execution tool when asked to calculate the square root of 3.
• Resources are app-controlled: your code decides when to fetch data. The course project used them to fill autocomplete and add context to prompts. Claude's "Add from Google Drive" feature is cited as the same pattern.
• Prompts are user-controlled, workflows started from buttons or slash commands. The workflow buttons beneath Claude's chat input are given as examples.

2026-11-06 · open the original ↗

• Clients list prompts, then fetch one with arguments filled in. list_prompts() returns session().list_prompts().prompts. get_prompt(prompt_name, args) returns the result's messages, and each argument, e.g. {"doc_id": "plan.md"}, is passed to the server's prompt function as a keyword argument.
• In the CLI, prompts appear as slash commands. Typing /format offers a dropdown of the six documents. The finished prompt goes to Claude, which uses the available tools to fetch and reformat the chosen one.

2026-11-06 · open the original ↗

• Server-provided prompts beat what users would write themselves. Users can already type "reformat the report.pdf in markdown" and get decent output. A server author can craft, test and evaluate a specialized prompt that handles edge cases, so users get that expertise without learning prompt engineering.
• Prompts are defined with a decorator and return a list of messages. The example @mcp.prompt(name="format") takes a doc_id and returns [base.UserMessage(prompt)], instructing Claude to rewrite the document in markdown using the edit_document tool. Multiple user and assistant messages can be returned to build longer conversation flows.
• Test prompt interpolation in the inspector before users depend on it. It shows exactly what messages Claude will receive with the variables filled in. The claimed benefits are consistency, encoded domain expertise, reuse across clients and a single place to update.

2026-11-06 · open the original ↗

• The client's read_resource parses the result according to its MIME type. It calls session().read_resource(AnyUrl(uri)) and takes the first item of contents, since normally only one resource is needed. If that item is text with type application/json, it returns json.loads(text); otherwise it returns the raw text.
• Putting resource content in the prompt beats a separate tool call. In the CLI, typing @ shows an autocomplete of resources, and the selected document's content goes into the initial context. The lesson argues this gives a smoother experience and immediate answers about the data.

2026-11-06 · open the original ↗

• Resources expose data for fetching, like GET handlers in HTTP. They suit reading information rather than performing actions. The client sends a ReadResourceRequest with a URI and the server returns a ReadResourceResult.
• Resources let the app inject context so Claude needn't call tools. The worked feature is @document_name mentions. One resource lists document names for autocomplete; another fetches a mentioned document's contents, which the code places in the prompt inside a document tag.
• Direct resources have fixed URIs; templated resources take parameters. docs://documents returns the list of keys. docs://documents/{doc_id} has its parameter parsed by the SDK and passed to the function as a keyword argument.
• The mime_type hint tells clients how to read the returned data. The examples are application/json, text/plain and application/pdf. The SDK serializes return values itself, so you return a data structure rather than a JSON string. The inspector lists the two kinds separately, under Resources and Resource Templates.

2026-11-06 · open the original ↗

• Real projects usually build either an MCP client or a server, not both. The course builds both only to show how they fit together.
• A custom wrapper class around the SDK's ClientSession handles connection cleanup. The session is the actual server connection and needs careful resource management. The course's MCPClient class exists to clean it up automatically and make it easier to use.
• Two thin methods give the app everything it needs for tools. list_tools() returns session().list_tools().tools for sending to Claude; call_tool(tool_name, tool_input) forwards Claude's chosen tool and arguments to the server.
• The client can be tested on its own, then end to end. uv run mcp_client.py runs the file's test harness and prints the tool definitions. uv run main.py with "What is the contents of the report.pdf document?" exercises the full loop: list tools, Claude picks read_doc_contents, the client executes it, and Claude answers.

2026-11-06 · open the original ↗

• The SDK's browser inspector tests a server without any client application. mcp dev mcp_server.py starts it at a local URL, typically http://127.0.0.1:6274. Click Connect, then use the Tools tab's "List Tools" and "Run Tool" with inputs such as deposition.md. The lesson warns the interface is still changing and may look different.
• Server state persists between inspector calls, so multi-step workflows can be checked. Running edit_document and then read_doc_contents confirms the edit took effect, which the lesson presents as a replacement for separate test scripts when iterating, testing edge cases and debugging.

2026-11-06 · open the original ↗

• The Python SDK's decorators replace hand-written JSON tool schemas. FastMCP("DocumentMCP", log_level="ERROR") creates the server in one line. @mcp.tool(name=..., description=...) plus Python type hints and Pydantic Field(description=...) produce the schema Claude reads. The course's starter project, cli_project.zip, uses version 1 of the MCP Python SDK.
• The example server exposes reading and editing over an in-memory dictionary. Six documents such as deposition.md, report.pdf and spec.txt are keyed by ID. read_doc_contents returns a document's text; edit_document takes doc_id, old_str and new_str and does a find-and-replace. Both raise ValueError for an unknown ID.
• Ordinary Python exceptions and type hints double as validation and error handling. The lesson lists the gains as no manual schema writing, automatic validation from type hints, clearer parameter descriptions for Claude, and tools registered automatically by the decorator.

2026-11-06 · open the original ↗

• The MCP client handles protocol traffic so your application doesn't. It is your server's way in to an MCP server's tools, exchanging the messages and dealing with protocol details for you.
• MCP is transport agnostic. The most common setup runs client and server on the same machine over standard input/output, but they can also connect over HTTP, WebSockets or other network protocols.
• Two message pairs carry most of the work. ListToolsRequest/ListToolsResult asks the server what tools it offers; CallToolRequest/CallToolResult asks it to run one tool with given arguments and returns the output.
• A single user query makes two round trips through the client. For "What repositories do I have?", the server first lists tools through the client and sends them to Claude with the query. When Claude picks a tool, the server calls it through the client, the MCP server hits the GitHub API, and the result goes back to Claude for the final answer. The lesson concedes this is many steps but argues each component has one clear job.

2026-11-06 · open the original ↗

• MCP moves tool definition and execution off your own server. Rather than writing and maintaining a schema and function for each piece of a large service such as GitHub (repositories, pull requests, issues, projects), your app connects to a dedicated MCP server that already exposes them as a standard set of tools, prompts and resources.
• Anyone can write an MCP server, often the service provider itself. The lesson's example is AWS possibly releasing an official server for its services; the gain over calling an API directly is that the tool schemas and functions are already written for you.
• MCP complements tool use rather than replacing it. Tool use is how Claude calls a tool; MCP is about who implemented that tool. With MCP, someone else has already done that work.

2026-11-06 · open the original ↗

• Working habits with Claude are the team's, so check them together. The closing lesson is an interactive checklist (not captured in the text) for the channel where the team hands Claude the most work. Each "no" points to the lesson covering it, and the finished list generates a message to post to Claude to start on the gaps. Follow-on resources are listed for individuals, team leads (the Building Effective Human-Agent Teams course) and whoever administers Claude Tag.

2026-11-06 · open the original ↗

• The course's features combine to keep Claude on a goal for weeks. Connections give it the team's tools and information. Memory and instructions teach it how the team thinks. Untagged replies teach it when to act on its own, and routines when to start unasked. All are managed per channel from the Configure page, which any signed-in full member can open.
• Your role shifts from directing tasks to setting goals and reviewing decisions. As you verify more of Claude's work, you scope it to larger projects across several channels. Because your attention becomes the limit, the lesson says to have Claude group its questions and bring each decision with a recommendation. It describes this as how teams at Anthropic work.
• An ownership message names the goal, what Claude owns and what returns. The example sets an October 14 launch with no open blockers. Claude owns keeping things unblocked, gets missing information itself, and brings scope, timeline and trade-off decisions twice a week, grouped. Trust is extended a step at a time, per kind of task.

2026-11-06 · open the original ↗

• Delegate outcomes, and first confirm Claude can reach the inputs. Picture handing the work to someone who knows the workspace completely. Check access with "what can you access from this channel?", then move the task or get a tool connected if needed, and put sensitive work in a private channel.
• A good request states goal, inputs, a check, priorities and output form. Say what you want and why, so Claude can fill in details you didn't specify. Point to sources or an example. Build in verification such as a rubric, cited sources, or separating what was verified from what was inferred. Name audience, polish and decisions to bring back. Ask for a claude.ai page if people will revisit the result.
• Adjust the request to the kind of task. For big jobs, ask Claude to propose a plan outline first. For exploratory ones, say so and let it propose directions. For proactive or scheduled work, say what it owns, optionally by pinning a "north star", one ambitious measurable goal Claude can then work toward on its own.
• While Claude works, steer in the thread with new replies. A longer task updates a progress checklist in place, and those edits send no notifications. Claude posts a new reply when it needs you or has a result, and usually says so if blocked. Editing a sent message has no effect, and each top-level message starts a new task.
• Review against cited sources, then fix the cause, not just the output. Wrong place means move the task or connect the tool. Incomplete work means ask which sources it searched. Unclear requests get rewritten. A missed team pattern gets saved to memory so the whole channel benefits.

2026-11-06 · open the original ↗

• Routines run recurring work on a schedule without anyone asking. The kinds named are daily or weekly reports, continuous monitoring of a channel or repository, and regular checks for overdue or at-risk items. A routine uses the channel's connected tools.
• Write the routine to post only what needs attention. One message should say what to read, what to look for, what to post and when. The example compares the onboarding tracker each weekday at 9am with the previous day's channel talk, names owners and links messages, and posts nothing on a quiet day. That way a post always means something to look at.
• Treat the first run as a draft and correct it in-thread. Claude applies thread feedback to every later run, which the lesson argues keeps the routine worth reading rather than more scroll.
• Routines belong to the channel, not to whoever created them. Anyone in the channel can list them (@Claude !scheduled), pause or stop them by describing the change. They keep running even if the creator leaves the channel or the organization.

2026-11-06 · open the original ↗

• A channel with one kind of work makes Claude a specialist. Everything Claude knows in a channel comes from its history, notes, instructions and tools. A focused channel is also what lets it tell which messages are its job.
• With automatic replies on, Claude decides message by message whether to answer. You steer it with a remembered line, e.g. reply to any account name or open-item question and stay out of scheduling and social chatter. The suggested uses are support channels answered from a knowledge base, policy questions answered from the policy doc, project channels where it finds past decisions, and incident channels where it spots patterns in reports.
• A standing responsibility has Claude pursue a goal for days or weeks. The shapes given are coordinating a launch (updating trackers, reminding owners, flagging slips) and owning an outcome, such as a queue under a day old, by bringing decisions with a recommendation. A third is continuity as people rotate, including flagging proposals that contradict earlier calls. The job is saved to notes first, then moved to instructions once it works.
• When a channel gets noisy, sharpen the instructions before turning replies off. "Only respond when someone @-mentions you" switches the channel's Respond automatically setting for everyone. A narrower line refines it through notes. The same line sent inside a thread, or !mute / !unmute, quiets just that thread.

2026-11-06 · open the original ↗

• Lasting feedback lives in memory or channel instructions; instructions win conflicts. Memory is notes Claude keeps, added on its own or when told. Channel instructions are rules a person types into the settings page (Configure, under any Claude reply), and Claude reads them at the start of every thread.
• Notes are scoped to a channel, the workspace, or your DM. Use @Claude remember for this channel: … to add a channel note. Workspace notes apply everywhere but are saved only from public channels, and only for things everyone should know, like a company-wide naming rule. Notes go stale, so you can ask what Claude remembers, correct an entry or tell it to forget one. Organization Owners can also edit notes in admin settings.
• Instructions are closely followed guidance, not an enforcement mechanism. For anything that must never happen, the lesson says to use a setting or access control instead. They suit purpose, untagged-reply rules, tone, sources and filing. They take effect in new threads only, and admins can lock the page. The bug-triage example has Claude look up error IDs, propose an owner, keep replies under six lines and never touch production.
• Try rules in memory, then promote settled ones to instructions. Memory holds a rule more loosely. Telling Claude "keep replies under six lines" saves it to memory as a quick trial, and once proven it moves to instructions, via a channel manager if you lack edit access.
• Weak results usually trace to one of four fixable causes. Thin answers mean missing tool connections. Answering what it should leave alone means no defined job in the instructions. A correction that keeps recurring was never marked "remember for this channel". Silence means Claude isn't turned on for that channel.

2026-11-06 · open the original ↗

• Choose where to ask Claude as you would choose for a teammate. DM what you'd DM a person, use a group's private channel for that group's work, and use the public channel where the work happens for anything the team could use. What differs by place is who else is in the work, which tools Claude can use and where it keeps what it learns.
• When several places fit, the public channel wins. Colleagues can add context, correct details or carry the task on, and Claude reads every reply. Its corrections go to channel notes that serve everyone. Connected tools, instructions and routines are set up once for all members. Used for anything else, the lesson argues, DMs and private channels keep work private that didn't need to be.

2026-11-06 · open the original ↗

• A private channel's boundary binds Claude exactly as it binds people. Everything from public channels works there for members only. From any other channel or DM, Claude behaves as if the channel, its tools and its memory don't exist, so it suits people matters, finance, legal and confidential escalations.
• Learning flows into a private channel but never out. The channel uses workspace notes saved from public channels. What it learns goes only to its own notes, so confidential context cannot surface elsewhere.
• In a private channel, the member list is the access list. A tool connected there, such as billing in a finance channel, is available through Claude to every member, at whatever access Claude's account was given. The lesson advises least access and a tight membership. Actions are logged in each tool under Claude's own account.
• Admins decide whether Claude answers in guest or externally shared channels. Where it does answer, it keeps to that channel and doesn't search the rest of the workspace.

2026-11-06 · open the original ↗

• Prefer a public channel whenever more than one place fits. Others can see, correct and continue the work, and what Claude learns there helps everyone in the channel. Claude sees the channel's full history, including messages from before it was added. By default, tagging it needs no personal Claude account because the organization covers the work.
• Team connections let Claude act on the discussion, as itself. Whoever manages Claude Tag decides which tools, such as GitHub, Drive, a CRM or the team calendar, connect to each channel. The role examples are pulling a CRM account before a sales call, running a warehouse query, drafting a support reply and opening a pull request. Results come back in the thread or as a claude.ai page Claude can keep editing.
• Claude's account permissions set what everyone in the channel can do. If that account can change issue-tracker tickets, anyone in the channel can ask Claude to update one; if it is read-only, they can only look tickets up. Actions appear under Claude's account, not the requester's, and Claude cannot read other people's private channels or DMs from there.
• Personal connectors in a channel serve only you, gated by a prompt. Asked to add Thursday's launch review to your calendar, Claude acts under your name. It first shows you three choices: Allow (it posts directly but holds responses that look sensitive, a check the lesson says can miss things), Allow with review, or Don't allow. On Enterprise, an organization Owner can remove one Allow option, and anything Claude posts is visible to the whole channel.
• Verify a fetched record against its source, and correct it in-thread. The exercise asks Claude what it can access, fetches one real item, and checks whether it is current, complete and sourced. A colleague's correction in the thread is singled out as the thing a DM cannot do.

2026-11-06 · open the original ↗

• In a DM, Claude works as you, in your own tools. It runs on your Claude account and connectors, so it can read your calendar, email and files. It can also search any public channel you name and use whatever you attach or paste. In a channel, by contrast, it works under its own name. Where an organization has turned DMs off, a channel holding only you and Claude stands in.
• DM actions happen under your name, and DM learning stays private. What Claude learns in a DM is kept to that DM and never reaches shared workspace notes, and nothing done there is visible to channels. You can disconnect connectors from account settings, and the lesson says to review before letting Claude send or change anything.
• A DM's privacy is also its limit. Colleagues can't correct, add to or continue the work. Team-channel systems such as the CRM or tracker aren't reachable, so answers about them are thinner. Corrections made after pasting a result into a channel don't teach Claude anything. When any of that matters, the lesson says to ask in a channel.
• The exercise is a tailored morning brief set up as a routine. You name the channels and people that matter, or have Claude search the workspace and propose them. You then ask for a brief and refine the first one in its thread, e.g. for format, a weekly count of unanswered questions in a channel, or whose messages come first.

2026-11-06 · open the original ↗

• Claude Tag puts Claude in Slack, replying in threads with channel context. You tag @Claude in a channel and it replies under your message, having already read the channel so you don't have to explain background. It can also use any tools connected to that channel, such as Google Drive, a calendar or a ticketing system. Anyone in the channel can reply in the thread to add detail or redirect it, with no new tag needed.
• Living in the channel lets Claude work when nobody tags it. The lesson names three modes. Untagged replies handle each new message in, say, an IT-help or bug-report channel. A standing responsibility looks after something like a launch checklist for days or weeks. Routines repeat a task on a schedule, e.g. a channel summary every Monday at 9am.
• Claude is the same in a DM, public channel or private channel. What changes is who can join the work, what Claude can reach and where it keeps what it learns. Later lessons cover each place. The setup exercise is /invite @Claude, then asking a question whose answer should draw on recent channel posts.

2026-11-06 · open the original ↗

• The final assignment is one real task done with AI this week. Start with delegation: decide which parts need your judgment and relationships, and pick a tool to match the task's privacy needs. Describe the school, goals and students without identifying details, and iterate. Before sharing anything, apply diligence. The lesson's disclosure test is that if knowing AI was used would change someone's view of the work, they may need to be told.
• The 4Ds are a loop you re-enter, not a fixed sequence. You may move from delegation to description to discernment and then decide to delegate differently, which the lesson frames as fluency growing.
• The course closes by having teachers build something, not just complete tasks. Prompts such as "I wish ___ existed" or "I spend too much time doing ___" seed a first version, inspired by projects from Teach For America's educator work. It is then tested against each D and iterated. Follow-ups are Anthropic's use-case library, a shareable completion badge, and the AI Fluency: Framework & Foundations course.

2026-11-06 · open the original ↗

• On real tasks the 4Ds loop, not run once in order. The worked case is Marcus, a trainer preparing a differentiated-instruction session for first-year secondary teachers in high-need schools, with two weeks and little prep time.
• Delegate the parts AI improves; keep the parts that need judgment. He hands AI the framework research, example activities, a timed agenda and ideas for modelling. He keeps his personal opening story (32 students at eight reading levels in his first year) and the choice of which frameworks and activities fit this group. The research gets faster, he argues, but credibility and fit only happen if he stays in the chair.
• Spell out audience, goal, format and constraints in the request. The request is for a 90-minute session mixing instruction, modelling and practice, ending with each teacher holding a plan for one class for one week. It specifies two or three frameworks actually used in secondary classrooms, and nothing needing prep time, purchases or colour printing.
• A structurally sound draft can still miss the real situation. Two activities assumed small groups and real student data, which is unworkable at 4:30 on a February Tuesday, so they were rewritten for a hypothetical roster. One framework was correct but impractical and was replaced with a lighter one. The first draft got him 70% of the way in 15 minutes; the remaining 30% was the part needing his judgment.
• Diligence means owning the result and disclosing AI's role. He adds his own voice and experience, tells his manager AI helped research and draft the structure, and notes what the draft missed for next time. The total was about two hours over several sittings, with research and first draft, formerly a full afternoon, taking 20 minutes.

2026-11-06 · open the original ↗

• Models behave differently because their builders encode different values. Training and fine-tuning choices set how cautious, confident, creative or willing to push back a model is, and that shows in its voice and handling of ambiguity. Labs such as Anthropic publish a constitution, a set of written principles the model is trained against, so its underlying values are visible.
• Pick a model for the task as you'd pick a colleague. The lesson suggests more expressive models for brainstorming a staff event and more measured ones for a sensitive message to a student or family. Running one prompt through two models and comparing is itself informative.
• AI is not the pedagogy; the teacher is. Knowledge of team dynamics, stakeholders and students' histories is something AI lacks, having only patterns and language. Teachers also need a working point of view because students will ask them.
• A personal AI value document sets intentions, principles and boundaries. An intention is one sentence on why you use AI. Principles are operating rules, e.g. no identifying student or staff data in public tools, review every output before your name goes on it, and disclose significant AI help. Boundaries are work you keep because the doing is the point, such as reflective writing or family communication. The lesson argues revisiting it every few months is where its value lies.

2026-11-06 · open the original ↗

• Protect student data before choosing what AI analyzes. Ms. Okafor's quarterly analysis of benchmarks, quizzes and exit tickets falls under FERPA. She starts from the district's approved-tools list, since privacy protections and data retention vary by tool and plan. She sends only what the pattern-level analysis needs: names replaced with generic IDs, demographic fields and the IEP-status column dropped, class period and standard-by-standard scores kept.
• Validate AI first on data you've already analyzed by hand. Run on last quarter's data, Claude correctly found that periods two and six outperformed and that exit-ticket completion tracked benchmark growth. It missed that period four's numbers reflected a three-week long-term substitute. Once prompted to account for sub-coverage dates, it adjusted. The test shows what AI does unaided, what needs added context, and what not to delegate, and leaves a reusable playbook.
• Validation builds confidence but doesn't remove responsibility. Errors can affect grades, intervention placements and family conversations. Diligence means checking new results against classroom knowledge and the original data before acting, and telling coaches, principals and teams how AI contributed.
• Dependency, displaced human interaction and bias are classroom-specific risks. "The person doing the work is doing the learning": AI that replaces critical intellectual work is a problem. AI should enhance in-person collaboration, not replace it. Bias can be indirect too, through default perspectives, better answers in some languages, or arguing one side more persuasively.
• Some data must never enter a general-purpose AI tool. The lesson's rules: never enter IEP details, 504 accommodations or disciplinary records. Strip names, IDs and demographic flags even on well-protected tools, read the terms, and follow existing district data protocols. After an accidental share, delete the conversation, request deletion from the provider and follow district incident response.

2026-11-06 · open the original ↗

• Specific context turns a generic AI draft into classroom-fit material. The worked case is Ms. Okafor, a second-year 7th-grade science teacher on an NGSS cells-and-body-systems unit. Her readers range from 3rd- to 9th-grade level, four have IEPs requiring reduced, chunked text, and some are multilingual learners. Instead of "write a reading passage about organ systems", she asks for one page on how the circulatory and respiratory systems interact, at roughly 6th-grade level, with five bolded in-context vocabulary terms, analogies, short paragraphs and a build toward her claim-evidence-reasoning summative.
• Uploaded past materials set your voice and rigor faster than prompts. Unit plans, rubrics and successful passages show AI the expectations and language students are used to. Persistent context in Claude comes through projects, connectors and styles, and the lesson says other tools have equivalents.
• A clean-looking first draft still needs a discernment checklist. Check that the science is accurate rather than oversimplified into error, that the reading level hasn't drifted up, and that the vocabulary is what the standard needs. Ask whether anything would land badly with these students and whether it actually models the reasoning the summative requires.
• Revise with precise instructions rather than discarding the draft. Her follow-up asks Claude to define "diffusion", shorten sentences and swap "facilitate" for "help", and add an explicit claim tied to evidence. The lesson warns that AI may over-correct, and that "make it more accessible" is too vague. The loop then runs again for the scaffolded and extension versions.
• AI speeds up materials creation but the teacher still owns judgment. The time saved goes to grouping, anticipating misconceptions and handling a lesson that goes sideways. Diligence means standing behind whatever reaches students, whether a passage or report-card comments.

2026-11-06 · open the original ↗

• Generative AI creates new content rather than classifying existing data. The example contrasts a spam filter with a system that writes a new email. LLMs such as Claude are "large" because they have billions of parameters.
• Three converging developments, plus scaling laws, produced today's models. Kyra, of Anthropic's education team, names the 2017 transformer architecture, the explosion of digital training data and GPU/TPU compute clusters. Scaling laws showed performance improving predictably with size, data and compute, while abilities such as step-by-step reasoning emerged without being explicitly programmed.
• Models generate statistically likely text rather than looking answers up. Pre-training on next-word prediction yields a "very competent literal document completer". Fine-tuning with human feedback and reinforcement learning then shapes it to follow instructions and avoid harm. This is why it can discuss almost anything yet sound confident when wrong.
• Each limitation follows from how the system is built. There is a knowledge cutoff, e.g. November 2024, after which the model knows nothing without web search. Hallucinations arise because training doesn't verify facts. The context window drops older material first-in-first-out, output is non-deterministic (adjustable via temperature), multi-step reasoning is weak though reasoning models are improving, and needed data or tools may simply be unavailable.
• The best results pair human judgment with AI's speed and scale. Humans supply critical thinking, creativity and ethical oversight. The exercise tests a topic the teacher knows cold: explain it at three levels, spot-check suggested resources for hallucination, and probe time-sensitive or local questions for stale answers.

2026-11-06 · open the original ↗

• No lesson content was captured for this page. The archived text holds only an interactive-content "Loading" placeholder, so there is nothing to summarize beyond the title "Explore!".

2026-11-06 · open the original ↗

• Good prompting is necessary but not sufficient for AI fluency. The inner Description–Discernment loop covers daily interactions. The outer Delegation–Diligence loop covers whether to use AI at all and the ethical duties that follow, in the workplace and community.
• Description defines the output, the approach and AI's role. The lesson contrasts "write a summary of this report" with a request for an eighth-grade audience, the three highest-impact findings and under 300 words. You can also set the steps or reasoning to follow, and a role such as critical reviewer, brainstorming partner or fact checker. Anthropic's research found description skills come most naturally.
• Discernment is the rarest skill and the one most worth building. It means checking the output (accurate statistics, the right register for the audience) and the reasoning behind it, then iterating rather than just accepting or rejecting. The research found questioning AI's reasoning, checking facts and spotting missing context were among the least common behaviours observed.
• Delegation means understanding both the task and the tool. A routine status update may suit an AI first draft; a sensitive message to a family about a child's progress needs the teacher's own tone. Confidential data calls for checking the system's privacy and security features.
• Diligence keeps the human accountable for every final result. That means choosing AI systems deliberately, being transparent with colleagues and stakeholders about AI's role, and verifying and vouching for every output. The lesson's exercise builds a reusable context document that leads with the teacher's values, with no student-identifying details.

2026-11-06 · open the original ↗

• In K–12, student learning and privacy come before AI convenience. Zach, a California high school math and science teacher, cites FERPA, COPPA and district approval lists. He stresses that teachers stay professionally accountable for whatever reaches students or families, and AI help doesn't transfer that. The question the course poses is not only whether AI can do something but whether it should, and whether it serves students.
• AI fluency is a durable relationship with AI, not product or prompt knowledge. The course defines it as using AI efficiently, effectively, ethically and safely, combining skills, knowledge, insight and values, and argues it compounds as models change. Its core is the 4D Framework by professors Joseph Feller and Rick Dakan.
• The 4Ds run as two loops. Delegation–Diligence governs whether and how to use AI and owning those choices. Description–Discernment governs getting more from each back-and-forth interaction.
• Teachers already practise description and discernment. Clear context, steps and success criteria are what lesson planning and assignment-giving involve; assessing student work and curriculum makes teachers trained evaluators. The course says fluency comes from building and iterating rather than lectures. A free Claude account, or any other language model, is enough for the exercises.

2026-11-06 · open the original ↗

• The course was co-built with teachers, grounded in educator research. Anthropic's partner, Teach For America, supplied real classroom examples and pedagogical review, and piloted the exercises with teachers to gather feedback. The page describes Teach For America as a leadership development organization with over 72,000 alumni. The stated aim is helping educators use AI effectively, efficiently, ethically and safely.

2026-11-06 · open the original ↗

• Fix the tool problem that hurts most first, using its lesson. The wrap-up groups the course into four abilities: getting calls right (descriptions, evals, strict tool use), cutting waits (parallel calls, streaming), using Anthropic's server tools (code execution, web search, computer use only when there's no other way in), and spending less (measuring input tokens, caching definitions, programmatic tool calling). For gaps it points to the Troubleshooting tool use page, the Tool reference, the Claude Cookbook's Tools category, and the Academy's Introduction to Model Context Protocol course.

2026-11-06 · open the original ↗

• A tool loop's cost compounds because every request resends everything. Each request carries tool definitions, system prompt, question and all prior tool results. In the fictional Meridian demo (40 engineers, "who was under 70% utilization in June 2026?"), request 1 was 606 input tokens and request 37 was 47,905; the run took 42 requests, 1,124,799 input tokens and $2.29. The lesson says to print usage.input_tokens on every response to see which part is growing.
• Programmatic tool calling keeps intermediate results out of Claude's context. Claude writes a script that calls your tools inside the code execution container, and only what the script prints reaches the model. The same question took 3 requests, 28,486 input tokens and $0.0667 (Sonnet 5, September 2026 prices, code execution time billed separately). The captions add that the classic run miscounted the roster but both runs found the same six names.
• Setup takes four changes, with real compatibility limits. You add the code execution tool, give each callable tool allowed_callers naming code_execution_20260120 or later, send the container ID back on follow-ups (a pending call times out after a few minutes), and document each tool's output JSON shape so the script can parse it. As of October 2026 it doesn't support strict: true tools or disable_parallel_tool_use, doesn't run on Haiku 4.5, and helps little when each call depends on reasoning over the previous result.
• Caching tool definitions is a one-line win, but it fails silently. Putting cache_control on the last tool caches the whole tools prefix. On Sonnet 5 a cache read costs 0.1x the input price, a write 1.25x, and a one-hour TTL write 2x; Meridian's 14-tool agent (3,305 tokens of definitions) fell from $0.0554 to $0.0154 over eight questions. Editing any tool definition invalidates the cache, prefixes under 1,024 tokens quietly don't cache, and input_tokens then leaves out cached tokens, so the true total also needs the cache read and creation counts.
• Turn on caching first, then A/B test programmatic calling. The recommended order is caching (one line), then running some normal traffic with and without allowed_callers and comparing billed input tokens.

2026-11-06 · open the original ↗

• Computer use drives software through screenshots, while your program performs every action. Claude never touches the desktop. It returns tool calls (screenshot, click at coordinates, type), your program carries them out and returns results, some of them as images. The fictional Meridian export of plot set MEG-2026-0142 from a no-API app called PlotDesk took seven actions.
• Isolate the desktop, because on-screen content can hijack Claude. Text in a page or image can override instructions, so each session gets a dedicated container or VM with no credentials, no host mounts, network access only to the hosts the task needs, and your program and API key kept outside it.
• The SDK computer toolset needs only the actions you implement. You subclass the beta toolset class (Python SDK 1.12.0+), write one method per action, and every action you leave out is sent as disabled. Tool Runner runs the loop. As of October 2026 this toolset is on the Claude API and Google-managed Claude on Google Cloud, while Bedrock, Foundry and Claude Platform on AWS have older beta versions needing a different tools entry and a beta header.
• A confirm callback lets a person approve risky actions. The SDK calls it before each action, and anything other than True refuses the action and tells Claude a person turned it down. Because confirm can't see the screen, Meridian auto-approves screenshots and routes every click and type to a human operator watching the desktop.
• Use computer use only when no direct interface exists. Every screenshot stays in the conversation, so each step costs more than the one before. An MCP server, API or command line is preferable, and the browser use tool fits better for tasks that stay inside web pages.

2026-11-06 · open the original ↗

• Web search is a server tool: one tools entry, no handler. It runs on Anthropic's infrastructure with no tool_result to send back. The demo uses type web_search_20260209 (name always web_search) and says to copy current type strings from the tool reference. Searching usually finishes within one request, and on pause_turn you resend the content as an assistant message. Each search is billed on top of tokens.
• Dynamic filtering trims search results before they cost you tokens. On Claude 4.6+ with web_search_20260209 or later, Claude runs code server-side to keep only relevant content in context. The captions say it needs a model that supports programmatic tool calling; elsewhere you must set allowed_callers to direct or the API returns a 400.
• allowed_domains restricts search to sources you can stand behind. The fictional Meridian proposal, which carries professional liability, restricted search to csagroup.org, cwbgroup.org, ontario.ca and canada.ca, written as bare domains with subdomains included. Of four cited Canadian standards, Claude found one wrong (Division 1, not 3) and said it couldn't confirm one A23.3 subclause number.
• Citations come free, but JSON output strips them. Answers come in several text blocks to be joined, plus web_search_tool_result blocks with each result's title and url. The captions add that document citations plus JSON output return a 400, while web search with JSON output runs but loses its citations.
• Check platform availability before designing around web search. At recording, per the captions, it wasn't on Amazon Bedrock at all, and Claude on Google Cloud got basic search without dynamic filtering. Pricing, max_uses caps, block rules and org-level enablement are left to the docs because they change often.

2026-11-06 · open the original ↗

• Hand Claude a sandbox instead of asking it to do arithmetic. Code execution is a server tool running sandboxed Python and Bash on Anthropic's side, with no outbound network and common analysis libraries preinstalled. You add one tools entry (the demo uses code_execution_20260120) and write no handler. As of October 2026 it runs on the Claude API, Claude Platform on AWS, Anthropic-managed Claude on Google Cloud and Anthropic-hosted Microsoft Foundry.
• Files enter through the Files API and container_upload blocks. You upload each file to get an ID, then reference it in a container_upload block in the same message as the question. The captions note the Files API is generally available, so no beta header is needed. Files Claude writes to its output folder come back as file IDs you can download, which is how the demo got a matplotlib chart.
• State lives in the container, so reuse its ID. Python state carries between turns only on code_execution_20260120 or later. Idle containers are restored with their files if you pass container.id back. At recording, Haiku accepted the newer tool types but didn't keep Python state between turns, so Sonnet or Opus are preferred for this pattern.
• Intermediate data stays in the sandbox, not your context. In the fictional Meridian demo, 12 pump-station CSVs were analyzed without raw rows entering the prompt, and Claude iterated on its own output. It found Station 7 exceeded its 600 L/s design capacity twice, in April and May 2025.

2026-11-06 · open the original ↗

• Streaming shows users what Claude is doing during the wait. Without it, a tool loop only sees finished responses, so the UI shows a spinner. In the simulated Meridian demo both builds took about 7.5 seconds, but the streaming one put up a status line at 1.8 seconds.
• A streamed tool call names the tool first, then streams input fragments. content_block_start carries the tool name with empty input, then content_block_delta events carry input_json_delta fragments, then content_block_stop closes the block. The final message_delta with stop_reason tool_use is the cue to run the tool.
• Buffer fragments per block index and parse only at block stop. The captions warn that fragments split mid-key, mid-value or mid-escape, some are empty strings, and several tool calls in one turn interleave unless each index has its own buffer. The SDK's messages.stream does this for you, but the wire format is what you'll be debugging.
• The switch is small and the rest of the loop is unchanged. You replace client.messages.create with client.messages.stream, map tool names to friendly status text (Meridian's STATUS dict turns lookup_project_status into "Looking up project..."), and call stream.get_final_message() for the usual response object.

2026-11-06 · open the original ↗

• Running independent tool calls concurrently roughly halves the wait. Claude 4 and later emit several tool_use blocks in one response by default. In the fictional Meridian site check (project status, weather, permit), sequential calls took 19.9 seconds and parallel ones took 10.8, so the query waits only on the slowest lookup.
• Your loop must answer every tool_use block, or the API rejects it. A loop that reads only the first block leaves the other calls without results. The lesson collects all blocks and runs them in a ThreadPoolExecutor so I/O waits overlap.
• Splitting results across messages trains Claude out of parallel calls. All tool_result blocks, each keyed by tool_use_id, belong in one user message. Separate messages make the conversation look like one-at-a-time tool use, which the lesson calls a common reason parallelism drops. The captions add a system-prompt nudge to invoke independent tools simultaneously.
• Return failures as is_error results instead of raising exceptions. An uncaught exception kills the loop and throws away the good results. The error text should say what went wrong and what to try next. A call skipped because an earlier one failed still needs an is_error result.
• You decide which calls must run in order, not the model. Reads that don't depend on each other are safe to run together. Writes, or steps that need an earlier success, should run one after another. The captions note that disable_parallel_tool_use goes inside tool_choice (it errors at the top level), and Tool Runner handles the loop if you don't need custom batching.

2026-11-06 · open the original ↗

• Strict tool use makes schema-invalid tool input impossible to sample. With strict: true, the API compiles the JSON Schema into a grammar and allows only tokens it permits (grammar-constrained sampling), so a string can't appear where an integer belongs. The flag sits beside name and input_schema, and every object needs additionalProperties: false.
• Generate the schema from your validator so the two can't drift. Meridian's handwritten schema typed the license number as a bare string, so "PE 46196" passed the schema but failed a validator requiring PE- plus five digits. Building the schema with Pydantic's model_json_schema() (or Zod in TypeScript) carries the pattern over, with extra: forbid becoming additionalProperties: false.
• Strict guarantees the shape, not the facts. Across 100 stamp requests on Haiku 4.5, the handwritten schema with strict off got 79 rejections, and the generated schema with strict on got none. Of the 28 requests that never mentioned a license, all came back null, so none were invented. The validator is left checking only business rules.
• Bounds and complexity limits catch people out. As of October 2026, minimum/maximum/minLength/maxLength return a 400, so they go in descriptions and validators. A request can hold at most 20 strict tools, 24 optional parameters and 16 anyOf/type-array parameters across all tools, and going over returns "Schema is too complex for compilation." Compiled grammars are cached separately (about a day, per the captions), so PHI must stay out of names, enums and patterns.
• Input can still slip, and forced tool choice fails on newest models. Mismatches happen after refusals, max_tokens cutoffs or enum/const case changes. tool_choice any/tool returns a 400 on Opus 5.5, Sonnet 5.5, Fable 5.1 and Mythos 5.1, so leave it on auto and ask for the tool in the prompt. Strict tools can't be used with programmatic tool calling.

2026-11-06 · open the original ↗

• When Claude misuses a tool, look at its definition first. Claude never sees your function, only the definition you send and the results you return. Rewriting the fictional Meridian assistant's definitions raised its eval score from 14/30 (47%) to 26/30 (87%) on the same model, claude-sonnet-5.
• The description does the most work and needs several sentences. The lesson asks for three to four sentences or more: what the tool returns, when to use it and when not to, what each parameter means, and what it doesn't return. Meridian's version names its trigger (a specific project by name or job number), says to normalize partial numbers to MEG-YYYY-NNNN, and points permit and billing questions to other tools.
• Merge overlapping thin tools into one tool with parameters. Four one-fact project tools made Claude guess between them. Combining them into lookup_project_status with a fields enum took the set from six tools to three, and the overlap misses went away. The captions add namespacing for larger sets and the tool search tool past about 50 tools.
• input_examples and specific error messages fix format mistakes. Examples are validated against the schema (an invalid one returns a 400) and cost about 20–200 tokens, per the captions. Error text acts as a prompt too: "Job number not found, verify format" lets Claude correct itself, where "Error 404" teaches it nothing.
• Fix only the part at fault and rerun the eval. Wrong or extra tool calls point to the description or overlapping tools. Wrong value types or formats point to the parameter description and examples. An eval of 30 labeled questions shows whether a change helped.

2026-11-06 · open the original ↗

• Plugins package a working .claude setup into one installable, versioned unit. A plugin can bundle skills, subagents, hooks and MCP server configs, plus LSP servers, background monitors, themes and a slice of settings.json. It installs with /plugin install github@claude-plugins-official, which shows details and a scope choice first. /reload-plugins --force is only needed if the reload warns that it would re-read the whole conversation.
• A private marketplace gives teams one source for discovery and updates. You add it once with /plugin marketplace add your-org/claude-plugins, and after that installs resolve through it, with version tracking and updates in one place. The Discover tab lists plugins across your marketplaces.
• Read a plugin before installing, because it runs with your privileges. Its hooks fire on every matching tool call whether you read them or not, so a community Stop hook could call a network endpoint every turn with no warning. Community listings are submitted by their authors and the official marketplace is curated separately, but the lesson says "listed isn't the same as trusted." Claude Code's details view shows the contents and estimated context cost.
• Plugin components stack with yours, and one key changes default behavior. A plugin's hooks fire alongside your own rather than replacing them, and its skills, agents and commands are namespaced under the plugin name. Its settings.json is limited to two keys (agent and subagent status line), but the agent key promotes one of its subagents to the main thread with that subagent's system prompt, tool restrictions and model.
• Packaging your own needs no restructuring, just a name. Components are discovered by the same .claude conventions: a folder per skill, a markdown file per agent, and hooks/hooks.json and .mcp.json at the root. The optional .claude-plugin/plugin.json manifest needs only name, which namespaces skills as /plugin-name:skill-name, and the lesson advises versioning it like any other dependency.

2026-11-06 · open the original ↗

• The less you watched a run, the harder you verify it. A short session you watched scroll by needs a glance. An unattended or CI run that nobody saw needs a real check that reconstructs what happened.
• Auto mode's classifier blocks danger but never judges correctness. Unattended work runs should stay in auto mode rather than bypass permissions, so most actions are still screened. That screening doesn't lower the verification bar at all.
• Start from the diff, not Claude's summary. Run /code-review, then read git diff yourself: the planned files first, then anything outside the plan. A tidy summary can hide a change to a file you never expected it to touch.
• Make tests a hook-enforced gate rather than a claim. A Stop hook runs the tests and refuses to end the turn on failure, and a PostToolUse hook lints and type-checks after each edit. Exiting with code 2 feeds the failure back to Claude to fix, and the check fires on every run without anyone asking. Headless runs are checked by their JSON result and exit code.
• A fresh reviewer with no memory catches rationalized mistakes. A new session or subagent reviewing the changed code, with no stake in how it was built, finds what the original run talked itself past.

2026-11-06 · open the original ↗

• Use managed Code Review for PR reviews; it needs nothing built. It's an Anthropic-hosted service on Team and Enterprise plans, enabled by a Claude org Owner under "Allow code review" in admin settings, with the Claude GitHub app installed by a GitHub org owner. It can run when a PR opens, on every push, or on an @claude review comment. Review agents check the diff against the whole codebase and post deduplicated, ranked findings inline by severity, with a summary table in the check run.
• Code Review only comments, so humans stay the decision-makers. It never approves, blocks or pushes fixes. You fix and push yourself, and can run /code-review locally first (its --fix flag applies the findings to your working tree).
• The GitHub Action is for CI work that goes beyond review. anthropics/claude-code-action@v1 is set up through /install-github-app (repo admin required), which installs the app and sets the API key secret. Its inputs include anthropic_api_key (or an OAuth token or workload identity federation), an optional github_token, trigger_phrase (default @claude), use_bedrock/use_vertex/use_foundry, prompt (runs without a mention) and claude_args.
• One workflow answers @claude mentions and another runs on a schedule. The mention workflow needs id-token: write and can implement a request from a comment, pushing commits and posting what it did. A cron workflow (e.g. 9:00 UTC) writes its result to the run log rather than a comment, and workflow_dispatch adds a manual trigger.
• Use claude_args to keep unattended runs bounded. --max-turns 5 hard-caps the loop. The permission mode should not stop to ask, since nobody is there, and allowed tools should be exactly what the job needs, which means read-only for a report.

2026-11-06 · open the original ↗

• Cloud scheduled tasks are the default for recurring work. A scheduled task (formerly "routine") bundles a prompt, a repository and connectors, and runs on Anthropic's infrastructure with no script, server or workflow file. It can fire on a cron schedule, an HTTP POST to its endpoint, or a GitHub event. You create it at claude.ai/code/routines or with /schedule in plain language, such as /schedule daily dependency audit at 9am.
• Scheduled tasks have limits to plan around. They are a research preview, recurring schedules run at most hourly, and runs start from a fresh clone of the default branch and push to a claude/ branch unless the prompt names another. A PR-triggered run starts from the PR's head commit if that repo is listed first. Branch protection or rulesets control pushes, but a rule your connected GitHub access can bypass won't stop it.
• Headless -p mode runs Claude Code as a pipeable one-shot command. It reads stdin, writes stdout, and loads the same hooks, skills, plugins, MCP servers and CLAUDE.md as an interactive session. With --output-format json and --json-schema, the matching object lands in structured_output for jq. Saving session_id lets a later claude --resume carry out a plan with full context.
• --bare gives CI an identical, faster setup on every machine. It skips auto-discovery and leaves Bash, file read and edit, plus whatever --settings or --mcp-config adds. It doesn't use a subscription login, so ANTHROPIC_API_KEY must be set.
• The Agent SDK embeds the same engine inside your own app. The TypeScript and Python SDKs expose a query function with CLI-equivalent options (allowedTools, system prompt, permission mode) and stream messages back. The lesson's guidance is to start with scheduled tasks and move to headless, --bare or the SDK only when the job needs more control.

2026-11-06 · open the original ↗

• Hooks turn rules Claude usually follows into rules it can't skip. A CLAUDE.md instruction is a request, while a hook is code that runs at a fixed point in the loop. Of roughly 30 events, the key ones are PreToolUse (enforcement), PostToolUse (format/lint), Stop/SubagentStop (refuse to finish), Pre/PostCompact, InstructionsLoaded (audit what loaded) and SessionStart.
• PreToolUse returns a decision as JSON, and can rewrite the call. You print JSON and exit 0 with permissionDecision set to allow, deny or ask (defer exists only for -p runs). updatedInput rewrites the call instead of blocking it, but it replaces the whole input object, so unchanged fields must be echoed back.
• Exit code 2 blocks; exit code 1 does not. Exit 0 means success: JSON on stdout is parsed, and plain text is added to context only on SessionStart, UserPromptSubmit and UserPromptExpansion. Exit 2 feeds stderr back to Claude and can even block Stop, while any other code, including 1, is logged and Claude carries on. PostToolUse is too late to stop a call, and Notification and SessionStart ignore blocking.
• Redacting beats blocking for secrets in commands. In the demo, a Bash PreToolUse hook (with a matcher and optional if clause) spots an sk_live_ pattern and swaps it for a placeholder through updatedInput. The command still runs, but the secret never goes through.
• Use SessionStart with the compact matcher to restore context, not PostCompact. SessionStart's output is what gets back into the conversation. A hook that prints a short summary of the working files after compaction lets Claude resume instead of starting cold.

2026-11-06 · open the original ↗

• Pick a permission mode once instead of approving actions one by one. There are six modes. Manual runs reads only, and accept edits adds file edits and common filesystem bash. Plan researches without editing, and auto's classifier can approve its exploration commands. Auto accepts everything after classifier review, don't ask auto-denies anything that would prompt, and bypass skips all checks. Shift-tab cycles manual, accept edits, plan and auto, and the status bar shows the current mode.
• Auto mode's classifier guards intent, watching for escalation beyond the request. It's designed to block production deploys and migrations, force pushes, piping downloaded code to a shell, sending sensitive data out, and irreversibly deleting files that existed before the session. It lets through local edits, lockfile installs, read-only requests and pushes to your own branch. The lesson says its guardrails are still evolving.
• Pair auto mode with a test-running Stop hook, since broken isn't dangerous. The classifier will pass a refactor that breaks authentication. Auto mode checks intent before most actions, and the Stop hook checks correctness after Claude finishes.
• Use don't ask for unattended runs, and confine bypass to isolated machines. Don't ask suits CI, scheduled jobs and overnight batches: reads in the working directories and pre-approved tools run, everything else is denied, and the pipeline never hangs waiting for approval. Bypass is equivalent to --dangerously-skip-permissions and belongs only in an isolated container or VM.

2026-11-06 · open the original ↗

• Build a verification skill first, so checking doesn't rely on memory. Its description triggers it when a change like a refactor finishes. It then runs the tests, reads the diff, confirms no test was weakened to pass, and reports pass or fail with evidence. In the lesson, "done" means the gates were run and observed, not that the code looks right.
• If you've typed a multi-step instruction twice, make it a skill. Release checklists, migration recipes and pre-PR checks fit the same shape. Only skill descriptions load into context until a skill is needed, so packaging procedures costs little. Checking skills into .claude/skills gives the whole team the same checks.
• Keep SKILL.md lean and put depth and tooling in side files. A linked reference.md is read only when needed. Scripts in the folder, such as a check.sh that runs all the gates, are executed rather than loaded into context.
• Each instruction surface owns a different kind of rule. Always-on conventions go in CLAUDE.md, task-specific procedures and references go in skills, and any rule Claude must not be able to skip goes in a hook. The first two are instructions Claude follows, while a hook is code that actually runs.

2026-11-06 · open the original ↗

• A longer CLAUDE.md gets followed less reliably. The file is guidance, not enforced configuration, and every line competes with every other for attention. That's how the file works, not a bug, so the aim is to keep it tight and delete any line you can't justify.
• Hard rules belong in hooks, not CLAUDE.md. A rule like "never push to main" will usually be respected but isn't guaranteed. A pre-tool-use hook can actually block the action, so CLAUDE.md should keep only softer conventions.
• Four CLAUDE.md locations all load and stack at launch. Managed policy (org-controlled, can't be excluded), user (personal, across projects), project (checked in and shared) and local (git-ignored, this repo only). Local is the place for personal context such as architectural decisions on your own refactor branch.
• @path imports organize a file but don't shrink the context load. Imports such as @.claude/conventions/testing.md are expanded inline at launch, so everything still loads up front.
• Specific, checkable phrasing and a small emphasis budget make rules stick. "Put new API routes in src/api/handlers, one per file" beats "follow best practices." Bans should name the replacement ("Use named exports, not default exports"). "IMPORTANT" works only relative to quieter rules, so save it for the two or three that hurt most, and treat each mistake as a bug report against the file. You can tell Claude to add the rule itself.

2026-11-06 · open the original ↗

• Read the plan closely before Claude starts editing. Plan mode researches without editing source files and returns a plan. Reading it properly and iterating on it is faster than letting Claude run and cleaning up afterward.
• Tell /compact what to keep, or the summary may drop it. Compaction replaces old messages with a summary, and anything lost can send Claude off course. Instructions after the command shape the summary, for example /compact Focus on the --version flag implementation.
• Rewind to a checkpoint instead of prompting your way back. Every user prompt is a checkpoint, and double-tapping Escape on an empty prompt opens the menu. You can restore code and conversation, either one alone, or summarize from or up to a checkpoint to compress a side conversation or a long setup phase.
• /goal and /loop let Claude run with less steering. /goal keeps Claude working until a fast evaluator confirms the condition, e.g. "all tests in src/billing pass, and the type checker reports zero errors." The evaluator reads only the transcript, so the condition must be visible in output, and /goal clear cancels it. /loop repeats a prompt on a fixed or self-paced interval to poll things like CI. Escape stops a self-paced wait, and a fixed loop runs until cancelled or for seven days.
• Give parallel sessions separate worktrees so they can't clobber each other. Each agent gets its own file tree, and a clean worktree is removed automatically when its session exits. A .worktreeinclude file at the repo root lists git-ignored files, such as an env file, to copy into each worktree.

2026-11-06 · open the original ↗

• Practice on one real, waiting task this week. The final assignment is to pick something concrete, such as a grant application, a donor report, program data or a policy update, and do it with AI support. Afterward you reflect on what worked and which competencies need more practice.
• Work through all four Ds, going back to earlier ones as needed. Delegation sorts AI work from human judgment and, per the video, picks a platform that meets the task's privacy needs. Description sets out the organization's context and how AI should work. Discernment evaluates and refines the result, and Diligence means owning it and disclosing AI's role where knowing it would change someone's view of the work. The lesson stresses this is a loop: discernment can send you back to delegate differently.
• Use the blueprints and supporting resources as guides at first. Anthropic's use-case library has step-by-step guides for grant writing, donor communications and data analysis, alongside the 4D Framework guide and a terminology cheat sheet. The AI Fluency: Framework & Foundations course goes deeper, and the completion badge is meant to start conversations about AI fluency within your organization.

2026-11-06 · open the original ↗

• For nonprofits, "human in the loop" means AI serves the mission. Beyond steering each interaction, the human decides which problems AI should solve, judges whether solutions fit the organization's values, and keeps the relationships and real-world impact the work depends on.
• Guard against dependency by being able to explain what the AI does. The video's reasoning is that AI isn't programmed like a CRM and gives a different response each time, so judgment is needed on every use. The test to apply regularly is "can we explain what the AI is doing?" If yes, it's healthy augmentation. If not, rework the process. The goal is not zero dependency but decisions that make the organization stronger.
• Use AI to make room for human touch, not to remove it. At its best AI clears noise so staff have time for the handwritten card or time with a community member. At its worst it automates that away. The video advises setting norms early about productivity expectations and what happens to the time saved.
• An AI policy spreads these judgments across the organization. The exercise structures the policy in six parts: platform awareness (allowed and prohibited tools, acceptable retention and training), task delegation (what stays fully human, who approves new uses), expectations and capacity (redirecting saved time, building skills beyond one "AI expert," what happens when workflows fail), quality and oversight, transparency to funders and those served, and values alignment, including when not to use AI. AI then helps compile the answers into a draft for the team to review.

2026-11-06 · open the original ↗

• Audit your actual workload before automating anything. In the hypothetical, Emily, a development coordinator three weeks from a cancer-research fundraising gala, gets 20–30 near-identical emails each morning and spends two hours (about 10 hours a week) answering them. Reviewing a week of her inbox shows a handful of recurring question types.
• Delegation asks whether AI should do a task, not whether it can. Receipt requests, documented event details (dress code, parking, schedule) and step-by-step processes go to AI. Ticket transfers (high risk if done wrong) and complaints (which need empathy and context) stay with humans. Because the work exposes identifying and funding information, she uses a tool that doesn't train on user data.
• Define the system precisely, then test it on real emails. The product is a Gmail-connected Claude setup that reads, categorizes, and drafts replies or flags messages for review. The process is to categorize, check whether the information is available, then reply or create a task. Performance means warm but professional, never guessing, and flagging when unsure. Testing showed correct categorization, but one shellfish-allergy reply oddly asked the sender to confirm what they'd already said, so she made the performance description more action-oriented.
• Apply creation, deployment and transparency diligence before going live. Creation diligence means deliberately choosing what to automate to protect donor relationships. Deployment diligence means she still reviews and sends every reply, so any later full automation rests on testing. Transparency diligence means the emails, following her organization's policy, say they're system-generated, explain why, and offer follow-up options.

2026-11-06 · open the original ↗

• Earn trust in AI analysis by re-running an analysis you've already done. The delegation–diligence loop takes a recurring task and past data with known answers, has AI reproduce the result, then refines and retests. If AI matches the known results, the approach can be reused. If several rounds of refinement can't get there, the task shouldn't be delegated.
• Testing shows which gaps more context fixes and which are real limits. Rio, program director at the hypothetical Valley Veterans Services, tested on last quarter's raw attendance and employment data. AI found the attendance–placement correlation but missed the combined housing-plus-job-placement program until he asked it to consider program type, which became a standing instruction. For enrollment cohorts, it tried to infer missing dates, so he noted that enrollment dates must be supplied and results cross-checked.
• People who aren't data-savvy can treat AI like a team analyst. It can suggest approaches, write Excel formulas and reformat messy data. The lesson's caveat is to keep asking for explanations until you understand both the process and the output.
• A validated approach still leaves you accountable for the results. On new data Rio still checks that the numbers fit what he knows about his programs, owns the report, and says how AI was used if asked. The same test-first method is suggested for donor analysis, budget forecasting, survey synthesis and outcome tracking.

2026-11-06 · open the original ↗

• Judge AI tools like other software, with one extra question: training. Email, CRMs and spreadsheets all have storage, retention and access rules, and AI can be assessed the same way, except for whether inputs train future models. The video says training almost never reproduces an exact copy of your data, but it can surface patterns, themes or statistics from it in answers to other users.
• Match the tool and plan tier to how sensitive the data is. Providers and tiers differ, and third-party tools with AI features may pass data back to an AI provider. The safest setup doesn't train on inputs and keeps data for a short window, usually 30 days or less, or not at all (zero data retention). That matters for sensitive work, not casual brainstorming. Claude's policies are at trust.anthropic.com plus a privacy site (privacy.anthropic.com on the page, privacy.claude.com in the video), and training can be turned off in the app. A provider without such resources is a red flag.
• Work back from the goal to strip data you don't need. In the video's food bank example, a client survey with names, contact details, income and employment status is analyzed for patterns across clients, so identifying columns can simply be deleted, or reduced to something like zip codes for geographic analysis. The analysis still gets done with far less risk. Pasting the terms and privacy policy into AI and asking for citations is suggested as a way to read them.
• Verify the findings and disclose AI's role before using results. Deployment diligence means checking the patterns against your own observations, and transparency diligence means deciding who needs to know AI was involved. Claims in any grant or report built on the analysis are yours to own.
• If you share something by mistake, there are clear steps. Delete the conversation, request data deletion through the provider's privacy process for serious cases, and follow your organization's data-handling protocol, as you would for a misdirected email.

2026-11-06 · open the original ↗

• A rich first prompt plus your past work yields an authentic draft. In the hypothetical, an ice storm topples over 15,000 Detroit trees and the city's Office of Sustainability offers $50,000 emergency grants, with proposals due in 48 hours. James of the eight-year-old Green Detroit Coalition asks for four sections in 1,000 words (product), has AI learn the group's voice from past proposals and its mission one-pager (process), and asks for a confident, data-driven, resident-centered tone that defines environmental justice as power-sharing (performance).
• Uploaded examples and context tools are what give AI your voice. The lesson calls supplying past work and style essential for high-quality writing, and points to Claude's projects, connectors and styles, or other tools' equivalents.
• Review the draft for facts, voice, values and false assumptions. In James's first draft, the capacity section undersold existing community relationships, and the timeline skipped community input before choosing planting sites, which the video calls a process error. The page's exercise adds checking for deficit-based framing of beneficiaries and whether the draft speaks to the funder's priorities.
• Revise with specific requests, then finish the proposal yourself. "Add these specific details about our community relationships" works better than "make this more compelling," and only you can supply track record, partnerships and staff expertise. The back-and-forth builds what the course calls a cognitive environment. James delegated only the first draft and did the final touches himself, so he can stand behind every word.

2026-11-06 · open the original ↗

• Context-rich prompts get actionable research; generic ones get generic answers. In the hypothetical, Maria, executive director of a 15-year Portland shelter and transitional-housing nonprofit, is researching expansion into Seattle. Instead of "tell me about Seattle housing policy," she specifies the deliverable (an overview of assistance programs, legislation, compliance and funding), the approach (changes from the last two years, income thresholds, comparisons with Portland), and a practical, mission-focused tone. The video suggests dictating or uploading material to supply context faster.
• Polished research output still has to be checked critically. Maria's checklist covers whether program names are accurate, sources are legitimate, claims are verifiable and specific, anything expected is missing, and the tone fits. Specific numbers, recent legislation and active programs get flagged for primary-source checks (product discernment). She also asks whether AI actually looked for current information or just guessed (process discernment).
• Refine the response rather than discarding it. Her follow-up points out that many sources are news articles, asks for confirmation from official government sites, and asks where the funding deadlines came from. AI may then search for sources or admit uncertainty, either of which narrows things toward reliable information.
• AI gets you oriented faster, but judgment and accountability stay with you. Before the findings go into a funding proposal or outreach, Maria verifies them and owns the result.

2026-11-06 · open the original ↗

• Delegation decides what work goes to humans and what goes to AI. It has three parts: problem awareness (is a donor thank-you just an acknowledgment, where boilerplate is fine, or relationship-building that needs a human touch?), platform awareness (such as privacy protections when donor data is involved) and task delegation.
• Diligence means owning how AI is used and what it produces. It covers creation diligence (deliberate choice of tools and of which parts AI works on), transparency diligence (boards, funders and beneficiaries deserve to know when and how AI was involved) and deployment diligence (verifying every statement and vouching for the final result). Delegation and diligence form a loop, with responsible practice informing later delegation choices.
• Description goes beyond prompting to build a working environment. Product description sets the output, format, audience and style. Process description sets the approach, like briefing a junior colleague. Performance description sets how AI should behave, for example as a critic, a cheerleader or a skeptical audience.
• Discernment means evaluating and iterating, not just accepting or rejecting. Product discernment asks whether statistics are accurate and the language matches how beneficiaries describe themselves. Process discernment asks whether AI made assumptions about the community that don't hold. Performance discernment asks whether it's giving useful suggestions or just generating content. Describing and discerning repeat like a conversation with a human collaborator.
• The four Ds work together to sharpen human work, not replace it. In an impact report, delegation splits the work, description guides it, discernment checks it, and diligence runs throughout. The stated aim is more effectiveness in work that needs human judgment and deep knowledge of the community.

2026-11-06 · open the original ↗

• Nonprofit enthusiasm for AI far outpaces meaningful use of it. The presenters, from GivingTuesday's partnerships team and Anthropic's education team, report from conversations with thousands of nonprofit professionals that only a handful of enthusiastic organizations have achieved meaningful implementation. They promise practical, community-informed lessons rather than "magic prompts."
• AI fluency means using AI effectively, efficiently, ethically and safely. It's framed as a mix of skills, knowledge, insight and values that adapts as the technology changes, so you can judge whether, how and how far AI should support a given challenge.
• The 4D Framework underpins the course and works as two loops. Created by professors Rick Dakan and Joseph Feller, it covers Delegation, Description, Discernment and Diligence. The delegation–diligence loop governs when and how to use AI and owning those choices. The description–discernment loop governs back-and-forth collaboration.
• Every efficiency gain should turn into more impact for the community. The question to ask is "should AI do this, and how does it advance our mission?", not just "can it?" The opening exercise turns this into practice: use AI to interview you and build a reusable context document about your organization's mission, role, constraints and goals.

2026-11-06 · open the original ↗

• Practise the full 4D sequence on one real task this week. Before opening a laptop, decide what part needs you and which tool suits the data. Then describe your business, customers and voice; check prices, tone and plausible-but-invented details against what you know; and only use output you can vouch for, disclosing AI's role where it matters. The lesson stresses this is a loop, not a line.
• Discernment is where time savings hold up or fall apart. For a small business, the lesson says, the owner's own expertise is the check on whether output is accurate and sounds like them.
• Keep a running record of prompts and workflows that work. The course points to Anthropic use-case "blueprints", the Framework & Foundations course, and a shared doc so teammates don't start from scratch. The page also notes the FTC is developing guidance on AI-generated marketing, reviews and customer communications, and that state privacy laws keep changing.

2026-11-06 · open the original ↗

• Being the human in the loop means setting the problems. Corey of Prospect Butcher defines the role as deciding what AI should solve, judging output against organizational and professional standards, and keeping the domain expertise AI can't replicate.
• Dependency is avoided through understanding, not avoidance. Because AI is non-deterministic, validating it once isn't enough. The test is whether you can explain what the AI is doing and why you're using it; accepting output because "AI is usually right", or sending a draft because it reads well, signals over-dependence.
• Faster output brings faster expectations that erode care. In the lesson's example, an owner whose AI proposal drafts save an hour per quote trades accuracy for speed once she stops checking pricing and scope.
• An AI policy turns individual judgment into team norms. Suggested areas: approved platforms, task boundaries and gray areas, who reviews output and what validation is required, disclosure to regulators, customers and partners, and how saved time is used. Settling that last one early is meant to prevent the "do more with less" trap.

2026-11-06 · open the original ↗

• Delegate aggregation and arithmetic; keep every payment decision. Corey, co-founder of Prospect Butcher Co. (a worker-owned whole-animal butcher with two Brooklyn locations), uses AI to pull invoices from two billing systems, flag vendor follow-up emails, read sales velocity and model cash. Final payment calls, vendor conversations, disputed invoices and one-off purchases stay with him. He chose a tool that doesn't train on his data, because the data includes vendor banking details.
• The system is specified by output, logic and behaviour. Every Monday it produces a payment-run recommendation: a snapshot of outstanding invoices and cash, a vendor-by-vendor breakdown with suggested amounts, and a cash flow forecast after payroll. It ranks urgency using payment terms, vendor follow-ups and cash position. It frames everything as a recommendation with reasoning, accounts for rent and credit cards outside the billing platform, and does not generalize from typical businesses.
• Back-testing against past months caught two serious errors. The system counted already-paid invoices, overstating what was owed by about $18,000, which could have led to double-paying vendors. It also put the largest invoices first, which meant the farms, when the pushier non-farm vendors chasing invoices like $600 needed attention. Two describe-check-adjust rounds fixed the status filter and rewrote the prioritization.
• Trust is earned through data, and the human submits payments. Corey still reviews every run, because overpaying risks payroll and missing someone risks a relationship. He was upfront with co-founder Greg, saying the savings go to staff and customer experience.
• The payoff is consistency more than time saved. Two to three hours scattered across evenings became a focused 45 minutes on Mondays. Corey says on-time weekly payment to small family farms matters more than the time recovered.

2026-11-06 · open the original ↗

• Customer-facing AI needs guardrails, or it will invent things. Mak's company handed phone support to AI after call volume grew beyond what staff could answer. A first "glorified voicemail" version made customers angrier, and without guardrails the system twice gave customers a made-up address.
• Telling callers upfront what the AI can do increased adoption. A generic "How can I help you today?" greeting frustrated callers. Introducing itself as MAKS Virtual Assistant, listing what it can handle, and offering a human after one reminder worked better, especially for callers wary of AI. Mak says forcing AI on people was where problems started.
• Using the AI's own call analysis to find frustrations drove improvement. Mak recommends asking the system to analyse its calls for points of frustration and adjusting in repeated rounds. He reports about 50% of calls are now handled by AI, with most callers happy.
• Judgment, relationships and management stay human. AI helps with supply and pricing data, but a supply chain manager still deals with vendors, and Mak sees no foreseeable point where AI runs without human oversight.
• Protect data first, and test AI against known answers before delegating. The lesson advises stripping names, addresses and contact details before uploading even to privacy-protective tools, and reading the tool's terms. Then rerun past tasks whose answers you know and compare. If accurate results can't be validated after several tries, don't delegate the task.

2026-11-06 · open the original ↗

• Domain-specific context turns generic output into useful analysis. Mak, CEO of MAKS Enterprises TIPM Rebuilders (automotive electronic modules, sold on eBay, Amazon and its own site), tells the AI which five channel-specific part numbers all mean a 2011 Caravan, so it can combine sales data across channels for meetings. A bare "do a market analysis" request, he says, gets a generic answer.
• Check AI output against data you already trust. Mak's team feeds the AI their own data and then compares results with known figures, such as actual sales in a channel recorded on a separate spreadsheet.
• AI-drafted SOPs save huge time but still need review. SOPs used to take engineers a painstakingly long time to write. Mak now talks a procedure through with the AI and gets a draft "within a minute", but always reads it and finds things to tweak. He says output gets tighter as he shares more company information.
• The loop is iterative, and the owner still decides. The lesson's own conclusions: a first prompt rarely gets all the way there; upload product histories and SKU mappings whenever possible; and flag claims for checking, because the owner is usually the only one who can spot the mistakes.

2026-11-06 · open the original ↗

• Three developments converged to make modern LLMs possible. These were the 2017 transformer architecture, the explosion of digital training data, and big gains in compute (GPUs, TPUs, clusters). Scaling laws showed performance improving predictably with size, and abilities nobody programmed, such as step-by-step reasoning, appearing as models grew.
• Training turns a document completer into an assistant. Pre-training on next-text prediction produces "a very competent, literal document completer". Fine-tuning with human feedback and reinforcement learning then teaches it to follow instructions and avoid harm. A prompt is continued from learned patterns, not looked up in a database.
• Strengths: versatility, conversational memory and tool use. One model switches between tasks without retraining, keeps track of earlier points in a conversation, and can increasingly search the web, process files or use other applications.
• Each limitation traces back to how these systems work. The lesson lists knowledge cutoffs (e.g. a November 2024 cutoff means no later data), hallucinations from unverified training data and statistical generation, a context window that drops content first-in-first-out, non-deterministic output (adjustable via "temperature"), weakness on multi-step reasoning (improving with extended-thinking models), and no access to data or tools it hasn't been given.
• The best results pair human judgment with AI speed and scale. Humans contribute critical thinking, creativity and ethical oversight; AI contributes pattern recognition and volume. The lesson expects some limits to remain even as retrieval-augmented generation and tool use improve, without knowing which ones.

2026-11-06 · open the original ↗

• Good Description covers the output, the method and the AI's role. Beyond output, format, audience and style ("summarize for a non-technical executive audience, three highest-impact findings, under 300 words"), you can specify the steps it should follow and the stance to take: critical reviewer, brainstorming partner, or fact checker.
• Discernment is the rarest skill and the biggest gap. In Anthropic's research, Description behaviours came most naturally, while questioning AI's reasoning, checking facts and spotting missing context were among the least common behaviours observed. Discernment means iterating, not just accepting or rejecting output.
• Delegation requires understanding both the work and the tool. A routine status update can take an AI first draft; a sensitive negotiation needs the person's own tone. Confidential data calls for checking the tool's privacy and security features first.
• Diligence means transparency and full accountability for the result. That covers choosing systems deliberately, telling colleagues and stakeholders when AI was involved, and checking every claim before sharing. The lesson says diligent practice in turn sharpens later Delegation decisions.

2026-11-06 · open the original ↗

• Casual AI use and real time savings are far apart. The presenters, Kristen (Anthropic education team) and Brian (PayPal product partnership innovation), say conversations with thousands of small business owners show that closing that gap takes a more deliberate approach, not "magic prompts" or one-off demos.
• AI Fluency rests on four linked competencies, run as two loops. The 4D Framework (Delegation, Description, Discernment, Diligence) is credited to professors Joe Feller and Rick Dakan with Anthropic. The Delegation-Diligence loop covers whether and how to bring AI in and staying accountable for it; the Description-Discernment loop covers getting better output through back-and-forth.
• A small business owner's name is on every output. With no legal or PR layer between owner and customer, the course says the question is not just "can AI do this" but "should it", and whether the result sounds like the owner, is accurate about their services, and holds up if a customer pushes back.

2026-11-06 · open the original ↗

• Apply the full 4D cycle to one real task this week. Kristen (Anthropic) and Chris (chief product officer at CodePath) suggest a long-requested feature, an unrealized prototype, or unsynthesized user feedback. Delegate implementation, scaffolding, boilerplate and first-draft specs; keep the judgment on who the user is and whether it's the right thing.
• Describe the full chain before writing a prompt. Go from user voice to requirement, spec, AI instruction and tests, knowing what done looks like and what a success test measures. Then check output through the five Discernment questions, since AI may build what was described but not what solves the problem.
• Prototype freely, ship selectively, and veto your own work when needed. Before shipping, ask whether you understand and can explain it, and whether you'll know if it's working. Sunk effort is hard to walk away from, but the lesson says the builder's job is to serve the user, not defend the software.
• The 4Ds are dynamic, not a fixed sequence. Moving from Description to Discernment and then rethinking Delegation is what the course calls fluency developing. It predicts the builders who do the most interesting work will be those who know when to stay in the loop, not those who automate the most.

2026-11-06 · open the original ↗

• You own the outcome, including code you didn't write. Martina, an Anthropic engineer, describes Diligence as catching up to your own code: understand it, stress it, test it. The page adds that "AI wrote it" explains and excuses nothing.
• Deliberately surface the decisions AI made silently. Writing code yourself exposes edge cases as you go; with AI they may get decided unseen. Martina asks targeted questions ("can users view other users' files?") and, after substantial work, "What assumptions and trade-offs did you make?" and what security risks to know about.
• Disclose AI authorship in pull requests as information for reviewers. It isn't meant as a disclaimer. AI makes a different shape of mistake from humans: deprecated APIs used confidently, code that is locally clean but inconsistent with the codebase, and invented behaviour for unspecified cases. Reviewers who know can target those.
• Understanding AI-built code is now a separate step. Working code you don't understand is newly possible. Martina's answer is to have the model explain it patiently, which takes time but puts you back in the loop.
• Pre-AI engineering practice matters more now, not less. Because you ship faster and understand a smaller fraction of what you ship, tests pin down behaviour so you can keep changing things. Logs, error tracking, dashboards and feature flags mean problems show up in your own data, not a user's email. The page also lists migrations, versioning and rate limits as things AI won't raise unless asked.

2026-11-06 · open the original ↗

• When implementation is fast, experience becomes the differentiator. Builders needn't become designers but must recognize good experience, spec for it and iterate. The principles: clarity that matches users' mental models (a wait-time checker should work like other status checkers), hierarchy and progressive disclosure, and feedback through loading states, confirmations and plain-language error messages.
• Accessibility is a baseline AI won't deliver by default. The lesson says to request screen-reader compatibility, colour contrast and keyboard navigation explicitly every time, and to build test cases that check them.
• "Make it look good" is a wish, not a spec. An actionable version: put the wait time in the largest text on the page, use a single colour for status, and show the refresh time so the patient knows how stale the number is.
• A critique for a colleague isn't an instruction AI can execute. "This feels cluttered" is fair feedback but useless to AI. Design literacy includes translating your own taste into executable descriptions within the describe-evaluate loop.

2026-11-06 · open the original ↗

• Functional integrity is necessary but where most review wrongly stops. The first lens covers bugs, errors and security holes across unit, integration, regression, edge-case and end-to-end tests. The lesson says AI should write tests in the same pass as the code, with regular checkpoints, because an unrun test suite is "a false sense of security".
• AI has predictable blind spots in production readiness. These include load, concurrency and slow dependencies, such as hundreds of simultaneous refreshes or an API call five seconds late. Suggested moves: have AI stress-test its own output, generate production scenarios, and answer "What production assumptions does this code make?"
• AI solves the stated problem, not necessarily the real one. A patient asking about wait times may really need to know whether a pediatrician is free in the next 20 minutes to judge a child's fever. Checking problem fit is the builder's job.
• AI has patterns, not taste. It produces a competent interface no one enjoys using. For a clinical tool, the lesson says, that is a patient-safety issue, not just an aesthetic one.
• Historical training data can carry bias into a displayed number. If past wait times reflect systemic inequities by demographic, the estimator may reproduce them without flagging it. The lesson advises guardrails, asking AI to name its biases, and questioning every assumption, adding that the biggest problems are almost never at the first lens.

2026-11-06 · open the original ↗

• Description is a four-step chain, and prompting is one link. It runs from user voice ("I want to see wait times before I go") to a measurable product requirement (mobile-friendly webpage, estimated not exact, refreshed every five minutes) to a technical spec (web app polling a clinic API with a responsive UI) to the AI instruction (stack, data shape, no-data behaviour, tests to pass).
• The builder carries context the user never says. AI can't know the user has waited two hours with a kid in the car, or that exact times would make staff anxious about being held to them. Every scoping word is a judgment call the builder must carry intact to the AI.
• Working code with an unhappy user is a Description failure. The fix is forensic: trace whether the break was in understanding the user, scoping the requirement, translating to spec, or the prompt itself. The lesson says it usually lives upstream of the prompt.
• Tests are the most precise form of description. A test either passes or fails, so handing AI tests with the prompt tells it how success will be judged, which changes what comes back. A passing test with a frustrated user means the test described the wrong intent, which the lesson calls the most useful result of the exercise.

2026-11-06 · open the original ↗

• The hard part is knowing what code you want. The lesson casts the builder as a project lead and AI as the team. The lead frames the problem, sets what good looks like, orders the work and decides which calls to keep, all before any code is written.
• AI is strongest mid-toolkit and weakest at the edges. Of the builder's six capabilities (empathy, design, architecture, implementation, judgment, shipping), implementation should be delegated most aggressively, and architecture suits human-plus-AI work. AI can only generate options for design, and empathy, judgment and shipping stay human. In the lesson's example, AI can't notice that a clinic receptionist checks her phone 40 times a day because patients keep calling about wait times.
• Write acceptance tests before code to define done. Reaching implementation without defined tests and success checkpoints means a step was skipped. The page's example: "A patient with a basic smartphone can find the current wait time in under 30 seconds without creating an account", not "the system is easy to use".
• Faster implementation moves the builder's value to framing problems. Skipping empathy and design work as overhead is the temptation to resist. The lesson predicts the builders who thrive will be those who frame problems clearly and can tell "code that runs" from "code that matters", not the fastest prompters.