How do you catch bugs when vibe coding without getting stuck in a debugging loop?
by•
Building tools quickly with AI agents works great until something randomly breaks and you have no idea which change caused it.
Tracing errors back through AI-generated code can take hours when there are no proper tests set up. I've heard people talk about using evaluation agents or automated checks but setting those up properly isn't always clear when you just want to ship fast.
What's your simple setup or routine for testing and catching bugs when coding with AI tools?
32 views
Replies
My routine is less about tests and more about making the app tell on itself. Every debug print in the app also goes to a log file on the device, in every build, written as a plain sentence about what happened: "login link ignored, already signed in". Every tappable control has a fixed name and the tap is logged under it. So when something breaks, on my phone or a user's, Settings has a Share Logs button and I hand the agent the tap trail plus the last few lines before the failure, instead of a description. That shortens the loop, because the agent is reading evidence and not guessing which of its changes did it. Two smaller habits. Ad hoc prints get a greppable prefix so they can be removed before the task ends. And a build that fails is treated as information, not as the agent's mistake, so it reads the error instead of apologizing and trying something random.
@gbasovv I like the idea of giving the agent actual evidence instead of just describing the bug. The trap trail and logos sound especially useful when debugging issues that are hard the reproduce.
Do you find this approach works just as well with web apps, or is it more effective for mobile apps?
@_hugo_lefollezou_ Honest answer: on web I have less of it. The log file and the tap trail are a mobile thing, because a phone in someone's pocket is the one place I cannot open a console. My web side is the site and the admin panel, and there the evidence comes from two other places. The browser already keeps the console and the network tab, so I ask people for those, and the backend is where the real state lives: a song generation is one document that moves through states, and a failed run carries an error code next to the raw error, so the site shows the cause and I can read the same code in the function logs. So the principle is the same, give the agent what actually happened, but on web the platform already records most of it and on mobile I had to build the recorder myself.
@gbasovv That makes a lot of sense. I like how you're using what each platform already offers of adding extra tools everywhere. This idea of showing the actual error code on the site sounds especially useful. It must save lot of time when tracking down the cause of a faild run.
@_hugo_lefollezou_ It does. Before it, a failed run on the site just said something went wrong, and a person writing to support could only describe the screen. Now the page names the cause, so their screenshot already tells me whether the music engine refused the prompt, a step timed out, or it was something on my side, and I open the right log first. The nice side effect is that once every failure has a code, you can count them, and the counts tell you which fix is worth doing next instead of the one that annoyed you most recently.