You Own Every Line

When the double offer reached two climbers, nobody at Cragmoor asked which tool wrote the code. They asked who merged it. Accountability for code does not transfer to the thing that typed it. It stays with the engineer whose name is on the commit and the team that ships it.

That is not a moral position about AI. It is a description of how every software team already works, and of what the tools leave unchanged. This page states the professional contract that follows from it, and every later chapter is one clause of that contract.

Where the Name Lands

Follow a change from the agent's diff to production and count the records a team keeps along the way. The commit has an author. The pull request has an author and an approving reviewer. The deploy has whoever pressed the button or merged to the branch that deploys. When something breaks, the page goes to a person on the on-call rota, and the incident review names a change and its owner.

Agent's diffno name attached

→

Commit and pull requestauthor: Kai, then an approver

→

Deploywho shipped it

→

Page and incident reviewthe on-call engineer, then the owner

Every one of those records points at a person. "The agent wrote it" answers the question of who typed the code, which nobody was asking. The questions that matter after an incident are who decided this should ship, what they checked, and what would have caught it, and all three have human answers whether or not a tool was involved.

None of this is new. Before coding agents, a change copied from a forum answer or written by a contractor who has since left raised exactly the same question, and teams answered it the same way: the code belongs to whoever brought it into the repository and the team that ships it. What is new is the volume. An agent can produce in an afternoon what a contractor produced in a month, and the question of who understands it arrives at the same speed.

The Contract, Stated

Before code leaves your hands, three things are true. You can explain every line of it: what it does and why it is there. You have run it against tests you understand, so you know what has been checked and what has not. And you would defend it in review, which means you have already asked of it the questions a careful reviewer will ask.

That is the same contract as for code you typed yourself. The agent changes how fast the code arrives, not what you owe for it. A diff that took the agent four minutes to produce and you forty to read is a normal, healthy ratio for code that will run in production, and the time is not wasted: it is the price of being able to answer for the change.

Run Kai's waitlist against the three clauses and it fails all of them. He could not explain the code that hands an offer on, because he had not read it. He had run it against tests he had not read either, so he did not know what was checked. And he could not have defended it in review, because the first question Ines asked, what stops two offers at once, had no answer. None of that required him to type a line himself. It required him to read what he was putting his name to.

Review Is a Second Check, Not the First

A reviewer reads on an assumption: that the author understood the change, and that the review is looking for what the author missed. That is why reviews work at all. Nobody can verify a 300-line change from scratch in the half hour a review usually gets. A reviewer can check an author's understanding against the code and probe the places it is thin.

A pull request whose author did not read it breaks the assumption. It gets one reading where it should get two, and that one reading is spent doing the author's job: Ines discovering what the code does, which is what Kai should have known before he asked her to look. Two half-readings do not add up to one full one. Chapter 13 returns to this from the reviewer's side, with Kai's next AI-assisted pull request.

The author can make a review stronger, not just possible. A pull request that says what the change does, which tests show it, what the author checked by hand and what the author is unsure about tells the reviewer where to spend the half hour. "I am not certain the 12-hour boundary is inclusive; the test for exactly 12 hours assumes it is" is worth more to Ines than any amount of polish, because it points her at the one decision that might be wrong.

A Library Is Not the Same

You also ship code you did not write when you add a dependency, and nobody expects you to read every line of the package manager's download. The difference is everything that comes with a library and does not come with generated code.

	A library you import	Code an agent generated
Maintainers	People whose job is that code	Whoever merged it
Versions	Numbered releases, pinned in your lock file	One version, the one in your repository
Tests	Its own suite, run on every release	Whatever you and the agent wrote
Other users	Thousands, who find bugs before you do	None; your team is the only user
Changelog	What changed and why, per release	Your commit messages, if they say why

Generated code has none of the library's protections. Its only maintainer is whoever merged it, its only test suite is the one in your repository, and its only users are your customers. Treating it like a library, trusted because it came from somewhere competent, misses that nobody else is ever going to look at it.

What Owning Requires

The contract has clauses, and each is a later chapter. Read the diff, because the diff is the change and the agent's summary is not (Chapter 6). Know how generated code characteristically fails, so you know where to look (Chapter 7). Let tests you understand define what "works" means (Chapter 8). Keep every step reversible, so a mistake costs a discard and not a weekend (Chapter 9). And disclose AI assistance where your team asks for it, which Chapters 9 and 13 take up.

None of these is a special rule for AI. They are the ordinary obligations of an author, made sharper because the typing is no longer what slows you down. When code arrives in minutes, the reading and checking are the only parts left where your judgement enters, and they are exactly the parts a hurried author is tempted to skip.

A useful test of whether you own a change: could you predict what a later change to it would break? If someone asked you next month to make the 12-hour window different for each gym, would you know which functions to touch, which tests would need updating and where the time-zone helper comes in? If yes, you own it, whoever typed it. If you would have to ask the agent to find out, you merged something you are not yet in a position to maintain.