Nate Meyvis

My PRs are getting larger

In the pre-AI world, I was a small-PR1 person, sometimes notoriously so.2 These days I prefer much larger units of code, for many reasons:

  1. AI, when used well, has a good chance at making large changes properly. So, to the extent that code review is about ensuring that the code is proper there's less reason to do it at such a very granular level.3
  2. AI allows me to do more, and more thorough, code review before I send it to GitHub or to any other forum for formal review. (Most of this code review is also AI-centric.)
  3. Keeping code changes small helps humans locate the causes of problems, but AI is really good at that kind of debugging whether or not changes are small. (Put another way: even if you make the task of locating a bug's cause 10x as hard, it will usually be easy for AI to find it, as long as you're doing other things reasonably well, and often even if you're not.)
  4. Prose descriptions of small changes are a good form of documentation, but (i) AI generally doesn't need them, and (ii) having AI means that humans also don't need those descriptions.
  5. If you combine small PRs with AI-enabled productivity, you wind up with a lot of PRs, which can clog up your deployment queue, lead to merge conflicts, and cause other logistical problems.4

I find this bittersweet: small PRs were a fundamental part of how I worked and how I understood the craft. The practice defined much of the texture of my working life. But that old world is well and truly gone, it's great to be able to make large changes responsibly, and the point was always5 to make good things properly. So: I'm using larger PRs, I don't plan to go back, and making software still brings me great joy.

  1. I'm using "PR" generically here to mean any set of code changes reviewed and merged as a unit. This is a "MR" on GitLab, a "CL" at Google, and so on.↩

  2. People who swear up and down that they support best practices generally and small changes specifically will often, I find, look at you funny (or worse) if you actually start sending small changes for review. But that's another post.↩

  3. There are, of course, many other reasons to do code review. (This is another thing that I've found people always agree with when you say it, but very rarely behave as if they believe.)↩

  4. This is a subtle (and important!) subject, and I'm definitely not saying that any one of these consequences has to happen. So, for example, your unit of code review doesn't need to be the same as your unit of deployment. The point is just that there's likely to be some or the other logistical or organizational problem if you're generating 20 (or however many) PRs in an hour.↩

  5. ...for me, at least.↩

#generative AI #nuts and bolts #sociology of software #software