Highlights

His concern, which I share, is that simply automating code review away risks losing all the other things we use it for. Code review isn’t just about finding bugs. It’s how teams share knowledge, teach junior engineers, build collective ownership and spread architectural understanding.

My question is: why are we waiting until code review to do all of those things?

One of the principles I learned very early at Thoughtworks was to shorten feedback loops. If feedback is valuable, don’t remove it. Move it closer to the decision it is informing.

Pair programming, trunk-based development, automated testing, static analysis, fitness functions and security scanning all move feedback earlier. Increasingly, agents can participate in those loops too, challenging designs, testing assumptions and continuously verifying what is being built, but the real thinking is coming from experienced humans and if we want that experience to benefit the whole team then we have to act like one much earlier than code review.

So perhaps the question isn’t how we get the code reviewed faster. Perhaps it’s why we’re waiting until code review to have all the important conversations in the first place.

If agents are going to produce substantially more of the implementation, we need to be much more deliberate about maintaining human understanding through collaborative design, pairing, good boundaries, executable architecture, shared operational responsibility and probably some practices we haven’t invented yet.

Another common approach is to decide whether to review code by hand or with AI, based on how “risky” a change is:

• Low-risk change: only AI, without human review. It can ship to production once AI agents are happy
• High-risk change: mandatory human review

This is the approach that Anthropic and OpenAI follow

We decided to do a couple of things:

• Switch to a risk-based system. With a risk-based system, we agreed that if your change touched the public API/MCP, auth, design system, non-additive database schema changes, or agent skills, it needed a human review. We then enforced that with a shell script to add a GitHub label.
• Improve our guardrails (unit and end-to-end testing, post-deploy observability, stricter linting and type checking, etc). Improving guardrails was pretty easy, just expensive in tokens and attention. We enabled nearly every rule in ruff/prettier/eslint/ty, and we improved our unit test coverage to a floor of 85%.

Results before vs after:

• PRs merged: 353 → 684 (80/wk → 154/wk, +94%)
• Merged within 1h: 28% → 45%; within 24h: 76% → 80%
• Human-reviewed PRs median merge time: 26h
• No human-review median merge time: 1h.”

Uber’s custom-built Code Review Inbox highlights high-impact changes, so devs know to spend more time and effort on them:

We take it mostly for granted. Think about how many people have lived before you; think of the immensity of their lives, what they said, what they heard, what they did. Think of them sitting at their desk, struggling to articulate this experience for others. Think of the historians and philosophers and wise people who dedicated their whole careers to figuring out how and why certain events unfolded, why and how individuals made fateful decisions. Think of all the books they had read just to create a single, distilled volume they published.

They are all long dead and buried, yet they continue to reach out, collapsing centuries and shattering barriers, traveling across time and space and the vast range of perspectives. They are offering you their hand along your own life path.

Five successive changes to how cache entries are stored in memory cut the per-entry footprint by over 50%. Across our fleet, these changes freed up roughly 100 terabytes of memory, equivalent to the amount of RAM in 130 of our Gen 13 servers. The cache also got faster. Insert throughput rose 43% and lookup latency dropped 19%, as fewer allocations and better memory locality meant we did not trade speed for space.