Every “I built an app with AI in one hour” story skips the same chapter: the part where the code doesn’t work, the AI confidently says it fixed it, and it still doesn’t work.

That chapter is most of the job. I say this with love, as a physical therapist who has shipped more than twenty internal tools for my hospital with AI and no formal training: the skill that separates people who finish from people who quit isn’t prompting. It’s what you do when it breaks.

Nobody taught me to debug, so I paid for this routine with a year of long nights. It has six steps. None of them require knowing how to code.

1. Reproduce it once, on purpose

Before touching anything, make the bug happen again — deliberately, from a known starting point. Which exact click, which exact input, which page.

This sounds too obvious to write down. It isn’t. The beginner move (I did this for months) is to rush back to the AI shouting “it’s broken!” while only vaguely knowing what “it” is. The AI then guesses, you apply the guess, and now you have two problems and no map.

A bug you can trigger on command is halfway solved. It also produces the single most valuable thing you can hand an AI: a precise sentence. “When I save a post with an image attached, the page freezes — text-only posts save fine.” That sentence does more work than any amount of pasted code.

2. Change one layer at a time

Every tool, even a tiny one, is layers: the screen, the code behind it, the data it saves, the server it lives on. When something breaks, the question isn’t only what’s wrong — it’s which layer is lying.

My worst nights all share one signature: I changed two layers at once. Tweaked the code and renamed a database column. Then it broke — or worse, started working — and I couldn’t say which change did it. When you fix something without knowing why, you haven’t fixed it; you’ve hidden it, and it will re-emerge at the least convenient moment with interest.

One change. Test. One change. Test. It feels unbearably slow and it is the fastest thing I know.

3. Feed it evidence, not feelings

There’s a phrase I’ve banned myself from typing: “it still doesn’t work.”

To an AI, that sentence contains zero information, so it does the only thing it can — guess again, usually in a more exotic direction. The spiral of increasingly weird fixes that follows isn’t the AI failing. It’s the AI accurately reflecting how little I gave it.

What breaks the spiral is evidence, verbatim: the exact error message, copied character for character, even if it means nothing to you — especially if it means nothing to you. The red text in the browser console (F12 opens it; that keystroke might be the highest-value thing in this post). What you expected versus what actually happened. I’ve watched an error message solve in one round what three hours of “still broken” could not.

4. Shrink the problem until it embarrasses itself

When a whole feature fails mysteriously, stop fixing the feature. Build the dumbest possible version of just the broken part and watch where it dies.

Upload with a photo fails? Forget the form — can the server receive any file? One test page, one button, nothing else. Yes? The bug lives upstream in the form. No? It lives below, in the server. Either way, the search area just got cut in half, and you can cut it in half again.

This is the step that made me stop fearing “big” bugs. A big bug is just a small bug wearing a large system as a coat. My most humbling one — an upload that failed only for certain files, with a nonsense error — shrank down to this: the security layer on our office server silently disliked one pattern in the file’s content. No amount of staring at my code could have found it, because my code was never the liar. Shrinking found it in twenty minutes.

5. Know when to walk away from the conversation

Here’s something the tutorials won’t tell you: AI doubles down. Once a chat has gone deep down a wrong theory about your bug, every new answer gets pulled toward defending that theory. You’re no longer debugging your code — you’re arguing with a sunk cost.

My rule now: two failed fixes in a row for the same bug = the conversation is the problem. Open a fresh chat and rewrite the situation from zero, in three or four sentences: what the tool is, the precise trigger from step 1, the evidence from step 3, what’s been ruled out. A clean summary plus a fresh AI beats a tired thread and a stubborn one, close to always.

The pattern is suspiciously human. A colleague stuck on a theory needs a coffee break, not a louder argument. So does the model.

6. Write it on the wall you crashed into

When the bug finally dies, the loop has one step left, and skipping it is how you pay for the same bug twice: write down what it was and what fixed it — one or two lines, anywhere you’ll look again. Better yet, somewhere the AI sees too: most AI coding tools can hold project notes, and mine now contain a growing list with entries like “server stores time in UTC, screens must convert — check this FIRST when times look wrong.”

That list is the difference between debugging as suffering and debugging as investment. Same crash, once: education. Same crash, twice: carelessness. My list is long, and every line is a night someone else doesn’t have to lose.

The part nobody says out loud

I used to think debugging was the tax you pay to get to the fun part. I had it backwards.

Anyone can accept working code from an AI — that’s typing. But staying calm while something is broken, asking what do I actually know versus what am I assuming, isolating, shrinking, testing — that’s the actual skill, and here’s the good news buried in it: none of it requires a computer science degree. It requires the discipline to check one thing at a time and the honesty to believe evidence over hope. Those are learnable by anyone. I’m the proof, twenty-some tools over.

The code was never the hard part. The code is what you get as a receipt for debugging well.

This is part of From Zero to Ship — the honest logbook of a non-developer building real tools with AI. The six rules I follow when working with AI pair well with this one.

Comments

Loading comments…

Post Comment