Not every bug throws a red wall of text. Often the app runs fine and just does the wrong thing: the total is off, the wrong name shows, a click does nothing. There is no crash and no trace to paste, so you are stuck describing a symptom your agent cannot see. This chapter gets you a way to make that invisible bug visible.
7.2.1Not every bug crashes
A crash is loud. As the stack-trace chapter covered, it prints a report that points straight at the file and line where the code gave up. You have somewhere to look.
A silent bug gives you none of that. The code runs all the way to the end and produces a wrong result, so nothing errors and nothing points at the spot. That absence is exactly what makes it harder: there is no red text to follow, only a wrong number on the screen.
7.2.2Look in the console and the network tab
The evidence is usually already there, in a part of the browser you have not opened yet: the developer tools, the inspector built into every browser. Right-click the page and choose Inspect. On Safari there is no Inspect until you turn it on, under Settings, Advanced, "Show features for web developers".
Three places in there tell you most of what you need. Chrome's own guide is the reference if you want more than this.
| Place | What it shows |
|---|---|
| Console | Errors and warnings the page printed |
| Network tab | A request that failed or returned wrong data |
| The screen | The actual wrong value, next to what it should be |
Open all three before you touch the code. A warning in the console or a failed request in the network tab often names the problem outright.
7.2.3Give your agent a real debugger
A log answers one question you already knew to ask. When you do not know which question, you want the tool nobody tells beginners about.
A debugger stops your program mid-run and lets you look around. You set a breakpoint, a marked line where execution pauses, then step forward one line at a time and inspect every value in scope, without adding a single print. Your editor has one built in already: VS Code's debugger covers most languages, and Node ships its own underneath.
The part that matters here is that this is a tool you hand to your agent, not just to yourself. Your agent is the one doing the debugging, and by default it is working blind, guessing from source code and asking you to paste output back. Connected to a debugger it can set its own breakpoints, run to them, and read the actual values, which is the difference between a theory and an observation. DebugMCP is one way to connect it, and Chrome DevTools does the same for anything happening in a browser.
Watch out: never attach a debugger to production. A breakpoint pauses the process, which means it freezes real customers mid-request, and everything in scope at that moment is visible to whoever is looking. Debug locally or against staging; in production your logs are the evidence.
7.2.4Add a log to see what's happening
When nothing on the surface explains it, the core move is to add a log: a line that prints a value so you can watch what the code actually holds. You ask your agent to drop one at the suspect spot, run it, and read the result.
Here is what one looks like, in JavaScript and in Python:
Run it, and the real value prints where you can see it. If you expected 90 and it prints 100, you have found the exact point where reality diverges from what you assumed.
7.2.5Hand the agent the observation, not the symptom
"It's broken" or "the total is wrong" gives your agent nothing but your guess. It will guess back, and you both circle. A loop like that only breaks when you feed in something concrete, which is exactly what the next chapter is about.
The something is what you just captured: the failed request, the console warning, the value your log printed versus the value you expected. Hand that over and the agent stops guessing and starts tracing.
Do this now: open the console and network tab on the page that misbehaves, paste the prompt with what you see, and add the one log line your agent gives you to turn the invisible bug into a value you can read.
