Own the Generated Code
Takes responsibility for code you did not type, before other things start depending on it.
When to reach for it
Before merging a change you did not write line by line — especially one that is about to sit under other work and become expensive to remove.
What changes
- Every file in the change gets a one-line answer for what it does, why it exists, and what happens when it fails.
- Lines nobody can explain are listed, then explained, replaced, or deleted before merge — none of the three is skipping.
- New packages, environment variables, tables, columns, and external calls introduced by the change are enumerated in one place.
- You finish holding a written explanation of the change in your own words, produced without the diff in front of you.
Pairs with
- Ship ChecklistThe last pass before a change goes out — what to verify, in the order that catches the most for the least time.
- Demo Then ShipProves the feature works in the actual running app, not only in the tests written for it.
- Feature Flag ExitShip behind a flag with the removal already written down, so the flag does not quietly become a permanent fork in the code.
Own the Generated Code
Once something else imports it, this code is yours whoever typed it. Do the reading now, while removing it is still cheap.
1. Read every line
Not skim. Every line, in order, with the surrounding file open. If the change is too long to read, it is too long to merge — send back a request to split it.
2. Answer three questions per file
For each file: what does it do, why does it exist here rather than somewhere else, and what happens when it fails. Answer out loud, in your own words. The files where this is hard are the ones to look at twice.
3. Mark what cannot be explained
Any line, expression, or dependency whose purpose is unclear gets marked. Each mark gets exactly one of three resolutions: get it explained until it makes sense, replace it with something understandable, or delete it and see what breaks. Leaving it is not on the list.
4. Enumerate what it introduces
Collect in one place: new packages, new environment variables, new tables or columns, new external calls, new files other people must know about, new build steps. This is the maintenance bill, and it is easier to refuse now than later.
5. Check the failure modes you would check in your own code
Null and undefined. An empty list. A slow or failed network. The second click. Two of these running at once. A value larger than expected. Whatever this codebase has been burned by before.
6. Write the explanation from memory
Close the diff and write a paragraph explaining the change as you would in review. If it cannot be written without looking, the reading is not finished — go back to step 1.
7. Separate owned from trusted
List what is genuinely understood and what is being taken on trust. Put a test around each trusted part, so the next change to it fails loudly rather than quietly.
Rules
- Do not merge code that cannot be explained, however well it works today. Working is a property of this week's inputs.
- Do not let "the agent wrote it" appear in a post-mortem. The commit carries your name and the pager rings for you.
- Do not keep unread code because deleting it feels wasteful. It cost nothing to produce and it will cost something every month it stays.
- Do not rely on tests that were also generated and also unread. They can encode the same misunderstanding as the code they cover.
- Do not defer this past the point where something else depends on it. That is the moment the cost of removing it stops being yours to choose.