Writing Code Was Never the Bottleneck

I've felt like a broken record the past few weeks, but this.

Authoring has never been the bottle neck, the same way my typing speed has never been the bottle neck.

The bottle neck has been, and continues to be, code review. It was in our pitch deck 4 years ago; it's still there.

For most companies, by default, it's a process that's synchronously blocked on another human. We need to either make it async (stacking) or automate it (better, more intelligent CI), or--ideally---both.

The tools we have are outdated, and if you're a team with more than 50 eng you've already spun up a sub team (devx, dev velocity, or dev productivity) whose job is to address this. Despite that, industry wide, we've still done very little because it's a philosophically poorly understood part of the process (why do we do code review? Like seriously, in three bullet points what's the purpose - most developers realize they haven't thought that deeply here).

https://graphite.dev

Code review has become the new bottleneck, since it’s the layer that prevents sloppy AI-generated code from entering the codebase.

One thing I do that helps clean things up before I send a PR is writing a summary. You might consider encouraging your peers to do the same.

## What Changed?

Functional Changes:

      - New service for importing data

      - New async job for dealing with z.

Non-functional Changes:

       - Refactoring of Class X

        - Removal of outdated code

It might not seem like much, but writing this summary forces you to read through all the changes and reflect. You often catch outdated comments, dead functions left after extractions, or other things that can be improved—before asking a colleague to review it.

It also makes the reviewer’s life easier, because even before they look at the code, they already know what to expect.

1. Define the problem you are trying to solve.

2. Propose a solution to the problem and get feedback.

3. Design the data model(s) and get feedback.

4. Design the system architecture and get feedback.

5. Design the software architecture and get feedback.

6. Write some code and get feedback.

7. Test the code.

8. Let people use the code.

Writing the code is only one step.

In all honesty, I expect over time intelligent agents will be used for the other steps.

But the code is based on the proposed solution, which is based on the problem statement/requirements. The usefulness of the code will only be as good as the solution, which will only be as good as the problem statement/requirements.

I'm showing my age, but this is almost exactly analogous to the rise of Visual Basic in the late nineties.

The promise then was similar: "non-programmers" could use a drag-and-drop, WYSIWYG editor to build applications. And, IMO, VB was actually a good product. The problem is that it attracted "developers" who were poor/inexperienced, and so VB apps developed a reputation for being incredibly janky and bad quality.

The same thing is basically happening with AI now, except it's not constrained to a single platform, but instead it's infecting the entire software ecosystem.

The "good catch" thing is something I do, too, but mostly for short review comments like "this will blow up if x is null" etc.

I had to think a bit about it, but when it feels off it can be something like:

- I wrote several paragraphs explaining my reasoning, expecting some follow-up questions.

- The "fix" didn't really address my concerns, making it seem like they just said "okay" without really trying to understand. (The times when the whole PR is replaced makes it seem like my review was also just forwarded to the LLM, haha)

- I'm also comparing to how I often (especially earlier in my career) thought a lot about how to solve things, and when I got constructive feedback it felt pretty rewarding - and I could often give my own reasoning for why I did things a certain way. Sometimes I had tried a bunch of the things that the reviewer suggested, leading to a more lively back-and-forth. This could just be me, of course, or a cultural thing, but my expectation also comes from how other developers I've worked with react to my reviews.

Does that make sense? I'd be interested in hearing more about the problem you're dealing with. If this is not the right place, feel free to send an email :)