> ## Content Index > Fetch the complete content index at: https://debugly.dev/llms.txt > Use this file to discover other available public pages before exploring further. # AI Wrote It, So Nobody Owns It, and That Is the Incident - URL: https://debugly.dev/ai-wrote-it-so-nobody-owns-it/ - Published: 2026-10-02T15:30:00.000Z - Updated: 2026-10-02T15:30:00.000Z - Author: Rohit Bhadani - Tags: Opinion, AI, Engineering Culture Here is the thesis. The most dangerous property of AI assisted code is not that it is wrong, because human code is wrong at comparable rates and we have spent decades building cultures that catch it. The dangerous property is that it arrives without an owner, and every mechanism we have for catching wrong code, review, tests, on call, postmortems, is a mechanism that ultimately attaches a person to a decision. Remove the person, and the mechanisms keep spinning but stop biting. I am not arguing that AI written code should be banned. I am arguing that ownership is a load bearing structure in software quality, that assisted code quietly removes it, and that the removal, not the generation, is the incident waiting to happen. ## What ownership actually does Ownership is not blame. It is the property that some person holds the context for a piece of code: what it was supposed to do, what it must never do, which incident shaped it, and which edge was a deliberate trade. That context is exactly what debugging requires, per [an AI agent cannot debug a system you cannot describe](https://debugly.dev/ai-agents-cannot-debug-what-you-cannot-describe/), and it is exactly what review checks for, and it is exactly what the on call reaches for at two in the morning. When a human writes a line, they acquire, imperfectly but really, some of that context. The act of deciding is the act of owning. When a model writes the line and a human presses a key, the decision was made by the model and the key press was not a decision, so the context was never acquired by anyone, and the code enters the codebase with no one holding the thing the incident will need. ## The diffusion is structural, not moral It is tempting to say developers should simply take responsibility for what they merge, and they should, but the structure actively works against it. The suggestion arrives pre written and plausible, and accepting it feels like reading, not deciding. The diff is large and fluent, and review attention collapses, the same fatigue as the formatting diff in [the formatting only pull request that changed behaviour](https://debugly.dev/the-formatting-only-diff-that-was-not/), multiplied. The model cannot be paged, cannot be asked what it was thinking, and cannot feel the consequences, so the loop of feedback that teaches a team, incident to fix to ownership, has no human at the generation step. The result is code that nobody can narrate, and the review that should catch that is the one in [reviewing code the author cannot explain](https://debugly.dev/reviewing-code-the-author-cant-explain/), which only works if the reviewer insists on narration, and narration is precisely what the workflow optimises away. ## The counterargument, fairly The honest defence is that ownership was already thin before any model arrived. Codebases are full of orphaned modules whose authors left years ago, and teams routinely merge dependencies, millions of lines, that nobody on the team owns, and the world does not end. So the argument goes, assisted code is just more of a familiar condition. I accept the premise and reject the conclusion. Dependencies are owned at the boundary: someone chose the dependency, pinned it, and accepts the upgrade burden, and the dependency's own maintainers hold its context. Orphaned modules accrue ownership slowly through whoever touches them next. Assisted code is different because it is generated at the volume of typing with the ownership of neither authorship nor dependency, and it is produced inside the trust perimeter, so it skips both the boundary review of a dependency and the acquisition of authorship. It is a new category, and categories need new controls. ## What ownership for assisted code looks like The teams that handle this well attach the ownership at the point of acceptance, because that is the only point where a human decision still occurs. **The accepter is the author, stated aloud.** The merge record names the human who accepted the change as its author, with the same obligations as if they had typed it, including being the one paged and the one who writes the postmortem section. Stating it changes behaviour, because people accept differently what they know they will be woken for. **Narration is the merge gate.** A change that touches consequential paths must come with one paragraph: what it does at the boundaries, what it must never do, and how the accepter verified it. The paragraph is the ownership artifact, and its absence is a block, because the absence is the defect. **The context is written at merge, not after the incident.** The must nevers and the incident memory go into the codebase next to the change while the accepter still remembers them, which is the describability investment that makes future debugging, human or model, possible. **Volume is throttled to review capacity.** A team can own what it can read. A pipeline that emits more assisted code than the team can narrate is emitting unowned code by construction, and the throttle is a quality control, not a productivity tax. ## The uncomfortable conclusion The incident I keep returning to is not the bug the model wrote. It is the postmortem where the question "who owns this" had no answer, and therefore the question "what was it supposed to do" had no answer, and therefore the fix was a guess, and therefore the same bug returned next quarter with a new author who also owned nothing. That recurrence is the ownership vacuum made visible, and it is the recurrence pattern from [blameless postmortems went too far](https://debugly.dev/blameless-postmortems-went-too-far/), where the missing piece was likewise not kindness but an owner. ## The rule of thumb Every line of code needs a person who holds its context, or it is not an asset, it is a liability with syntax. Attach the owner at the only place a decision still happens, the acceptance, make the narration the gate, and throttle generation to the team's capacity to own. The model can write faster than a team can own. That gap, not the model's error rate, is the risk, and it is closed by assigning, at merge, the one thing the model cannot have: the consequences.