I recently read Anthropic's Claude Code guide to merging code.

My biggest learnings are these:

  1. Involve the human as little as possible, automate as much as possible.
  2. Sounds obvious, but some people still advocate for involving the human throughout, and others for not involving the human at all, so their approach is still not obvious.
  3. To what degree humans are involved depends on the blast radius. How much damage a feature/PR could do changes the approval policy (0 humans for simple things, 1 for the average, 2 or 3 for very delicate stuff).
  4. Second, I learned they don't expect engineers to understand the whole codebase, only the part they need to change. This also sounds obvious, but there are companies where it's expected to understand the whole codebase or have owners of certain parts of the application. They didn't say they don't have owners, but their approach seems to focus more on pragmatism than ownership.
  5. So what some engineers do is create artifacts of the part of the code they need to update, say a graphic or a video, and then use that to have a better understanding of the components affected by the expected change, instead of expecting them to know that from reading code.

I think their approach is sound and I'm curious, especially about point 5. I think we'll see that more and more, people creating artifacts as bridges to better understand complex things. I like it!

That's it!