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
Dial
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.
Dial
@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?