AI Fluency for Builders
For product people, designers, and makers who own the full arc from customer problem to shipped solution. Two axioms carry this edition: delegating implementation is usually safe, delegating judgment is usually not. And most AI failures trace back to description, discernment, or diligence failures made earlier.
- Delegate implementation freely; keep empathy, judgment, and shipping
- Trace product failures up the description chain
- Evaluate code through the five lenses, from run-it to judgment-only
- Run the pre-deploy diligence gate before anything ships
Welcome, and the builder brief
Builders sit in an unusual position with AI: it can now produce in minutes what took your team days, which means the scarce skill is no longer producing. It is knowing what to produce, judging what got produced, and standing behind what ships.
Before anything else, write a reusable context document you will paste into AI collaborations. Four sections:
- What you are building and for whom.
- Your role and what you personally own.
- Constraints, including your stack and your non-negotiables.
- Where AI is wanted in your process, and where it is not.
Then complete the sentence: "If AI could handle ___, I could spend more time on ___." That sentence is your delegation compass for the whole course.
- Implementation is delegable; judgment is not.
- A written brief beats re-explaining your world in every conversation.
The two loops
The 4Ds organize into two loops. The inner loop, Description and Discernment, guides your daily interactions: tell the AI what you need, judge what comes back, refine. The outer loop, Delegation and Diligence, guides the bigger decisions: whether AI belongs in this work at all, and how you own the result.
Go back to your builder brief and tag each item with the competency it exercises. The one that shows up most is where your attention is already focused, and usually where you will see the fastest gains.
- Inner loop for the day-to-day; outer loop for whether and how much.
Capabilities and limitations, builder tests
The machine-side properties (prediction, knowledge, working memory, steerability) are covered in full in AI Capabilities and Limitations. Here is how a builder tests them on their own ground:
- Versatility test. Ask the AI to explain your system three ways: to a product manager, to a mid-level engineer, to a senior reviewer. Did the depth actually shift, or just the vocabulary?
- Hallucination test. Ask it to recommend libraries for a real need, then spot-check that each exists, that the API it described is real, and that the version is current.
- Cutoff and reasoning test. Ask about a recent deprecation in your stack. Did it resolve the confusion, or just restate the answer more confidently?
Run the same topic through a second AI tool and compare the error patterns. Different tools fail differently, and knowing your tools' habits is platform awareness in practice.
- Test capabilities on your own system, not on toy examples.
- Library recommendations are a hallucination hotspot: verify existence, API, and version.
Delegation and the builder's toolkit
The wrong question is "should I use AI here?" The right question is "I have a customer problem; how do I break it down, and what role does AI play in each part?"
Think of building as six capabilities, ranked by where AI is strong:
- Empathy. AI is weak here. It can surface data and personas; it cannot feel the gap between what users say and what they mean.
- Design. AI assists; taste stays yours.
- Architecture. AI advises well when you supply constraints.
- Implementation. AI is strongest here. First drafts of working code are the safest large delegation you can make.
- Judgment. Yours. What to build, whether it is good, whether it ships.
- Shipping. Yours: the accountability cannot be delegated.
Write acceptance tests before code; they give you and the AI a shared definition of done. And as AI accelerates implementation, your value shifts to framing problems and raising the bar.
A local clinic wants patients to see expected wait times. Deliberately write zero code in this lesson. Produce three artifacts:
- A problem brief: which patients, what outcome, what does great feel like?
- A delegation plan mapping the six capabilities to automation, augmentation, or agency.
- Five to seven acceptance tests a stranger could verify. "Shows the wait in under 30 seconds without creating an account" is a test. "Easy to use" is not.
- AI is strongest in the middle of the toolkit; empathy, judgment, and shipping stay human.
- Acceptance tests first: a shared, verifiable definition of done.
The description chain
Prompt engineering is only one link. The full chain runs: user voice → requirement → technical spec → AI instruction, and the builder is the translator at every step. AI cannot hear what the user did not say; only you were in the room.
The diagnostic that follows: code that works but a product that does not is a description failure. Find which link broke upstream. Did the requirement mistranslate the user? Did the spec mistranslate the requirement? Did the prompt mistranslate the spec?
- Tests are the most precise form of description. A passing test with an unhappy user means you described the wrong intent.
- Every adjective should be a decision you can defend. If you write "fast," write how fast.
Build the smallest slice of your clinic project with AI, then hand it to a partner playing the patient. Do not explain anything. Do not help. If your test results and their satisfaction diverge, trace the chain and find the broken link.
- User voice, requirement, spec, instruction: four links, and you translate at each.
- Adjectives are decisions; make them defensible numbers where possible.
Discernment for code
When AI can spin up a working product in minutes, "working" stops being the bar. Evaluate through five lenses, ordered from run-it-and-see to judgment-only:
- Functional integrity. Does it work on real inputs? The common AI failure: passes unit tests, breaks on data the prompt never covered.
- Production readiness. Error handling, logging, performance under load, security posture.
- Problem fit. Is this even the right solution to the actual problem?
- Experience quality. Would someone want to use it? Functional but confusing, slow or graceless is an experience-quality failure.
- Responsible impact. Who could this harm, exclude, or mislead?
AI has predictable blind spots in concurrency, security, and anything that only breaks at scale. And taste is a builder skill: AI delivers functional; making it worth using is on you.
A reflection worth sitting with: when the output is not good enough, is your instinct to fix it yourself or to describe it better? The second instinct scales; the first one does not.
AI-written code passes every unit test, then crashes on the first day of real customer data. Which lens failed?
Passing unit tests while breaking on data the prompt never covered is the classic AI failure of functional integrity. Real inputs are the test that counts.
- Five lenses: functional, production, fit, experience, impact.
- Concurrency, security, and at-scale behavior are the standing blind spots.
Discernment for user experience
When implementation is fast, experience is the differentiator, and "make it look good" is a wish, not a spec. Evaluate AI-generated interfaces against four principles:
- Clarity. Does the user instantly know what this screen is for?
- Hierarchy. Does the eye land on the most important thing first?
- Accessibility. AI does not get accessibility right by default. Specify it, then audit what you get back: contrast, focus order, labels, keyboard paths.
- Feedback. Does every action visibly acknowledge itself?
One more skill: a good critique and an actionable AI description are different artifacts. "The hierarchy is muddy" is a critique. "Make the wait time the largest element, demote the clinic logo, and move the refresh action below the fold" is a description. Learn to translate between them.
- Clarity, hierarchy, accessibility, feedback: audit all four on anything AI-designed.
- Translate critiques into concrete, actionable descriptions.
Stand behind what you build
You own the outcome, not the output. "AI wrote it" explains nothing and excuses nothing. Diligence for builders is a gate you run before anything ships:
- Understanding. Can you explain what it does, not what it should do?
- Testing. Have the edge cases been exercised, not just the happy path?
- Access. Who is not served? Check who your assumptions exclude before you call something shipped.
- Responsibility. Misuse potential considered, AI's role disclosed where it matters.
- Feedback loop. How will you know it is working after ship?
Also: shipping has its own technical vocabulary, migrations, versioning, rate limits, feature flags, that AI will not surface unless you ask. Prototype freely, ship selectively. And the underrated skill nobody teaches: deprecating your own work well.
- The pre-deploy gate: understanding, testing, access, responsibility, feedback loop.
- Prototype freely, ship selectively.
Closure
AI is strongest in the middle of the toolkit. Delegate implementation freely. Keep empathy, judgment, and shipping in your hands. And remember the 4Ds are dynamic, not a sequence: moving fluidly between them as you build is what fluency looks like in practice.
Pick a task that has been waiting: a feature request you have dodged, user feedback you have not synthesized, a spec you have not written, a corner of the codebase you are scared to test. Run it through all four Ds this week.
Course quiz
Attribution. Adapted from the AI Fluency courseware developed in collaboration with Anthropic, CC BY-NC-SA 4.0. This adaptation © 2026 AI Literacy Foundation, shared under the same license.