How do you explain a bug in AI-generated code you don't fully understand yourself?
Had a moment this week where a bug showed up in a part of the app I didn't write by hand, my agent did, and when someone asked me why it broke, my honest answer was "I'm not totally sure yet." That's a weird sentence to say out loud as the person who's supposed to own the code.
With code I wrote myself I can usually reason about a bug from first principles even before I open the debugger. With vibe-coded stuff I sometimes have to re-read the whole file like a stranger before I can explain anything, and the explanation ends up being "here's what I found after digging" instead of "here's why this happens."
Curious how others handle this, especially if you're working with a team or reporting to someone less technical:
- Do you wait until you've fully traced the bug before saying anything, or do you communicate the "still investigating" state openly?
- Has anyone gotten pushback for shipping code they couldn't fully explain when something went wrong?
- Has this changed how thoroughly you review AI output before it ships, or has trust just gone up over time?
Replies
I say "still investigating" openly, every time. tried the alternative once early on, waiting until I had the full trace before saying anything, and it backfired worse. the silence reads as either not knowing or hiding something, and with a non-technical stakeholder both look the same from the outside.
what actually changed for me is splitting the explanation into two parts out loud: "here's the symptom and here's my current hypothesis" now, "here's the confirmed root cause" later. people are fine with a hypothesis that's labeled as a hypothesis. they're not fine with silence followed by a correction.
the trust question is the interesting one. mine hasn't gone up with volume, it's gone up with how narrow the blast radius is per change. small diffs I can fully explain even when the agent wrote them. it's the big multi-file changes where "here's what I found after digging" becomes the honest answer, and that's exactly where I've started forcing smaller PRs regardless of how fast the agent could theoretically ship the whole thing at once.
@Gal Dayan the "symptom now, confirmed root cause later" split is a good habit, I'm stealing that. The blast-radius-not-volume trust point matches my own experience too - it's not that the agent gets more trustworthy over time, it's that I've gotten better at keeping the diffs small enough that I can actually be the one explaining it instead of the agent. Curious if you've had a case where forcing a smaller PR wasn't possible, like a schema migration that has to touch several files at once - do you just accept the "still digging" answer in that case or find another way to shrink the blast radius?