How to Explain to Your Manager That the AI Wrote the Bug

This is satire, because no organization has ever treated a coding agent as an autonomous coworker right up until it creates a billing incident, at which point it becomes an unauthorized raccoon with root access. Still, accidents happen. At 9:14 a.m., an alert announces that every customer who buys exactly two items receives negative two items. At 9:16, your manager asks who changed checkout. This is not the moment to say, “The AI did it,” with the serene confidence of a person describing weather. It is the moment to begin a carefully managed transfer of metaphysical responsibility.

Start with the correct grammar of accountability

Do not say: “The AI wrote the bug.” That sentence invites undesirable follow-up questions, including “Who asked it to?” and “Who approved the pull request?” Instead say: “An AI-assisted implementation introduced a defect into a change that I owned.” This wording has everything management needs: a subject, a verb, an incident, and one small, unavoidable adult.

If you need a longer version, use the Incident Attribution Ladder, developed by the fictional Institute for Applied Keyboard Distance. The ladder has four rungs: the agent produced the patch; you accepted the patch; CI verified that the patch compiled in its climate-controlled terrarium; production discovered that compilation and correctness have maintained a professional distance for decades. At no point should you describe the agent as “basically a junior engineer.” Junior engineers can be asked what they meant. Your agent will reply with a crisp 900-word retrospective, change three unrelated files, and offer to add observability.

Bring artifacts, not vibes

Your manager does not need a theological debate about authorship. Bring the diff, the prompt or task description, the test evidence, the reviewer decision, and the rollback or fix. Git’s diff tooling is built to compare the relevant revisions; use the three-dot form when you want the change from the branch’s merge base to your branch, rather than whatever emotional history the branch has accumulated.

git diff --stat origin/main...HEAD
git diff origin/main...HEAD -- src/checkout/total.ts
git log --oneline origin/main..HEAD

Read that output before the meeting. This is a demanding requirement, but the organization has already spent 43 imaginary engineer-centuries teaching agents to emit plausible TypeScript. It can spare 90 seconds for a human to notice that a “fix decimal rounding” task also renamed the authorization middleware to authFinalFinal2.

Then locate the line’s history without converting git blame into a disciplinary instrument. git blame -w -L 118,126 src/checkout/total.ts can show the revision and author associated with the affected lines while ignoring whitespace differences. The useful answer is not “whose name appears first.” The useful answer is which commit introduced the behavior, what task led to it, and which controls failed to catch it. Git records line history; it does not convene a tribunal, despite the command’s aggressively helpful name.

git blame -w -L 118,126 src/checkout/total.ts
git show --stat --summary <introducing-commit>
git show <introducing-commit> -- src/checkout/total.ts

Use the manager-safe incident update

Try this: “At 09:14 UTC, we detected incorrect quantity totals for a narrow checkout path. The defect entered in PR #482 during an AI-assisted change I submitted. The PR was approved and merged after the existing test suite passed. We rolled it back at 09:27 UTC, verified correct totals against the affected scenario, and are adding a regression test plus a review requirement for changes to pricing logic.”

This has the rare advantage of being both accurate and incapable of starting a 45-minute seminar entitled “Can We Sue the Autocomplete?” It also avoids the phrase “the model hallucinated,” which is technically expressive but operationally useless. A model did not hallucinate past your branch protection rule. A change crossed a series of gates designed by people, then arrived in production wearing a tiny lanyard that said APPROVED.

Explain why the existing controls were insufficient

Here the instinct is to demand an Agent Prohibition Policy, ideally laminated and stored next to the fire extinguisher. Resist. The relevant failure mode is usually narrower: the task was ambiguous, the generated diff was too broad, tests asserted implementation details instead of behavior, reviewers scanned prose instead of the changed control flow, or the agent was allowed to operate where the acceptance criteria were mostly implied by tribal memory and a screenshot from 2019.

Pull-request review systems already support comments, suggestions, approvals, and requests for changes. Use those mechanisms with embarrassing specificity. For sensitive paths, require a PR description that names the invariant, include a test case that fails before the fix, and make the author state which generated files they actually read. “Agent output reviewed” is not a control. It is a mood.

• Bad follow-up action: “Add a second agent to review the first agent.” This creates a committee of stochastic parrots and a third PR titled reviewer_feedback_final.md.
• Useful follow-up action: split agent work into small, independently reviewable changes, especially around authorization, money movement, deletion, migrations, and concurrency.
• Bad follow-up action: require a 12-field “AI Usage Declaration” for a one-line typo fix. Soon people will use the agent secretly, as nature intended.
• Useful follow-up action: require stronger evidence when the diff changes a business invariant, regardless of whether the text was typed by a person, an agent, or a caffeinated macro.

What the tool is bad at

Coding agents are bad at knowing the invisible constraints that live outside the repository: the finance team’s reconciliation ritual, the customer contract promising that invoices never mutate, the cron job in a different account, the undocumented reason a function has three identical-looking branches. They can inspect code and run commands; they cannot reliably infer which ugly line is load-bearing because it preserves an agreement made during the Great Vendor Migration of Q3. They are also exceptionally good at producing a diff that looks locally tidy while moving the risk into a boundary nobody asked them to inspect.

So do not make the postmortem about whether the AI is guilty. Software has no criminal justice system, only logs, diffs, tests, reviewers, and the occasional person who says “I merged it.” The true observation, standing alone after the satire has been asked to leave the room, is this: responsibility follows the decision to ship, and the fastest path out of an AI-written bug is the same as any other bug—make the behavior observable, reduce the change, test the invariant, and review the evidence.