The Crash Course

Six lessons, everything on this page.

Read top to bottom. Each lesson is short, teaches one idea, and gives you something you can apply on your very next agent session. No signup, no day-by-day drip — it's all here.

Decompose before you delegate

The single biggest predictor of a good agent session is how well you sized the task before you started typing. Ask an agent to "build the whole billing system" and you'll get something plausible that's wrong in a dozen places you can't easily see. Ask it to "add a function that computes prorated refunds given a cancellation date, with these three edge cases" and you'll get something you can actually check.

The move is the same one good engineers already make: take the outcome you want and cut it into units small enough that each has a clear, verifiable result. A unit might be one function, one endpoint, one migration, one bug fix. If you can't describe what "done and correct" looks like for a unit in a sentence or two, it's still too big — split it again.

Decomposition also gives you natural checkpoints. After each unit you review, test, and commit, so a mistake in step three never silently corrupts steps four through ten. Agents are strongest inside a tight, well-defined scope and weakest when asked to hold a sprawling plan in their head across many files. You supply the plan; the agent supplies the typing. Keep a short running task list — many tools maintain one for you — and hand the agent one item at a time.

Spec first, then prompt

A prompt is not a wish; it's a specification. The quality of what comes back is bounded by how precisely you stated what you wanted. Vague inputs produce confident, wrong outputs — and because the code looks finished, the error is easy to miss. So write the spec before you write the ask.

A workable spec for a unit of work names four things: the goal (what the code should do), the constraints (the language, libraries, patterns, and files it must and must not touch), the interface (inputs, outputs, signatures), and the done-criteria (how you'll know it's correct — usually a test or an observable behavior). Point the agent at real examples in your repo: "match the style of orders.py" beats any amount of abstract description.

Give the agent a place to remember. Most agents read a project file — Claude Code uses CLAUDE.md, Cursor uses rules files — where you record standing conventions once: test command, code style, directories to avoid. Written down, they apply to every task without being re-typed.

When a result misses, resist the urge to argue with the agent in chat. Sharpen the spec and re-run. A tighter spec fixes the class of error; a one-off correction fixes only this instance. The habit that separates fast operators from frustrated ones is treating the spec, not the conversation, as the thing you improve.

Review the diff, not the summary

An agent will happily tell you what it did in a tidy paragraph. That summary is not the change — the diff is. The most expensive habit in agent-assisted coding is reading the explanation, nodding, and accepting. You are the author of record for every line that lands in your repository; review it as if you wrote it, because as far as the world is concerned, you did.

Read the actual diff line by line. Watch for the failure modes agents share: inventing a function or API that doesn't exist, quietly changing a file you didn't ask it to touch, deleting code that looked unused but wasn't, hard-coding a value that should be configurable, or "fixing" a failing test by weakening the test instead of the code. None of these show up in a summary; all of them show up in the diff.

Work in small, reviewable commits so each diff is short enough to actually read — this is the payoff of Lesson 1's decomposition. Use version control as your safety net: never let an agent make sweeping changes on top of uncommitted work, because a clean checkpoint is what lets you throw away a bad attempt with one command. When something looks off, ask the agent to explain that specific line. If the explanation doesn't hold up, the code doesn't either.

Test what the agent writes

Code that looks right and code that is right are different things, and an agent produces the first far more reliably than the second. Tests are how you tell them apart without reading every branch by hand. The strongest workflow makes the test part of the spec: state the behavior you want, have the agent write the test and the code, then run it yourself — and read the test to be sure it actually checks what you meant.

Be a little suspicious. Agents sometimes write tests that pass trivially, assert the wrong thing, or mock away the very logic under test. A green checkmark you didn't inspect is not evidence. When you can, write the failing test first yourself, then let the agent make it pass — that ordering keeps the target honest and gives the agent an unambiguous, verifiable done-criterion.

Let the agent run its own loop. Modern coding agents can execute your test suite, read the failures, and iterate until it's green — the most powerful thing you can hand one is a command that tells it whether it succeeded. Learn how in the testing crash course, and see how teams evaluate agents systematically in Learn AI Evals.

For anything beyond a toy change, also run it the way a user would. Tests catch what you thought to check; exercising the real path catches what you didn't.

Know when not to delegate

Delegating is a judgment call, not a default. Agents shine on well-specified, verifiable, bounded work: boilerplate, refactors with clear before-and-after, test scaffolding, straightforward CRUD, translating between formats, and exploring an unfamiliar codebase. They struggle exactly where software is hardest — subtle architectural decisions, security-sensitive code, anything touching money or auth or personal data, gnarly concurrency, and work where the requirements are genuinely unclear even to you.

A simple test: if you couldn't verify the result, don't delegate the decision. You can let an agent write a payment handler, but you must understand and own the design it implements — never ship logic you can't personally defend. The danger isn't that the agent is dumb; it's that it's fluent, so wrong answers arrive dressed as right ones.

Keep a human in the loop by default, and reserve the fully autonomous, long-running mode for low-stakes, reversible, well-fenced tasks. Grant filesystem, network, and shell access deliberately, not blanket — an agent that can run any command is one prompt-injection away from running the wrong one. The goal isn't to type less; it's to ship correct software faster. Sometimes the fastest correct path is to write the tricky ten lines yourself and let the agent handle the eighty around them.

Control the cost

Coding agents bill in one of two shapes: a flat subscription (Cursor's plans, Claude Code on a Claude subscription) or metered API tokens (Codex and Claude Code on pay-as-you-go), where every message pays for the entire context you've accumulated. Understanding the second shape is what keeps a bill from surprising you: cost scales with context, and context grows every turn.

A few habits keep it lean. Start fresh for unrelated tasks — a long, wandering session drags its whole history into every new request, so clearing context between jobs is often the single biggest saving. Scope what the agent reads: pointing it at three relevant files is cheaper and more accurate than letting it ingest the repo. Match the model to the job — a smaller, faster model handles routine edits; save the frontier model for genuinely hard reasoning. Prefer a few well-specified requests over many vague back-and-forths, since each round re-pays for the context.

Measure before you optimize. Estimate what a session will cost with the LLM price calculator, and check how much context your files consume with the token counter — tool descriptions and long files add up on every single turn.

The real economy, though, is correctness. The most expensive tokens are the ones spent generating code you have to debug for an hour. Everything in Lessons 1 through 5 — tight scope, clear specs, real review, honest tests — is also cost control, because getting it right the first time is always the cheapest path.

Working with coding agents

A method that outlasts any single tool.

Six lessons, everything on this page.

Decompose before you delegate

Spec first, then prompt

Review the diff, not the summary

Test what the agent writes

Know when not to delegate

Control the cost

Build these to make it stick.

Spec-first refactor

Test-first bug fix

Project memory file

Decompose a feature

Same task, three tools

Cost budget challenge

Where to head next.

AI Coding Agents Field Guide (mid-2026)

Learn Claude Code

Learn Cursor

Build with MCP

Learn Testing

LLM Price Calculator

Free, and staying that way.