Owning What You Ship When AI Wrote It

A diff that looked fine

Here is a hypothetical, not something that happened to me. Imagine an engineer asks an AI assistant to add retry logic to a service call. The diff is tidy, the tests pass, the reviewer skims it and approves. Two weeks later the retries pile up during an outage and make it worse. Nobody on the team can say why the code backs off the way it does, because nobody read it closely, including the person who merged it.

When the incident review starts, one question comes first: whose change was this? That question has an answer, and it is the point of this whole course.

A quick note on who is writing this. I am Anupam Kumar, a Software Development Engineer working on backend and GenAI systems at Q3 Technologies in India. I am not a manager. This course is my learning notes plus what the evidence says, so I will always show the source and flag where it is weak.

The ownership rule

If your name is on the pull request, you own it.

AI is a tool, like a compiler, a linter or a Stack Overflow answer. The author of record is the person who submits and merges the change. That holds whether you typed every character, accepted a suggestion, or wrote one prompt and pressed merge.

This is not a moral lecture. It is my position on how accountability works in most teams: your colleagues, your users and your employer cannot hold the assistant to account. They can only turn to the people who shipped the change. GitHub’s own documentation does not make that accountability claim, but it does say, from the tool side, that you should carefully review and test generated code, particularly for critical or sensitive applications (GitHub Docs).

Why this matters now

The 2025 DORA report, a survey of nearly 5,000 professionals, puts it in one sentence: AI’s primary role in software development is that of an amplifier. It magnifies the strengths of high-performing organisations and the dysfunctions of struggling ones (DORA 2025 abstract).

Read that as a personal message too. If your habits are careful (small changes, real tests, honest reviews), AI can speed them up. If your habits are rushed, AI lets you be rushed at a much larger scale.

The same report notes about 90% of respondents use AI, yet about 30% report little to no trust in AI-generated code (DORA 2025 report PDF). Stack Overflow’s 2025 survey points the same way: 46% of developers said they do not trust the accuracy of AI output, up from 31% the year before (Stack Overflow). We are using these tools heavily while not fully trusting them. The gap between use and trust is where ownership lives.

Perception versus reality

One of the most quoted studies here is a randomised controlled trial by METR. Sixteen experienced open-source developers completed 246 tasks in their own mature repositories. With AI allowed, they took 19% longer. They expected AI to cut their completion time by about 24% beforehand, and afterwards still estimated it had cut it by about 20% (METR, arXiv).

Please read this carefully, because it is easy to over-claim. The sample is small, the tasks were in large familiar codebases, and the tools were early-2025 tools. It is not a verdict that AI slows everyone down. METR’s own February 2026 update says its follow-up data was too affected by selection effects (developers declining to work without AI) to give a reliable current estimate. It also says developers were likely more sped up in early 2026 than in early 2025, though its data is only very weak evidence for how much (METR update). So 19% is a snapshot of early-2025 tools, not today’s number. The sturdy lesson is narrower: our own sense of how well AI is helping can be wrong. That is a reason to check our work, not to trust our gut.

Comprehension debt

Addy Osmani describes comprehension debt as the growing gap between how much code exists in your system and how much of it any human being genuinely understands (Osmani). It is an opinion piece, not a study, but the idea is useful. Generating code is now cheap. Understanding it is not.

Passing tests does not remove the debt. Tests tell you the code does what the tests check. They do not tell you why it is shaped that way, what it assumes, or what happens outside the cases someone thought of.

There is also a skills angle. Anthropic ran a randomised trial with 52 mostly junior engineers. The group using AI scored 50% on a follow-up comprehension quiz versus 67% for the hand-coding group, and the speed gain was not statistically significant. People who asked follow-up questions and sought explanations retained more than people who simply delegated the code (Anthropic). Two cautions: it is a vendor study of an AI tool, and a short-term lab setting. Still, it fits the common sense idea that understanding fades when you stop doing the thinking.

The “explain every line” test

Before you commit or approve, try this. Pick any line in the diff and explain, out loud, what it does, why it is there, and what would break if it were removed. If you cannot, you have found comprehension debt, and you have three honest options:

1. Learn it now. Ask the assistant to explain, then check the explanation against the docs.
2. Simplify it. Replace clever code with something you can explain.
3. Cut it. Remove what you do not need.

The fourth option, merging anyway and hoping, is the one that breaks the ownership rule.

In my own work I own the backend and the architecture calls across two production GenAI products, and I have written postmortems and handover documents. The standard in this lesson is the one I am trying to hold myself to: if I cannot explain it, I am not ready to be accountable for it.

What the rest of the course covers

Lesson 1 is free. Lessons 2 to 8 are part of the Pro pass. Here is what they hold, so you can decide if they are worth it to you:

2. Using AI coding tools well: your employer’s policy, what never to paste, treating output as untrusted, and keeping your own skills sharp.
3. Reviewing AI-generated code: Google’s review standard applied to AI output, a security-minded checklist, and how to give feedback.
4. Responsibility for GenAI features: evals, guardrails, human oversight, privacy basics (India’s DPDP Act), and a one-page system card.
5. Incidents and blameless postmortems: what to do when a GenAI feature leaks, lies or is injected, and how to escalate.
6. Managing work and communication as an IC: estimates as ranges, status updates, your 1:1, and writing decisions down.
7. Stress and burnout: what the research says, how AI tools can add job demands, recovery habits, and where to get professional help in India.
8. Leading without a title: mentoring, delegating to people and to AI agents, and writing as leverage.

What the course is not: it is not a management qualification, and it is not legal, compliance or medical advice. It is one working engineer’s notes, with sources for the claims and a label on every opinion. Take the lessons in order the first time, then return to whichever one your week demands.

Your takeaway

The 7-line ownership standard

Copy this into your notes, your PR template or a team wiki, and make it yours.

1. I can explain every line I commit.
2. I have run it and read its tests, and I wrote at least one test that would fail if it were wrong.
3. I know what data it touches.
4. I know how to roll it back.
5. If I were paged for it, I could explain it and act on it.
6. Anything I could not verify, I say so in the PR description.
7. My smallest next step to close one gap this week is: ____

Reflect

Which of the seven did I skip on my last AI-assisted change? Write down one sentence about why. Usually it is a deadline or a feeling that the output “looked right”, and the METR result above is a reminder that feelings are weak evidence.

Pick one gap and fix only that one this week. A small, kept promise to yourself beats a long checklist you ignore.

Free pages that go with this lesson

• The Everyday AI Playbook: habits behind good AI use.
• Learning a new codebase and Explain like I’m new to this: prompts for building real understanding instead of copying output.