Working with AI as a builder

The tool was identical, and so was the model behind it. What separated the two evenings was skill.

Working with an AI builder is a skill set that breaks into three parts you can practice: context engineering decides what the model gets before it acts, tool selection matches the interface to the size of the task, and the iteration loop steers the session once work starts.

Each skill gets its working version in this chapter and its deep treatment in the Playbook, so treat this page as the front door.

Context engineering: write the project brief first

Every session starts from zero. The model has no record of your code, your users, or the approaches you already rejected, and the gap between what you assume and what you actually handed over is where most bad output comes from. When a session disappoints, the common instinct is to hunt for a cleverer prompt, but the higher-leverage fix is almost always more context, the same material you would give a capable contractor on day one.

Start with a project brief in a file. The working pattern is a short file at the root of your project stating what you are building, for whom, and under which constraints. Claude Code reads a file named CLAUDE.md in your project, and the same idea has become an open convention called AGENTS.md that other tools read. Three sentences are enough to begin:

This is a practice tracker for amateur cellists, built as a simple web app. It lets a player log practice minutes and see a weekly streak. It must never make a player's data visible to anyone else or send email without an explicit confirmation step.

That covers who it is for, what it does, and what it must never do, and a brief this size already changes the work, because every plan and every line of code is now generated against your constraints instead of generic defaults.

The brief gets the skill started, and the habits below complete it.

• Pack the task, not just the project. When you ask for something specific, attach the relevant file, an example to match, and an anti-example to avoid. A request framed "like this one, with these differences" produces better work than "make a new one."
• Keep the brief alive. When a session repeats a mistake you corrected last week, the fix belongs in the brief, not in one more chat message. Our brief for this site changes whenever we catch a repeated wrong turn, and it is the first thing the tool reads in every session we open.

The context engineering section of the Playbook shows what the file looks like as a build matures and how to keep it sharp.

Tool selection: match the interface to the size of the task

The same model reaches you through different interfaces, and a lot of early frustration comes down to running a task in the wrong one.

• Chat for thinking. A conversation interface is the place to explore an approach, compare options, and draft, with nothing touching your files.
• Editor-integrated AI for in-place edits. When you are looking at the exact lines that need to change, an assistant inside the editor changes them where you stand.
• A terminal agent for real multi-file work. A tool like Claude Code reads the project, proposes a plan, edits across many files, and runs commands to check the result. This is the interface for "add the feature," not "fix this line."

When a session drags, ask whether the task outgrew the interface before blaming the model. The tool selection section of the Playbook holds the full decision guide.

The iteration loop: describe, watch, verify, correct

The first response is a draft, not a verdict, and treating it that way is the third skill. The productive rhythm is a loop: describe the change and its constraints, watch the plan the tool prints before approving edits, verify the result by running it, and correct with specifics. One trip through that loop is one piece of work, and most real tasks take a few trips.

Specific corrections move the loop, and vague ones stall it. "Make it better" gives the model nothing to act on, so the next attempt is a coin flip. "The menu stays open after I tap a link, and it should close" names the symptom, the place, and the behavior you want, so the next pass lands close. Write corrections the way you would file a good bug report, and the loop converges in passes instead of evenings. The iteration loop section of the Playbook drills the full rhythm.

What one good exchange looks like

The exchange below is condensed from a real session we ran while building this site. Notice the pattern rather than the specifics: context arrives with the ask, the plan is visible before any file changes, the diff stays small enough to read, and the pass ends with a check instead of an assumption.

Verify before you trust

The verify step carries more weight than the rest of the loop, because the model produces the same fluent, confident text whether the change works or not, and a transcript that reads well is not evidence of working software. At this level, verification stays direct: run the app, click the thing you changed, and read the diff before you accept it. Learning to read what came back, the files, the changes, and the structure, is a skill of its own, and the next chapter teaches it.

Try it now

No setup: Write the three-sentence project brief for the build you chose in Find your build and pick its shape: one sentence for who it is for, one for what it does, one for what it must never do. A notes app is fine. That text is context engineering, finished and ready to paste at the top of your first real session.

With your tools: Pick one small task in any project, renaming something across files or adding a section to a README. Give it to Claude Code twice, in two fresh sessions: once bare, and once with your three-sentence brief pasted first. Compare the clarifying questions, the plans, and the diffs; the second session should read like work from a teammate who was onboarded. If nothing is installed yet, The Setup Clinic gets you to a working session in one sitting. In Codex or Cursor the move is the same: run the task once bare and once with the brief pasted at the top of the chat, and compare the two results.

Chapter Summary

• Working with an AI builder is a skill set you can learn, and it comes down to three skills you can practice.
• Context engineering means handing the model what it needs before it acts, the same material you would give a capable contractor on day one.
• Start every project with a short brief in a file: who it is for, what it does, and what it must never do, and keep it current as the build changes.
• For a specific ask, attach the relevant file, an example to match, and an anti-example to avoid.
• Tool selection means matching the interface to the task: chat for thinking, an editor assistant for line edits, and a terminal agent for real multi-file work.
• The iteration loop is the rhythm of one pass: describe the change, watch the plan, verify by running it, then correct with specifics.
• Write corrections like a good bug report, naming the symptom, the place, and the behavior you want, because vague feedback stalls the loop.
• When a thread keeps failing the same fix, start a fresh session instead of arguing with the old one.
• The verify step matters most, because the model writes the same confident text whether the change works or not, so run it and read the diff before you trust it.
• Next up, Review what the AI built teaches you to read the files and diffs the tool returns.

Sources

• Anthropic documentation for Claude Code project memory files (2026).
• The AGENTS.md open convention documentation (2025).