Maybe We Shouldn't Be Reviewing All This Code

I am Rachel Laycock, Chief Technology Officer at Thoughtworks. I am continually curious about how technology is transforming software development, team leadership, and business operations. In this piece, I will share my thoughts on whether code review is the most effective method for achieving our goals in software development.

Recently, I participated in a panel discussion with Brian Houck from DX at Code Remix, hosted by Moderne. Our conversation was particularly engaging because we held contrasting opinions on the subject matter. Brian has since penned a thoughtful article titled "What are code reviews even for?" expressing his strong stance on the topic, and I felt compelled to respond with my own perspective.

While I acknowledge that Brian and I largely share common goals, I believe that code review may not be the most efficient approach to reaching those objectives. Brian points out some alarming statistics, such as a 106% increase in lines of code per human-landed diff at Meta in a single year, and a 64% rise in median pull request size according to DX's data.

His concern, which I share, is that automating code review might inadvertently eliminate the additional value we derive from it. Code review isn't solely about identifying bugs; it also serves as a platform for knowledge sharing, junior engineer training, collective ownership, and spreading architectural understanding.

Why do we resort to code review as the primary means to accomplish these tasks? I have never particularly favored pull requests as the focal point of the software development process. My reservations stem from the fact that I find it challenging to believe that we should construct something, complete it, package it up, and then transfer it to another team member for an important discussion on whether we built the right thing in the right way.

Furthermore, merge conflicts have consumed far too much of my time. Throughout my career, I have learned the importance of shortening feedback loops. If feedback is valuable, it should be brought closer to the decision it informs. Rather than removing feedback altogether, we should move it closer to the decision it supports.

When seeking alternative solutions or knowledge transfer, I believe pairing is the superior choice. Sitting next to someone, physically or virtually, as they reason through a problem provides far more insight than merely reviewing their completed solution later. If we aim to impart knowledge to junior engineers, let them collaborate with experienced engineers while they think through problems.

Pairing, mob programming, or team design sessions using a whiteboard before writing or instructing an agent to write anything are all viable options. If our aim is to foster collective ownership, we should structure teams so that individuals work on and operate software collectively, rather than relying on pull requests to inform everyone about someone else's work. In this case, pairing, mob programming, or team design sessions around a whiteboard would be ideal.

To further promote collective ownership, we should arrange teams so that people build and operate software collaboratively, rather than depending on pull requests as the sole source of information about what another team member has already developed. Instead, we should utilize pairing, mob programming, or team design sessions around a whiteboard to achieve this goal.

If our objective is to maintain architectural alignment, we should collaborate on design together, establish essential constraints as fitness functions, and encode these constraints into the software. Lastly, if we are reviewing code for formatting, linting, known security issues, or any other aspects that can be deterministically tested, we should automate these checks.

We should not continue to argue about whitespace in 2026, as the focus should be on enhancing the overall software development process.

While Brian's argument does raise a valid point about teams accumulating cognitive and intent debt as software grows, I do not believe that mandatory pull requests are an effective defense against this issue. If agents are expected to produce significantly more code, we must ensure that the real thinking comes from experienced humans and that we create an environment where this experience can benefit the entire team.

To do this, we need to act like a cohesive team from the early stages of software development, not just during code review.