Mastery check: your agentic coding playbook

1. Name the goal and its verification, not just the location. Before opening the tool, write (even just mentally) what "done" looks like and how you'll check it — a passing test, a specific output, a behavior you can manually confirm. If you can't state verification, the task is still too vague to hand off.

2. Classify the risk before you start. Ask the two guardrail questions: how big is the blast radius if this goes wrong, and how reversible is it? Let the answer set your review mode — full autonomy with a final diff review for low-risk, reversible work; step-by-step approval for anything destructive, production-facing, or touching secrets.

3. Give it what it needs to plan well. Point at an existing pattern to follow if one exists. State constraints explicitly rather than assuming they're obvious. If this is a recurring type of constraint, put it in your project's rules file instead of repeating it per task.

4. Let it run the loop — read, plan, act, check — without micromanaging every step, for tasks you classified as lower-risk in step 2. Watch for it getting stuck in a retry loop on the same failure, which is your cue to step in with the missing piece of context rather than waiting indefinitely.

5. Review the diff like a pull request, not a rubber stamp. Read the actual changed lines, not just the summary. Check edge cases the task didn't explicitly mention. Confirm it matches the codebase's existing conventions.

6. Iterate through follow-up instructions rather than manual patches, when the fix is more naturally described than hand-typed — the agent retains context from its own previous attempt.

7. Keep the loop of trust calibrated over time. As you see which task types reliably produce clean first-pass diffs from your tool, you can extend a bit more autonomy there. As you see which task types reliably need a revision round, keep reviewing those more closely rather than assuming improvement that hasn't actually happened.

Every step in this playbook is about judgment, not about a specific product's UI. Whether you're in an IDE-integrated agent, a terminal-native one, or a chat-panel plugin, the same six questions apply: is the task scoped and verifiable, what's the blast radius, does it have the context and examples it needs, did I actually read the diff, is a follow-up instruction better than a manual patch, and is my trust level calibrated to evidence rather than convenience. Tools will keep changing; this judgment doesn't need to.

Think of a real, upcoming coding task — something you'd genuinely consider delegating to an agent this week. Walk it through all seven steps above, out loud or in writing. If you get stuck on any step (you can't state verification, you're not sure about blast radius, you don't know what pattern to point it at), that's exactly the gap worth closing before you hand the task over — not a sign the playbook doesn't apply to you.