I’ve been reading about “vibe debugging” and clearly I’m missing something.
Because what I do is get the agent to write red tests first for any code it’ll write next. And if I notice something’s buggy, I don’t “vibe debug” - I get the agent to write tests that reproduce that buggy behavior and implement till green.
In other words, the “vibe debugging” is still vibe coding as I see it.
The other situation I see mentioned side by side with vibe debugging is untangling / comprehending the large codebase implemented by the agent(s).
And I can’t for the life of me figure out how even that becomes a problem. Because what I do when I need to ship a feature is first create a /sprint-brief. Then the brief is input for /sprint-design. Then the design gets structured to a /run-sprint which has a /run-task for each item in the sprint. A task ships modular / atomic test driven development that breaks nothing.
If I ever need to intuitively understand what parts of the agent generated code are doing what, there are always the docs generated by /sprint-brief and /sprint-design to look at.
So, what (on earth) is vibe debugging exactly?
submitted by
/u/vthoriti
Originally posted by u/vthoriti on r/ClaudeCode
