You know that sinking feeling. The one where you push a pull request, everything passes CI, and then the production incident hits. The postmortem starts. Someone asks, “Who wrote this line?” And suddenly you realize: you don’t fully remember. The AI assistant generated half of it. The reviewer approved it. The tests passed. But now it’s your name on the blame list.
This isn’t a new problem. AI didn’t break your engineering culture. It just held up a mirror.
Let’s be honest—most engineering teams have been operating with blurred accountability for years. The “tester” title disappeared at many companies long before ChatGPT wrote its first unit test. One top comment on the HN thread nailed it: “Even in pre-AI world, there were no testers around me for the past many years… those who actually tested the final product before the release were called ‘release engineers,’ not ‘testers’ or ‘QA’.” The roles were already ambiguous. The responsibility was already diffuse.
Now add AI. Suddenly, the code that breaks was not written by any single person. It was co-authored by a machine. The logical question—“Who is responsible?”—is a trap. Because the real question is: Why did your team never have a system that could answer that question before AI showed up?
We’ve been pretending that authorship equals ownership. But in modern engineering, code is a collaborative soup. The PR author, the reviewer, the release engineer, the test automation—everyone touches it. Nobody owns it. And when something breaks, the blame collapses onto whoever touched it last. That’s not a bug in AI. That’s a bug in your team.
I’ve seen this firsthand. A team ships a feature. The AI generates the boilerplate. The human writes the business logic. The reviewer signs off without reading the generated code. The release engineer deploys it. Two weeks later, a critical edge case crashes the system. The incident commander asks: “Who wrote this?” Silence. The AI didn’t answer. The human didn’t remember. The reviewer didn’t catch it. And the release engineer? They just pushed the button.
So what do we do? Stop blaming the tool. Start fixing the system. If you don’t have clear ownership—if you don’t have a process where each line of code has a named human who understands it, tests it, and owns it in production—then AI will only amplify the chaos. It’s not that AI is dangerous. It’s that your team was already dangerous. You just didn’t notice because everyone was busy pointing fingers at each other.
Take a side. Either your team has clear ownership, or it’s a house of cards waiting to collapse. Neutrality is death. Pick a side: either you commit to building a culture of accountability, or you accept that every future incident will be a blame game. There is no middle ground.
Here’s the twist: The real question isn’t “Who is responsible when AI code breaks?” The real question is “Why did you ever think humans were responsible for code they didn’t fully understand?” AI didn’t create a new responsibility gap. It exposed the one that already existed in every broken engineering process where authorship was a myth and accountability was a lottery.
So the next time you’re tempted to blame AI for a production bug, look in the mirror. Your team’s accountability was never about the tool. It was about the culture you built. And that’s on you.
FAQ
Q: Isn't the AI vendor responsible for code quality?
A: No. The AI is a tool, not a licensed engineer. The company that deploys the code is responsible for its behavior. Blaming the vendor is a distraction. The real issue is whether your team has processes to verify and own the code, regardless of its origin.
Q: So what should I do differently on Monday?
A: Start by mapping every piece of code to a named human who understands it and is accountable for its behavior in production. Ensure that AI-generated code is reviewed with the same rigor as human-written code—and that the reviewer is clearly documented. If you can't tell who owns a module, you've already lost.
Q: But isn't this just a scapegoating issue?
A: Exactly. The contrarian take is that we're asking the wrong question. Instead of 'who is responsible?' we should ask 'why does our system allow blame to fall on a single person?' The answer is that we've designed for individual accountability in a team-based world. The fix is to build collective ownership with clear handoffs, not to hunt for a scapegoat.