Getting Lost in What the AI Agent Is Doing: How to Stay in Control of an AI Build

Commit before every instruction you give the agent. That single habit converts an unrecoverable mess into a list you can step backwards through, and it takes about four seconds. Most people learning to build with AI skip version control because it looks like professional tooling they have not earned yet. It is the opposite. The less you can read the code, the more you need a reliable way back to the last state that worked. The minimum practice: - Commit when something works, with a message describing what works: "job list loads from database". - Commit before asking for anything substantial, so the agent's changes sit in isolation. - When the agent finishes, look at the diff before you look at the app. The diff is the truth. - If the change made things worse, discard it and re-prompt from the known-good state. Do not try to prompt your way forward from a bad edit. That last rule is the one that saves projects. Prompting forward from a broken state is how a small problem becomes an unfixable one. The agent has no memory of which version was good, so it keeps building on the wreckage. With commits in place, a bad hour costs you an hour. Without them, it can cost you the project.

Reading a diff is a skill you can pick up in one session, and it is the highest-leverage thing a non-technical builder can learn. You are not reviewing code quality. You are checking scope. Three questions, in order: How many files changed? You asked for one thing. If nineteen files changed, the agent has done something you did not ask for. That is worth a look before anything else. Did it touch files unrelated to my request? Config files, package files, auth logic and database schema showing up in a request about button styling is a red flag. Agents often "helpfully" refactor things nobody asked about. Are there deletions I did not expect? Removed lines are shown in red. Deleted code is the most expensive kind of surprise, because the app can keep working for days before you find out what went missing. You can answer all three without understanding a single line of the code itself. It is pattern matching on shape and size, not comprehension. When something looks off, ask the agent directly: "You changed the auth file. I asked about the button colour. Explain why." Often it will admit the change was unnecessary. That question alone prevents a large share of mystery bugs.

Limit what the agent is allowed to touch and you limit what can go wrong. This is a prompt-level control, and it is more reliable than reviewing everything after the fact. Four constraints worth using by default: - Name the files. "Only edit components/JobList.tsx and lib/jobs.ts. If you think another file needs changing, tell me instead of changing it." - Ban side quests. "Do not refactor anything. Do not rename anything. Do not add dependencies." - Require a plan first. "Before writing code, list the files you will change and what you will change in each. Wait for me to confirm." - Cap the scope. "Make the smallest change that fixes this. Do not improve anything else." The plan-first constraint is the one that changes the most. It converts an opaque burst of edits into a proposal you can reject for about thirty seconds of your time. When the plan mentions a file you did not expect, you have caught the problem before it exists. Agents comply with these instructions well, and they need to be repeated. A constraint given ten messages ago carries less weight than one given now, so restate the important ones when the task changes.

When the third fix is worse than the first, stop prompting and reset. Iteration decay is a context problem, and more prompting makes context worse rather than better. Here is what is happening. Each failed attempt leaves broken code in the file and confused reasoning in the conversation. The agent now sees its own bad output as an example to follow, and it will not tell you that the conversation has stopped being useful. It cannot tell. The reset procedure: 1. Roll the code back to the last commit that worked. 2. Start a fresh conversation. Do not continue the one that went wrong. 3. Describe the problem from scratch, including what you already tried and what happened. "I tried adding a filter to the list and it broke the sort order twice" is useful context. The failed transcript is not. 4. Ask for a diagnosis before a fix: "Explain why this would break the sort order, then fix it." One survey respondent described the pattern precisely: "I will ask for one thing, but it does something completely different, or it focuses on one task while neglecting another." That is usually a signal that the conversation has accumulated too many competing instructions. A clean conversation with a clear single goal fixes it more often than a better prompt does.

Do I need to learn git commands to do this? No. The commit, diff and revert buttons in your editor cover everything described here. The concepts matter, the commands do not. Should I read every line the agent writes? No, and trying will stop you shipping. Read the shape of the diff: how many files, which files, what was deleted. Read the code closely only in the area you are actively debugging. How often should I commit? Every time something works, and before every substantial instruction. Committing too often costs nothing. Committing too rarely costs you the last known-good version. Is it better to use one long conversation or many short ones? Many short ones, each with a single goal. Long conversations accumulate contradictions and failed attempts, which is what makes later output worse than earlier output. What if I have already lost the working version? Strip back to the smallest thing that runs, commit that, and rebuild forward in slices. Starting from a known-good small app beats debugging a large broken one.