Using AI Well

This is for everyone using AI as part of the work: thinking through a problem, drafting a doc, writing code, or sending something to someone else.

It is built as a kernel: what is actually going wrong, the policy we chose, and what we do because of it.

The diagnosis: AI can think for you if you let it#

AI is easiest to use as a shortcut around your own thinking, not as a tool to sharpen it.

Bad, and this is a mistake everyone here has made: a PM pastes “design a way for customers to pause their subscription” into AI and ships the first answer, a self-serve pause button, as the plan. Three weeks later support is drowning in refund requests, because the one thing the PM knew from sitting on client calls, that pausing mid-cycle without prorating feels like theft to half these customers, never made it into the prompt. AI never got the chance to design around it, and neither did anyone else before it shipped.

Andrej Karpathy calls the underlying shift “Software 2.0”: as neural networks become the primary implementation medium, the job moves from writing the code yourself to specifying intent and judging the output. That only works if you actually do the judging. Skip forming your own view first, and there’s nothing left to judge the output against, so AI ends up doing both halves of the job instead of one. You are the brain. AI is the workhorse. That division only holds if you’re doing the brain part.

The tell: if you can’t say what you think before you open a chat with AI, you’re not using it, you’re asking it to decide for you.

The policy: think first, then let AI sharpen or check it#

Use AI to think more, never to think less: nothing leaves your hands, a decision, a doc, a message, a diff, unless you checked it yourself first.

Three things this rules out:

Reaching for AI before you’ve formed your own take. The answer that comes back becomes AI’s framing of the problem, not yours, and you can’t tell the difference from the inside.
Accepting an output because it sounds right. Sounding right and being right are different, and only one of them is checkable against what you actually know.
Sending someone something you haven’t personally verified. Your judgment doesn’t transfer to a document just because the words did, and handing it over anyway is disrespectful: you’re asking for their time on something you didn’t spend yours on.

The exception, and it’s a real one: exploring something you have no prior knowledge of at all is a legitimate use of AI, arguably one of the best. You can’t form a first take on a domain you’ve never touched. The rule still applies once you’re deciding, sharing, or acting on what you learned: treat what AI told you as a lead, not a fact, until you’ve checked it against a real source. The less you knew going in, the more that check matters, not less, because you have no independent way to catch it being wrong.

Taste is what you’re checking with#

Checking isn’t enough on its own. You also need to know what “good” looks like, well enough to tell output that’s merely competent from output that’s actually great. That built sense is taste, and it’s what makes you notice “this feels off” before you can say why. You build it the same way you’d build any other judgment: ship, watch what actually worked, and when you miss, ask why your gut was wrong that time.

Define “good” before you check for it, or your checklist defines it by default. A bar two people would score differently isn’t a bar, it’s a mood. Release notes already have one: the Before block names the real failure a customer hit, not the happy path, both blocks the same shape, real values instead of a summary. That’s checkable. “Make sure it sounds good” is not.

Taste also goes stale on the fifth read. Read the same output enough times and you stop reading it, you start remembering it, so the gap you’d have caught cold on a first pass is gone. If a check keeps missing something that surfaces later, more scrutiny on the same tired read won’t fix it. Close it, come back in an hour, or hand it to someone who hasn’t seen the prompt, then check again with eyes that are actually reading it.

Form your view first#

Use AI before you talk to anyone, but after you’ve tried to answer it yourself. Write down what you think first, even three lines. Then open a conversation with AI and pressure-test it, not generate it from scratch.

For PM: Drop your problem statement in and ask: what’s weak about this? What assumption am I making that could be wrong? What questions would a skeptic ask? This is not about getting AI to validate you. It’s about finding the gaps before someone else does.

For PD: Before presenting a design direction, ask: what usability problems does this create? What edge cases am I not accounting for? What would a user who isn’t familiar with this product think when they see this?

For PE: Before proposing a technical approach, ask: what are the tradeoffs of this approach vs. alternatives? What will make this hard to maintain in six months? What’s the failure mode if the load doubles?

The goal is to arrive at every conversation sharper than you would have alone, not to arrive with someone else’s conclusion wearing your name.

AI drafts, you edit#

The substance is yours. AI is fast at turning it into clean language, and slow at knowing what you actually meant. If the output requires heavy editing, your prompt was underspecified, so rewrite the prompt, not the output.

What AI handles well: Definition docs, release notes, updates, tickets, client messages, PRDs, retrospective summaries. Any structured writing where the substance exists in your head and the challenge is getting it into clear language.

What good prompting looks like: Give it the context it needs to write what you’d write. Not just “write release notes for this feature.” Instead: “write release notes for a feature that lets users save their cart across sessions. The audience is end users. Tone is clear and direct, no jargon. Here’s what it does: [description]. Here’s what problem it solves: [description].” The more context you give, the less editing you do.

What to watch for: AI writes confidently even when it’s filling in gaps you didn’t provide. If something in the output doesn’t sound right, it’s usually because you left something ambiguous and AI made a choice. Go back to the prompt, be more specific, and regenerate that section.

Ask a question, not a task#

“Write me a competitive analysis of X” produces a generic list, because there was no real question behind it for AI to answer. “What are the key tradeoffs between approach A and approach B for a user who needs to do Y?” produces something you can use to decide, because forming that question already required you to think about what you’re trying to learn.

PM and PD use cases:

Synthesising user feedback: paste in raw comments or ticket themes, ask for patterns and what they imply
Exploring design patterns: “what are common ways products handle [this UX problem] and what are the tradeoffs?”
Competitive research: ask about how a category of product typically solves a specific problem, then verify what it says
Preparing for leadership sessions: ask AI to steelman the other side of your argument before you walk in

This is also where genuine exploration lives, a topic you have no prior footing in at all, and it’s a good use of AI, not a workaround of the policy above. The caution matters more here, not less: AI’s training data has a cutoff and has gaps, and it answers confidently either way. Use it to explore and frame something new to you, then verify anything that matters against a real source before you decide or share it. The less you knew going in, the easier a wrong answer slips through unchecked.

The definition doc is the prompt#

This is the clearest place the whole page comes together: Define is where you form your own view, Build is where AI amplifies it, and review against the doc is where you check it before it ships.

Feed the definition doc in full. Add the codebase context AI needs to produce code that fits: the patterns you use, the adjacent code it should be consistent with, the standards you follow. The more context it has, the less you correct.

What good looks like: You give AI the definition doc plus relevant codebase context. It produces an implementation. You review against three things: does it do what the doc says, is the structure consistent with the codebase, and does it handle the edge cases. If any of these are no, you prompt again. Manual fixes are for small details. Structural problems get fixed by reprompting with better context.

What to build as you go: Every time AI makes a mistake you’ve seen before, add it to CLAUDE.md in the project repo. AI reads this at the start of every session. “Always use the service layer for database calls, never call the ORM directly.” “This module expects ISO date strings, not Date objects.” A maintained CLAUDE.md is compounding leverage. The team that keeps it gets faster every week. The team that doesn’t re-explains the same things indefinitely.

Check before it ships#

Get a second opinion before sharing anything important, but only after you’ve formed a first one. Before sending a definition doc to the team, paste it and ask: what’s unclear, what’s missing, what edge case isn’t handled? Before sending a client message, ask: how does this land to someone who doesn’t have our context? Before making a technical decision, ask: what are the risks of this approach that I might be underweighting?

This is one of the highest-leverage uses of AI for all roles, and the one most skipped, because it requires the discipline to slow down before shipping something.

Never send what you haven’t read#

Anytime you hand someone something, a definition doc, a PR description, a research summary, a client message, you’re asking for their time and attention. If it would take them longer to read it than it took you to generate it, it’s probably slop, and sending it anyway moves the cost of catching that from you to them. The Pragmatic Engineer put it plainly: giving someone something you don’t even understand yourself is disrespectful, not efficient.

The test: could you explain what’s in it right now, without looking back at it? If not, you’re not sharing your work, you’re forwarding something you don’t understand yet, and the person on the other end pays for that.

This isn’t an argument against drafting with AI. It’s the same policy, one step later: read it, fix what’s wrong, own every line, then send it. Check before it ships only works if there’s a first opinion, yours, for the second one to catch.

The whiteboard defense#

The benchmark for responsible AI use: someone can pull you aside at any moment, point at any customer-facing system you shipped, and you can explain how it works and defend the calls behind it.

This is not line-level familiarity. Nobody expects you to recite the function name or the exact implementation, and you may genuinely not know it. That’s fine. The bar sits one level up: when someone asks “why X instead of Y?”, “what happens if this actor is malicious?”, “what data structure is this and why?”, or “where does this fail?”, you answer confidently, because those were your decisions even if AI wrote the code.

Bad: asked why the rate limiter uses a fixed window instead of a sliding one, the honest answer is “AI picked it, I didn’t look.”

Good: “Fixed window, because our traffic is bursty and the sliding-window bookkeeping wasn’t worth the memory at our volume. It fails open if Redis is down, which I decided is fine on this endpoint but wouldn’t be on checkout.”

The carve-out is real, and it’s wide. For a PoC, a demo, a spike, a throwaway experiment: generate 100% of it, understand none of it, ship it today. Speed over quality every time, and there’s no defense owed, because nothing depends on it. The question that sorts the two cases is not “did AI write this?” but “will a customer depend on it?” If yes, you own the high-level picture of every part, however it got written.

Shipping customer-facing work you can’t explain is what this rules out. It doesn’t stop being your name on it because a model typed it, and “I don’t know, the AI did that” is not something you can say about a system a customer is using. This is never send what you haven’t read one scale up: from the document in your hand to the system behind it.

Keeping the cost down#

The most expensive way to use AI is also the least useful one: a vague prompt that takes five tries to get right costs more in tokens than a precise one, and still needs as much editing after. Thinking first isn’t just the safer habit, it’s the cheaper one.

Bloated context. The cost of most AI APIs scales with tokens in and tokens out. A padded prompt costs more than a tight one and usually gets worse results. Be specific. Cut what isn’t needed. The definition doc should be precise. Every sentence earns its place.

The wrong model for the job. Not everything needs the most capable model. Simple drafts, formatting, quick lookups: use a faster, cheaper model. Complex reasoning, architecture decisions, definition doc review: use the best one you have. Defaulting to the most powerful model for everything is like using a power drill to hang a picture frame.

Unnecessary regeneration. If AI output is 80% right, edit the 20% instead of regenerating. Regenerating costs as much as the original call and often produces something only marginally different. Get specific about what’s wrong and ask for a targeted revision.

Vague prompts that require many iterations. Every back-and-forth costs tokens. A better prompt upfront, with full context, a clear ask, and examples of what good looks like, means fewer iterations. This is why the time you spend on the definition doc pays off in Build: a precise definition means fewer prompting cycles to get the implementation right.

Prompt caching. Tools like Claude support prompt caching for repeated context: system instructions, CLAUDE.md contents, shared background. If you’re sending the same base context across many calls, use a tool that caches it. The first call pays; subsequent calls are significantly cheaper.

By role#

PM: highest leverage: thinking partner before leadership sessions, definition doc drafting, release notes, client communication, synthesising feedback into problem statements.

PD: highest leverage: exploring design alternatives before committing to a direction, writing UX copy, identifying usability gaps in your own designs, synthesising research into insights.

PE: highest leverage: implementation via definition doc prompts, maintaining CLAUDE.md, code review assistance, pressure-testing architecture decisions before proposing them.

For all roles: the habit that compounds fastest is forming your own view first, then using AI to draft, pressure-test, and check it. The people who do this consistently produce sharper work in less time. The people who only use it to skip that first step produce more work, not better work.