Every AI-assisted build breaks eventually. What separates builders who ship from builders who stall isn't avoiding errors; it's what happens after the red text appears. In vibe coding, the debugger is a conversation: errors get relayed, symptoms get described, and problems get narrowed in plain language rather than in code.

This lesson covers both the mechanics and the judgment of debugging by dialogue: how to report a problem so the AI can act on it, why long chats quietly make the model worse, and how to tell a real fix from one that merely silences the symptom. These habits feed directly into the pre-ship checks that come later in the course.

What is conversational debugging?

Conversational debugging is the practice of fixing broken software by talking: relaying the exact error, describing the symptom, and narrowing the problem together with the AI instead of reading and editing code. The builder supplies observations and judgment; the AI supplies the code-level work.

The founding move appears in Andrej Karpathy's original vibe coding post: "When I get error messages I just copy paste them in with no comment, usually that fixes it" [1]. The very next line confesses the failure mode: asking for random changes until a stubborn bug goes away. This lesson teaches the first line as technique and treats the second as the trap to grow out of.

The skill breaks into 3 teachable moves:

  • Paste the error verbatim
  • Describe the symptom and what "fixed" looks like
  • Know when to restart the conversation instead of persisting

The copy-paste move

The copy-paste move is exactly what it sounds like: when an error appears, the complete text goes into the chat unedited, with no commentary. Paraphrasing ("it's giving some error about the database") feels helpful and isn't. Error messages look like unreadable noise, but that noise is dense with file names, line numbers, and causes the AI can parse even when the builder can't [2].

This is also why a visible error is good news. Simon Willison argues that hallucinated code is the least dangerous kind of AI mistake, because running it surfaces an error instantly, and that error can be fed straight back into the conversation [3]. An error message is a gift; the silent bugs from the previous lesson are the ones that hurt.

Pro Tip! The same move works on stale knowledge: when the AI keeps producing deprecated code, pasting the current documentation into the chat corrects it.

Rubber duck debugging

Rubber duck debugging is a pre-AI tradition: explaining a bug out loud, line by line, to an inanimate object, classically a rubber duck. Andrew Hunt and David Thomas popularized the practice in The Pragmatic Programmer (1999), and generations of engineers have watched the explanation solve the bug before the duck said a word.

The insight it encodes explains why conversational debugging works at all: articulating a problem precisely is itself a debugging act. Turning vague frustration ("it's broken") into a specific account of what happened, when, and what was expected often reveals the answer mid-sentence.

The difference now is that the duck talks back. Every carefully described symptom does double duty: it sharpens the builder's own understanding, and it gives the AI the material it needs to respond with hypotheses.

Describing the symptom

A useful bug report to an AI has 3 parts: the symptom, when it happens, and what "fixed" looks like. The model can't see the screen, the browser, or the deployed app; it only knows what the conversation tells it. "It's broken, fix it" gives it nothing to work with.

Anthropic's guidance contrasts "fix the login bug" with a report that names the symptom (login fails after session timeout), points at a likely area (the auth flow), and defines done (a failing test that reproduces the issue, then a fix) [4]. Nielsen Norman Group's evaluations found the same pattern with code-generating tools generally: longer, requirement-rich prompts consistently outperform terse ones [5].

Symptom description is also the durable half of the skill. Newer agentic tools run code and read errors themselves, but no tool can notice a wrong total, an ugly layout, or an app that feels slow. Those observations only enter the loop when a person puts them into words.

Narrowing by halves

Narrowing by halves

Narrowing by halves is differential diagnosis without the code: splitting the space of possible causes with each question. Did it break before or after the last change? Does it fail for every input or just one? Logged in or logged out? Each answer eliminates half the suspects, and none of the questions require reading a line of code.

Karpathy's MenuGen project supplies the cautionary tale. The app worked locally but failed once deployed, and an hour of asking Claude, asking ChatGPT, consulting docs, and googling followed, because the bug wasn't in the code at all: the API keys weren't configured on the hosting service [6]. Where a bug lives, in the code, the configuration, or an outside service, is half the diagnosis.

The temptation under frustration is the opposite: dumping every observation into the chat at once and hoping. Precision beats volume. Narrowing is the genuinely intellectual part of debugging, and it belongs entirely to the human side of the conversation.

Context rot

Context rot is the tendency of a model to perform worse as its conversation grows. The research came first: "Lost in the Middle" (2023) showed that language models effectively ignore content buried in the middle of long inputs [7], and follow-up studies in 2025 found degradation across task types, tied to input length itself.

Teresa Torres translated the research for non-technical builders: "The longer your chat gets, the worse the model will perform" [8]. Her working rules: start a fresh chat for each new topic, restart after the model does something problematic, and at around 15 messages, ask for a summary and carry it into a new conversation.

The finding corrects a natural assumption: that the AI remembers what it built and knows what went wrong. It doesn't. It holds only a fixed-size context window, a short-term memory that degrades as it fills. Restarts work because of memory mechanics, not because the model got moody.

The two-corrections rule

The two-corrections rule draws the restart line: after correcting the AI more than twice on the same issue, the context is cluttered with failed approaches, and the productive move is to clear it and start fresh with a more specific prompt. As Anthropic's guidance puts it, "A clean session with a better prompt almost always outperforms a long session with accumulated corrections" [9].

Teresa Torres reached the same conclusion by trial and error, spinning in an endless cycle of an agent claiming fixes that never landed, until she found that "starting a new conversation often fixed the problem" [10]. The heuristics differ in detail (2 corrections, roughly 15 messages), but they cluster around the same advice: restart sooner than feels natural, and treat repetition, the same bug surviving a second fix, as the signal.

Restarting can feel like losing work, because the chat looks like the workspace. It isn't. The code and files persist; only the polluted transcript goes. Restarting with what was learned is the expert move, not the quitter's move.

Pro Tip! Before clearing a stuck chat, asking the model to summarize what's been tried gives the fresh conversation a head start.

Root cause vs. symptom

A symptom fix makes the red text disappear; a root-cause fix removes whatever produced it. The two look identical in the moment, which is what makes the distinction easy to skip. Karpathy's original post confesses the pattern honestly: when a bug won't die, he would "ask for random changes until it goes away" [11].

Anthropic's guidance encodes the counter-move in a single prompt pattern: paste the error, then ask the AI to fix it, verify the fix works, and "address the root cause, don't suppress the error" [12].

The habit for non-coders is a single question before accepting any fix: what was the root cause, in plain language? A cause that can't be explained simply probably wasn't found. A suppressed error doesn't vanish; it resurfaces later as the silent kind of bug that's far harder to catch.

Is vibe debugging mindless?

The word "vibe" suggests debugging with AI is mindless, and for easy bugs it nearly is: paste the error, get the fix, move on. The impression breaks down on the bugs that remain. As reported from LangChain's Interrupt conference in June 2025, Andrew Ng pushed back on the label, calling the work a deeply intellectual exercise and admitting to feeling exhausted after a full day of AI-assisted coding [13]. Simon Willison struck the same note about running multiple coding agents at once: "surprisingly effective, if mentally exhausting" [14].

What tires them out is exactly what the earlier practices describe: forming hypotheses, asking narrowing questions, and judging whether a fix is real or merely cosmetic. The AI writes the code; the human runs the investigation. Ethan Mollick frames this as a redistribution of expertise rather than its disappearance: the skill moves into guiding, troubleshooting, and evaluating the work [15].

The takeaway for new builders is calibration, not discouragement. Debugging by conversation is real thinking. Feeling mentally stretched by a stubborn bug isn't a sign of doing it wrong; it's a sign of doing the part only a human can do.