Code reviews are the hot topic at nearly every retrospective at SEP, and all over the internet. Since we introduced AI into our workflows, we can pump out code at breakneck speeds. It turns out that makes other areas of our process a lot slower. We are overwhelmed by all the reviews piling up in our queue. To compound the issue, these reviews are much larger than what humans used to hand each other. It’s an existential crisis in the software development world.
Mourning the Loss of Code Review
Previously, human code reviews provided crucial psychological, collaborative, and cognitive benefits. Beyond catching bugs, they foster team empathy and distribute code ownership to the entire team. They are a mentoring tool for junior engineers, and they helped us align development with the long term human goals.
The vibe shifts when reviewing AI generated code. Structurally, AI can produce verbose, highly generic code that lacks human intent, lacks context, and includes impossible edge cases or dead functions. This forces skeptical reviewers to manually reverse engineer every change in order to hunt for hallucinated logic. AI makes this task more arduous by not creating thoughtful diffs. They are large. Functions move around. Whole pages are rewritten. Our role as reviewers shift from a thoughtful collaborator to a skeptical auditor. This leaves us feeling cognitively exhausted and socially empty.
Reviews Were Always the Bottleneck
AI didn’t create this problem, it just amplified it, and the industry is going through growing pains. When we engineers come across a problem, our first instinct is to build solutions. In the last year there’s been an explosion of AI code review tools — CodeRabbit, Copilot Code Review, Greptile, Qodo, and others — built specifically to help with cognitive load. They help some, but I think the crux of the problem could be that AI breaks all the rules we created for ourselves in the Pre-AI era.
Back in 2020, Dr. Michaela Greiler gave a webinar on how to make review less of a bottleneck. Her solutions weren’t just tooling — they were the socio-technical practices that Extreme Programming and Agile methodology built their foundations on. We’ll dig into those specifics later, but the point is: we may already have the solutions to this problem.
Retrofitting Reality: Old Lessons for the New AI Era
Let’s take a ride in the wayback machine to “The Before Times”, drudge up some old lessons that the AI hype might have disrupted, and contemplate ways these concepts could fit into our new reality.
Note: I don’t have a crystal ball, and I can’t predict where the cards will fall from an industry standpoint. Some of these ideas I have already tried and had success with, most are merely suggestions on what your engineering team could try (and if you do try any combination of these, reach out and tell me how it went!). Your mileage may vary. My goal is to ground the problem with familiar concepts to counteract the existential dread and ambiguity you may come across on the interwebs.
1. Examine Your Review Culture
This is THE perfect moment to retro your review process. No process or reviewer is perfect. What are your team’s review goals? What is important about your process? Quality control? Knowledge sharing?Can comments in reviews become linting rules? Could a formatter handle the common nitpicks? Are there enough recurring security concerns to justify automated vulnerability scanning? Could we be writing better review summaries? Little decisions like these can have a snowballing effect on your processes and cognitive load.
2. Level Up Your Code Review Game
Code review is a skill. You may be a “fresh out” reviewing your first line of code, or you may have years of experience in your codebase and know what type of pitfalls to look for. Regardless, this is a great time to practice different code review techniques. The most common technique I use is test driven code reviews, but it’s good practice to change up your technique based on what kind of change you’re looking at. Knowing what technique to reach for can save you lots of time and cognitive power by making your review process more targeted.
3. Shift Left: Harness Vertical Slice Task Breakdown
AI’s ability to crank out applications means that we are back to reviewing giant, “horizontal” blocks of code all at once. You could try training your agents to break a feature request into tiny, end-to-end strips of functionality—like building just one single, working button on a website from the screen down to the database. To ensure these slices are perfect, have your AI audit every task against the Agile INVEST checklist, making sure each piece of work is completely Independent, Negotiable, Valuable, Estimable, Small, and Testable. When your AI forces developers to work in these small, high-quality vertical slices, the resulting code changes are naturally bite-sized and simple. This transforms the dreaded code review bottleneck from a frustrating traffic jam into a fast, automated assembly line.
4. Shift Left: Mob Your Agent Plan (Domain Walkthrough)
If you’ve implemented #3, your agent likely spit out an implementation plan for you in the chat, or as a markdown file. Mob Review the plan! Mob Programming is very effective for sharing knowledge and collaboration. It is common for teams at SEP to do domain walkthroughs together before someone starts a story. Reviewing an agent’s implementation plan as a team gets everyone on the same page about changes made. Concerns can be brought up, and the entire team can iterate with the agent on this plan. Cementing an implementation plan together can ensure that by the time code review comes around, everyone is already aware of what changes to expect and surprises are rare.
5. Shift Left: Harness Preparatory Refactoring
Your code base is like a garden. Soil is tilled and fertilized before planting new seeds. A code base must be cleaned, decoupled, and properly structured before adding new functionality. This keeps tech debt to a minimum. It also keeps reviews concise. We teach our engineers to regularly submit preparatory refactoring for review before implementing their new feature/fix. We should be harnessing our agents to have this same mindset. During human review, reviewers are presented with two distinct highly readable phases: a straightforward structured cleanup, followed by a focused feature addition that plugs into newly optimized patterns. Here is an example of an “Assess Refactoring Skill” that our agents use every time they plan work.
name: assess-refactoring
description: 'Identify refactoring opportunities in the code a feature will touch, using SOLID principles. Use during feature planning to surface refactors that should be done before feature work.'
—
# Assess Refactoring Opportunities
Evaluates the affected code for refactors that a feature naturally creates an opportunity to make.
## When to Use
- During feature planning, after `analyze-feature-impact`.
- Each opportunity found becomes a **standalone task to complete before feature work begins**.
## Inputs
- The affected files/components from `analyze-feature-impact`.
## Lens - SOLID
- **Single Responsibility**: components/modules doing too much that could be split.
- **Open/Closed**: can new behavior be added via extension instead of modifying existing code?
- **Liskov Substitution**: subtypes that break expected behavior.
- **Interface Segregation**: components/hooks depending on props/interfaces they don't use.
- **Dependency Inversion**: high-level modules coupled to low-level details.
## Output
For each opportunity, a standalone task:
- **Problem** — with a reference to the SOLID principle it violates.
- **Proposed refactor**.
- **Scope** — small / medium / large.
List refactors **before** feature tasks with a recommended order: refactors first, then feature implementation. Do **not** fold refactors into feature sub-tasks.
5. When All Else Fails: Bet on the Rollback, Not the Diff
For years, the pull request diff was the ultimate gatekeeper: a manual inspection point where engineers attempt to catch every edge case, predict system behavior, and guarantee safety before a single line of code ships. So far I’ve talked a lot about shifting left, but even with the suggestions above, we could see ourselves moving at a pace where using code reviews to flag quality issues is unfeasible and it is necessary to beef up our quality processes on the right. We can do this by using feature flags, canary rollouts, deployment slots, updating our observability and monitoring systems, backward- compatible database migrations, smoke testing, and my personal favorite, chaos monkey. Eradicate the fear of pushing code by lowering the cost of failure to zero.
So, Should We Mourn Human Code Review?
Maybe a little. But I’m not ready to hold a funeral. AI has exposed some cracks in code review processes that were already struggling to keep up, and asking another AI to inspect the mountain of code our first AI generated can only take us so far.
Maybe it’s taking a hard look at the practices we already know make software teams effective: small changes, shared context, intentional design, fast feedback, and systems that are safe to change. AI has dramatically changed how quickly we can produce code, but it hasn’t changed the fact that software development is a team sport. The challenge ahead isn’t figuring out how humans can review an infinite amount of AI-generated code. It’s designing our workflows so they don’t have to. So dust off some of these practices, try them with your agents, retro the results, and let me know what works. We may discover that the path forward looks surprisingly familiar.
