08 — Debugging, Version Control, and Testing — The Three Safety Nets

Debugging, version control, and testing felt like overhead that got in the way of the build — until the AI started producing mistakes in volume. Writing them down together forced the connecting idea into view: each one catches a different class of mistake that AI-generated code produces in volume. Debugging finds what broke. Version control lets me undo the AI's sweeping changes when they break everything. Testing proves the fixes stay fixed. Not overhead — the safety system that makes fast building survivable.

The framing that clicked: these three are the only thing standing between "AI goes fast" and "AI goes fast in the wrong direction." The model will confidently make large changes. Without nets, every one of those changes is a gamble.

Debugging: give the AI the right information

The roadmap's debugging guidance is shorter than the topic deserves, but its core claim is correct: _AI is very good at fixing errors when you give it the right information_ [1]. The phrase that matters is "the right information." My default used to be "it's broken, fix it" — which gives the model nothing to work with. The right information is specific and concrete:

• The exact error message, pasted verbatim. Not paraphrased.
• The log output leading up to the failure, so the model can trace where things went wrong.
• The minimal reproduction — the smallest input that triggers it.
• What I expected vs. what I got, stated explicitly.

The roadmap names one more move I underused: _if it keeps failing after a few attempts, ask it to list all possible causes instead of guessing_ [1]. When the model has guessed wrong twice, more guessing won't help. Switching to "enumerate every possible cause of this symptom" reframes the task from prediction to analysis, and the list it produces often surfaces the actual cause — which I then verify before letting it fix anything.

Two more debugging tools the roadmap mentions earn their keep: logs to trace exactly where things go wrong, and — when available — MCP tools that give the AI direct visibility into what's happening inside the app in real time [1][2]. Logs are the always-available option; MCP-style observability is the upgrade when the system supports it.

Version control: the AI makes sweeping changes — git is the undo

The case for version control is stronger in vibe coding than in hand-written code, and the roadmap is explicit about why: _version control tools like Git are especially important for vibe coders because AI can sometimes make sweeping changes that break things unexpectedly, and having a recent save point means you never lose too much progress_ [3]. The AI doesn't edit one line. It edits forty files in service of a request, and if the request was subtly wrong, forty files are now subtly wrong. Without a recent commit to return to, "undo" means reconstructing the previous state by hand.

The discipline that makes git useful with AI is commit frequency. A commit is a save point. The right cadence is "after every verified step" — not after a whole feature, but after each small, working increment. Then when the AI's next sweep breaks something, the recovery is git reset to the last known-good state, not a forensic exercise.

The honest habit: treat each verified step as a checkpoint. Prompt, review, run the tests, and if it's good, commit with a clear message _before_ the next prompt. The AI's next sweep is then bounded — worst case, I lose one step, not the session.

Testing: the AI writes tests as it builds, not after

The roadmap's testing guidance is the part I most resisted and now defend hardest: _ask AI to write tests as it builds, not after_ [4]. My old workflow was "build the feature, then bolt on tests at the end." With AI that workflow is backwards, because the feature arrives in minutes and the tests never get written — the dopamine hit of "it works" moves me straight to the next thing. The result is a codebase full of untested AI code, which is the worst of both worlds: fast to write, impossible to trust.

The discipline that fixes it: tests come with the feature, in the same prompt. "Add the login form and its tests" is one unit of work. The roadmap adds three more habits that all follow from treating tests as primary:

• Write a breaking test before fixing any bug. This is test-driven development applied to debugging — the test captures the bug, the fix makes it pass, and the test stays as a regression guard [4][5].
• Use E2E tests to catch real user-facing bugs. Unit tests verify functions; E2E tests verify the user can actually achieve a goal through the UI, which is where AI code tends to break in subtle ways [4].
• Refactor freely once tests are in place. This is the payoff. Tests aren't a tax — they're the thing that makes refactoring safe, which matters more in AI codebases because they accumulate mess faster [4].

There's a trap the roadmap's resources warn about and I want to name: don't let the AI _vibe-code the tests themselves_ — generating tests without thought until the coverage number looks good [6]. A test suite is only valuable when its assertions are meaningful. Tests the AI wrote to satisfy "add tests" can pass vacuously and give false confidence. The discipline: read the tests, confirm they fail when the code is wrong, and treat a green suite as "the behavior I specified works," not as "the code is correct."

How the three nets work together

The three disciplines aren't independent — they reinforce each other in a loop:

• Version control gives me the safety to let the AI try sweeping changes, because I can always reset.
• Testing tells me immediately whether a change broke anything, before it reaches users.
• Debugging is the recovery move when a change broke something testing didn't catch, and the fix is itself verified by a new test.

Skip version control and every AI sweep is a gamble I can't undo. Skip testing and I ship bugs at the speed the AI writes them. Skip disciplined debugging and I guess at fixes instead of diagnosing them. With all three, the AI's speed becomes leverage — fast changes, caught when wrong, recoverable when sweeping, and verified before they ship.

How I use this

A short loop I run on every task: commit before I prompt (save point), prompt for feature + tests together (coverage ships with the code), run the tests (verify), and commit again if green. When something breaks, I paste the exact error and logs to the AI, ask for a list of possible causes if the first fix fails, write a breaking test for the bug, and commit the fix with that test as a regression guard. The nets are the reason "AI goes fast" stays a good thing instead of becoming "AI goes fast in the wrong direction."

References

[1] roadmap.sh, "Debugging," 2026. [Online]. Available: https://roadmap.sh/vibe-coding/debugging

[2] LogRocket, "AI-First Debugging: Tools and Techniques for Faster Root Cause Analysis," 2026. [Online]. Available: https://blog.logrocket.com/ai-debugging/

[3] roadmap.sh, "Master Version Control," 2026. [Online]. Available: https://roadmap.sh/vibe-coding/master-version-control

[4] roadmap.sh, "Testing," 2026. [Online]. Available: https://roadmap.sh/vibe-coding/testing

[5] Builder.io, "Test-Driven Development with AI," 2026. [Online]. Available: https://www.builder.io/blog/test-driven-development-ai

[6] A. Gallagher, "Stop Vibe Coding Your Unit Tests," 2026. [Online]. Available: https://www.andy-gallagher.com/blog/stop-vibe-coding-your-unit-tests/