I Don't Want You To Review My Code

In 2026, I’ve noticed something about my job that is fundamentally different than every year prior. As a software engineer, I am responsible for building web products that serve hundreds of thousands of real humans. My job description has not changed much since 2025, nor has what I am accountable for, which is the code that declares what these systems do, how they behave, and how they look. I have always answered for the code that comes from my laptop; if that code introduces a bug or if there are constraints that we need to work around, I need to take ownership over that product surface and ship a fix quickly or help someone else do it. I’m still writing code by hand when the stars align, but even as AI increases my capacity for work throughput, the biggest difference between 2025 and 2026 for me is not how I feel about writing code, but rather, what happens once I’m done generating it.

I don’t want my team to review my code. Not because they can’t, but because I don’t think they should have to.

As my teammate, the last thing that I want is for you to take my pull request, copy the link into your AI agent with the instruction “pls review this”, and publish those comments as your own. I would much rather have flawed but genuine human judgment, or have this step automated outright, no middleman required. Code review used to be this process where, when I was the person building features brick by brick, my peers would come in and teach me new techniques for laying stone. They would sometimes catch bugs before they could find their way into production. But there was also a discourse that I was prepared to have with each newly opened ticket.

Now, code review is absolutely the biggest bottleneck that I face in my day. That, and waiting for CI. I used to have more human problems, like a coworker at my last company who refused to let me merge a PR because I had written a nested ternary (is there a bigger sin than that?) and I liked how it looked in this one particular control flow. We engaged in a long conversation that felt political because we were both fighting for the same thing: a codebase that we both enjoyed looking at. But engineers are looking at code less and less, which means that reviewing code is becoming increasingly tedious. Much of it has already been automated; I trust Cursor’s BugBot to catch nearly 90% of the bugs that would otherwise make it to prod, where the remaining 10% would come from scaling/load issues or tricky edge cases.

The process of “code review”, again, used to be engineers looking at the definition of a routine and talking through how it could be implemented differently, if at all. What the review process highlights is that we need to keep one thing constant: engineers must review what they frequently observe, which is the system itself. Review is an act of maintenance. We used to get a “feel” for code-defined machines by inspecting their contents and running steel threads through them. When AI is producing most of our code, we need to rethink what engineering teams are now spending the most time observing. This includes:

• The product surface itself. PRs in 2026 should all be required to have at least one photo or video that demonstrates that the author (or authoring agent) actually tested a change end to end.
• CI / tests. I wrote tests sparingly pre-AI; if I could prove to myself and others that something worked, that was usually enough. Maybe a unit test or two would suffice for shared helpers. Now, hundreds of lines of code in my PRs are tests that exist mainly to keep coverage high.
• Traces and events. Having a proper measurement strategy for a feature enables you to iterate, keep, or kill features. If I have confidence that something you’re shipping is measured well, then I immediately feel much better about letting you merge these changes.

It’s true that most of my hours once went to implementation: typing out my solution and being mindful of my software as a craft. Now that the hot new programming language is English, that friction didn’t really go anywhere. It moved. My PR cycle time is the longest it’s ever been in my career because of review and resource constraints around our test runners. I go back and forth with “review agents” on code changes, iterating with a stateless judge until I pass an arbitrary test. Features that can be built as PR “stacks” (which GitHub finally supports natively) are often punished because every rebase of the stack will 1) rerun CI for every single PR, and 2) usually auto-dismiss approvals, sending you back out on a quest to get those previous reviewers to re-stamp your changes.

I want to have a code review process that is trustworthy enough that humans only feel obligated to look at the three things above. I want others to (at their own discretion) read the code in a PR and learn something about the product, without their first thought being to criticize the way that it’s written. I am far less attached to code that was not typed by my hands; if you have a different implementation in mind, that reality is only a prompt and a few tool calls away. My opinions on what makes high-quality vs. low-quality code are largely unchanged, but I am more tolerant of ugly duckling code that has earned its place in the repo by being useful and easy to understand. This might be a hot take, but it’s a loosely held/strong opinion of mine.

My hope is that, across the industry, we see meaningful improvements in the ways that engineering teams at AI-enabled companies do code review. I want teams to talk openly about what they’ve tried. I’m putting up more PRs than I ever have, and so are the people around me. I’m drowning in review requests while passing off that same burden onto my already stretched team. And, the models have gotten good. I trust Fable-class LLMs to implement the majority of my work. The models are so good, in fact, that they can control a computer use agent to navigate a cloud-hosted environment and test my changes for me. As execution and implementation move to the cloud, so does quality assurance.

The holy grail of human-in-the-loop code review would probably be:

1. A teammate asks me for a review, and when I open their changes, I have a helpful description that was co-authored by a human. This gets me up to speed on why this change is necessary (ticket link/Slack thread) and how they tested it. This proves to me that they know what these changes do in their own words.
2. The PR contains an attachment, like a picture or a screen recording. Better yet, it has a screen recording of an agent clicking around in a preview environment that I can also visit.
3. The most important files in the PR are the ones that I see first in any sort of file list. Test files should even be excluded from the diff, or included as their own diff type (+300 additions / -200 deletions / +455 test lines) so I can see the real weight of the changes.
4. It should be easy to “talk to these code changes”. Opening a side chat and asking “where is this method defined?” keeps me in a flow state, instead of encouraging me to open my own chat agent and hand it the whole review.

And to paint the narrative with a bit more color:

Davis just finished a massive rewrite from Next.js to TanStack Start, along with a new component library. All of these changes live on a long stack of PRs that he pushes to his favorite git forge. He waits for his preview environment to spin up and get tested by QA agents. They interact with every component that changed, taking screenshots and pictures as they go while collecting feature telemetry and unit test results.

The first pass comes back with a memory leak detected and some style inconsistencies flagged. All of this context goes into a single repair prompt that is yet again tested autonomously. Davis puts these findings into the PR body with business context and asks his team to review. They look at the behavior of the systems through real visual evidence and performance/usage summaries.

The file with the highest relevancy, which is shown first in the file diff, reveals that the LLM accidentally fetched each row’s data from inside a client-side .map() instead of making one batched request up front. This regression wasn’t caught by any tests or agents, since the test db fixture is much, much smaller than prod (and haven’t we all done this at one point?). A teammate who has been burned by this before leaves a comment, and a new cloud agent is dispatched to make the correction. The React components look great, feel great, and are ready to merge. One click, tests are selected intelligently to run in a merge queue for optimal CI wait time, and the code changes are deployed. Et voilà.

In the above, we see that human code reviews of AI output are most helpful when we give reviewers better opportunities to exercise their critical thinking, instead of treating every part of the diff as equal and wasting their attention.

I offer no one-size-fits-all solution to the challenges above. But I think companies have three solid options. The first is to lean hard into developing your harness to be well-equipped for agentic review, and then just Trust The Model. This spans from custom code review workflows/skills/subagents to languages like Bend, where you write down the rules (“laws”) your code is never allowed to break, and Bend’s compiler will make the agent formally prove it followed them before it ships anything. This infrastructure is still pretty new, but it’s a clear productive step in the right direction.

The second is to set an exceptionally high bar for talent and give your employees radical ownership over their features/domains. Away with CODEOWNERS, away with mandatory reviews, away with reapproval-required-after-pushing-new-changes. Designers cannot spend all day reviewing slightly above-average vibe-coded ideas. But if you hire insanely talented product engineers, then designers can put their effort into things like design system audits and UX improvements, while trusting the engineers to have the same attention to detail that they do.

The third option is to get serious about your testing infrastructure. If your code review process isn’t going to change, then your focus should be on reducing the time that it takes for a PR to land in prod. Faster runners, smarter test selection, hotfix paths as a priority queue, instant rollbacks, and all that jazz. At my last company, I remember waiting anywhere from ~8 to 15 minutes before we could run any tests, just replaying Django migrations on a test db. This was inconvenient but tolerable a few years ago. Today, with PR/commit throughput as high as it is, that’s inexcusable.

None of these options are mutually exclusive, and there are probably other strategies that I forgot to mention here. The best engineering teams at ambitious companies are, hopefully, doing everything they can to strike a balance between developer experience, code quality, review certainty, and reliability.

But in another year or two, if you’re still reviewing my code, something has gone terribly wrong.