Building & fixing

The build-test-fix loop

You've sent your mini-PRD, the AI has generated the foundation of your app. Now begins the longest — and most formative — phase of the project: iterative construction. The rhythm is always the same: you ask for one thing, the AI does it, you test immediately, and depending on the result you validate or you fix. Then you start again with the next thing.

This rhythm may seem slow compared to the temptation of asking for everything at once. It's actually much faster over time, for a simple reason: when a bug appears, you know exactly which request introduced it — the last one. Without this discipline, a bug can come from any of your last five requests, and you'll spend more time hunting the culprit than fixing it.

flowchart LR
  D["Ask for ONE thing"] --> G["The AI generates"]
  G --> T["Test immediately"]
  T -->|"It works"| V["Validate and move on"]
  T -->|"It breaks"| E["Copy the exact error"]
  E --> C["Ask for the fix"]
  C --> T
  V --> D

Testing each step: your checklist

After each generation, open the app and actually try the feature. Don't just look at the screen: use the app like a user would. For Tom's "add a habit" feature, that means: type a name, click the button, check that the habit appears, add a second one, then reload the page to check everything is still there.

Also get into the habit of testing edge cases — that's where the bugs hide: what happens if you add a habit with an empty name? If you add twenty? If you click twice very quickly? You don't need to be exhaustive, but two or three "off the beaten path" tries per feature reveal the weak spots before your users do.

• Test the normal case: does the main action work?
• Reload the page: is the data still there?
• Test an edge case: empty field, weird value, double click.
• Check on mobile (or by shrinking the window) if your app is mobile-first.

The browser console: your best ally

When something breaks with no visible explanation, the answer is almost always in the browser console. Press F12 (or right click → "Inspect"), then open the "Console" tab. That's where the browser writes the errors: red lines, often in English, indicating what failed and where.

You don't need to understand these messages — you just need to copy them. Here's what a typical error looks like:

Uncaught TypeError: Cannot read properties of null (reading 'addEventListener')
    at app.js:24:18

Loose translation: "at line 24 of the app.js file, the code is trying to use something that doesn't exist". That's exactly the kind of clue the AI needs to fix things in one message instead of five. Frequent errors you'll come across: TypeError (the code is handling a value of the wrong type), ReferenceError (it uses a name that doesn't exist), SyntaxError (the code itself is malformed), and 404 Not Found (a file can't be found).

The perfect debugging prompt

When things break, don't say "it doesn't work". The AI has no way of guessing what you see on screen. A good bug report contains four elements: what you were doing, what you expected, what happened instead, and the exact error message from the console. With these four pieces of information, the diagnosis is almost always immediate.

Bug to fix.
What I was doing: I click "add a habit" after typing "Reading" in the field.
What I expected: the habit appears in the list.
What happens: nothing shows up, the field clears.
Error in the console: Uncaught TypeError: Cannot read properties of null (reading 'addEventListener') at app.js:24:18
Diagnose the cause and fix it, explaining to me in simple terms what was wrong.

Notice the last sentence: "explaining to me in simple terms what was wrong". That's what turns every bug into a lesson. After ten fixes, you'll recognize the common errors yourself — and you'll write requests that avoid them from the start.

When the AI goes in circles

It happens: you report a bug, the AI "fixes" it, the bug is still there, it "fixes" again, and nothing changes — or worse, something else breaks. After two or three unsuccessful attempts, stop pushing down the same path. Three effective strategies: ask the AI to start this feature over from scratch ("delete all the calendar code and redo it more simply"), ask it to add diagnostic messages ("add console.log statements so we can see where it gets stuck"), or completely rephrase your initial request, which may have been ambiguous.

Also keep the nuclear option in mind: going back to the last version that worked and resuming from there. That's exactly what Git is for, which we'll cover right now — a safety net that makes experimentation risk-free.

Saving with Git: your safety net

Git is the tool all developers use to save a project's history. The idea fits in one image: at every step that works, you take a "snapshot" (a commit) of your project. If an experiment goes wrong, you go back to the last snapshot in an instant. No more fear of breaking things: everything is reversible.

If you're on a browser tool (Lovable, v0, Bolt), good news: most of them manage version history for you — look for a "History" or "Versions" menu and figure out how to restore a previous state. If you're on Cursor or Claude Code, simply ask the AI to make the commits for you, or learn the three essential commands:

# At every step that works, take a snapshot of the project:
git add .
git commit -m "Adding habits works"

# To see the history of your snapshots:
git log --oneline

The right rhythm: one commit after each tested and validated feature. The commit message describes what works ("daily check-off OK", "calendar displayed"). Tom picks up this habit from the very first evening — and the day a design experiment breaks his whole layout, he rolls back in thirty seconds instead of rebuilding everything.

Moving forward in small, safe steps

A tested, working feature = a solid foothold. You build on stable ground, not on sand. That's what avoids the "everything is broken and I don't know why" effect that discourages so many beginners. Tom's complete sequence for each feature: ask → test → fix if needed → commit → move on to the next.

This method has a precious side effect: confidence. Every validated small step is a concrete win, and motivation feeds on wins. By the end of the chapter, Tom's app does everything his v1 planned — adding, deleting, daily check-offs, streak — and every brick has been verified. He's ready to go live.