Lesson 004Field guide · Build With AI
Working with AI Coding Tools
Team up with AI coding assistants without getting lost.
You'll learn
- The working relationship: you direct, the AI builds
- Why one small step at a time beats one big ask
- The ask-it-to-explain habit that keeps you oriented
- How to handle errors calmly — pasting them back is the normal move
- Why you save a working copy before every change
- How to tell, honestly, when you're out of your depth
01Section
You direct, it builds
AI coding help comes in a few shapes — chat assistants that write code when asked, coding-focused assistants that work alongside files, and tools that generate whole small apps from a description. The brands will keep changing; the working relationship won't.
In that relationship, you are not the programmer and you're not a passenger either. You're the director. You know what the tool is for, what correct looks like, and when it's done — that's your brief. The AI knows syntax and can produce code fast. Neither of you can do the other's job.
The mindset that makes this work
You don't need to write code. You do need to stay in charge of what's being built — every step, in plain language.
Checkpoint
02Section
One small step at a time
The tempting move is pasting in your whole brief and asking for the finished tool. Sometimes that even works. But when it doesn't, you're holding a few hundred lines of code you can't follow, with a problem hiding somewhere inside — and no idea where.
The reliable move is the same one you'd use with any collaborator: smallest useful piece first, confirm it works, then add the next piece.
Ask for the smallest working version: "Start with just the inputs and the total — nothing else." A skeleton you can run beats a masterpiece you can't.
Run it and check it yourself: Does it do what you expected? Compare against your by-hand answer before moving on.
Add one piece: "Now add the rounding rule." One change at a time means when something breaks, you know exactly what broke it.
Repeat until the brief is met: Your "done when" line tells you when to stop.
Key takeaway
Small steps aren't slower — they're how you stay in charge. If something breaks, the cause is always the last thing you changed.
Checkpoint
03Section
The ask-it-to-explain habit
You don't need to understand every line of code the AI writes. You do need to understand what each piece does — otherwise you're not directing anymore, you're just accepting. The fix is one habit: whenever code appears, ask for the plain-language version before you move on.
Keep this one handy
Before we continue: explain what this code does in plain language, section by section, as if I've never programmed. Tell me which part I'd change if I wanted to adjust the rules later, and what would break if I removed each section. Also tell me plainly: does this code send my information anywhere, connect to the internet, or do anything beyond the job I asked for?
This does two jobs at once. It keeps a mental map in your head — "the top part reads my inputs, the middle does the math, the bottom formats the message" — and it quietly checks the AI's work, because a piece it can't explain simply is a piece worth questioning.
Checkpoint
04Section
Errors are the conversation, not the verdict
At some point you'll run your tool and get red text instead of results. Here's the reframe that separates people who finish from people who quit: an error message is not a grade on you. It's information — usually quite specific information — about one thing that needs adjusting.
And the move is almost embarrassingly simple: copy the whole error message, paste it back to the AI, and say what you were doing when it appeared. That's it. Errors are written for exactly this kind of diagnosis, and AI assistants are genuinely good at reading them.
The calm response to red text
"I ran the page and got this error: [pasted the full message]. It happened when I clicked Calculate after entering 50 in the lawn size box. What's wrong, and what's the smallest fix?"
Worth knowing
Professional developers hit errors constantly and paste them into search engines and AI assistants all day. Meeting an error doesn't mean you're out of your depth. It means you're building.
Checkpoint
05Section
Save a working copy before every change
The most painful beginner moment isn't an error — it's this: the tool worked, you asked for one more improvement, and now it doesn't work, and you can't get back to the version that did.
Professional developers have elaborate systems for this. You need exactly one habit:
The moment it works, save a copy: Duplicate the file and name it clearly: quote-calculator-v1-WORKING.
Change only the copy: New version, new file: v2. The working version stays untouched.
If v2 breaks badly, walk away from it: You still have v1. Losing an experiment costs minutes; losing your only working version can cost the whole project.
"Improve" changes are exactly as capable of breaking your tool as "build" changes. Never edit your only working copy.
Checkpoint
06Section
Knowing when you're out of your depth
Everything so far keeps you oriented inside a small tool. Honesty requires naming the boundary too. You're likely past your depth when any of these show up:
- You can no longer tell whether the tool is doing the right thing
- The build now involves accounts, passwords, or payments
- Other people's private data would flow through it
- The AI's instructions involve servers, databases, or security settings you don't understand
- You're pasting commands you can't explain into systems that matter
None of these mean stop building forever. They mean this piece has outgrown a beginner-plus-AI team — shrink the scope back inside your depth, or get an experienced person's eyes on it before anyone relies on it. Knowing the boundary is a skill, not a limitation.
Privacy note: Never paste passwords, API keys, or other people's personal data into an AI chat while building — describe them as placeholders instead, like [MY-PASSWORD]. The AI doesn't need real secrets to help you build.
Pause and think: Picture your tool idea fully built. Does anything on that checklist appear anywhere in it? Better to know before you start than at step forty.
Checkpoint
Prompt exercise
Start a build session the right way
Copy this prompt into ChatGPT, Claude, Gemini, Copilot, or whichever AI tool you have access to — the website doesn't run AI itself. It sets up an AI coding session with every habit from this lesson built in. Use it with a real (or practice) tool idea and go through at least two build steps.
You're helping me, a beginner, build a small personal tool. Here's how we'll work: (1) Break the build into the smallest possible steps and do exactly one step at a time — never write the whole tool at once. (2) After each piece of code, explain what it does in plain language, section by section, as if I've never programmed. (3) Wait for me to confirm the step works before continuing. (4) If I paste an error message, stay calm and specific: tell me the likely cause and the smallest fix. (5) Before any change to working code, remind me to save a copy first. (6) If anything we're doing involves passwords, payments, other people's data, or security, flag it plainly and tell me it needs experienced review. Start by asking what I want to build.
Reflection: After two steps: could you explain, in your own words, what exists so far and what it does? That's the test of staying in charge — not whether you could have written the code.
Quick check
4 quick questions — no pressure
There's no pass or fail here. Answer them all, and we'll show you the answers either way.