AI Didn't Kill Code Review. We Did.

AI tools have made it easy for anyone to generate code that runs. But the harder problem isn’t who’s writing; it’s whether anyone is actually reading what gets shipped. Skipping the review step is increasingly common, and increasingly costly.

If you’re wondering whether everyone should be writing code at all, that’s a separate question I covered in AI Made Everyone a Coder. Why That’s a Problem.

Think of AI coding tools like handing two people the same high-performance car: one an experienced driver, one who’s barely driven before. Both can hit the accelerator. Both can go fast. But only one of them can actually use the car’s full potential safely and effectively. The other might feel like they’re doing great for a while, right up until they aren’t.

AI can probably do 60 to 70% of the heavy lifting. The remaining 30 to 40%, the judgment, the review discipline, the knowing when not to trust the output, is what still separates a strong engineer from a weak one. The floor has risen for everyone, but the ceiling still belongs to people who understand what they’re shipping.

To be clear: I’m not anti-AI-coding. I use these tools daily and they make the job genuinely easier, pulling in context from multiple places, drafting boilerplate, and debugging faster. The issue isn’t the tool. It’s treating AI output as a finished product rather than a first draft.

If you’re generating a change with AI, the non-negotiable step is: read your own PR before anyone else does. Go through it line by line. Ask yourself why it’s structured the way it is. If the AI reached for some new language feature or pattern you don’t recognize, that’s worth pausing on.

Example: Say you use an AI assistant to write a method that processes different types of events or payment payloads. The AI decides to implement this using modern Java pattern matching for switch expressions, destructuring the objects directly inside the case blocks:

public void processEvent(Object event) {
     switch (event) {
         case OrderEvent(String id, double total) -> System.out.println("Order: " + id);
         case RefundEvent(String id, String reason) -> System.out.println("Refund: " + reason);
         default -> throw new IllegalArgumentException("Unknown event");
     }
 }

While this code is completely valid in modern Java, if your team’s codebase is still written using traditional type checks and explicit casting, this introduces a brand-new syntax pattern that your peers might trip over during a late-night production hotfix. Instead of forcing your teammates to parse an unfamiliar language feature under pressure, it is much better to prompt the AI: “Rewrite this using standard instanceof checks so it matches our existing codebase style.”

public void processEvent(Object event) {
     if (event instanceof OrderEvent) {
         OrderEvent order = (OrderEvent) event;
         System.out.println("Order: " + order.id());
     } else if (event instanceof RefundEvent) {
         RefundEvent refund = (RefundEvent) event;
         System.out.println("Refund: " + refund.reason());
     } else {
         throw new IllegalArgumentException("Unknown event");
     }
 }

Your job was never to write the cleverest possible code. It’s to write code that’s maintainable and readable, not just by you, but by whoever inherits it later. Engineers spend far more time reading code than writing it. Write for the reader.

So: do the self-review first. If you don’t understand what you’ve written, you’re not ready to ask someone else to review it. You should be able to explain, in plain terms, what your change does and why. If you skip that step and just open a PR, you’re quietly shifting the understanding burden onto your reviewer, who, if they’re reviewing a high volume of AI-assisted PRs from the whole team, may not have the bandwidth to catch what you didn’t. You can’t force a reviewer to catch everything. But you can enforce your own self-review, every time.

When It’s Actually Fine to Skip the Deep Review

There are legitimate cases where you don’t need to scrutinize every single line of internal implementation:

• Throwaway scripts: Generating sample data, mocking up a quick simulation, or one-off utilities you’re not going to maintain. Just don’t run them in production.
• Library migrations with solid test coverage: If you’re swapping one library for a functionally equivalent one (say, one JSON processing library for another) and you have robust integration tests. You can skip a line-by-line review of the library’s internal code, but you still need to rigorously review the boundary where your application interacts with it to catch subtle breaking changes. Just make sure the AI hasn’t modified the tests themselves to force a passing grade.
• Version bumps: AI is generally good at reading changelogs and release notes and handling routine upgrades, provided your test suite is solid and untouched.

A Word on AI-Written Tests

AI can generate a large volume of test cases quickly, including edge cases you might not have thought of. That’s useful. But treat test code with the same scrutiny as application code.

A test can look like it’s asserting the right thing while actually checking something else entirely, or asserting something trivially true. If you just see green checkmarks and move on, you can end up with a false sense of safety: tests that pass but don’t actually protect you. That gap tends to surface at the worst possible time, in production.

The same applies to any AI-generated logic you don’t fully follow: if you can’t understand it, ask the assistant to rewrite it in a way you and your teammates can. Don’t accept output you can’t explain.

---

The Bottom Line

AI coding assistants aren’t going anywhere, and I don’t think we’re heading back to writing everything by hand. The open questions ahead are more about how we use these tools responsibly: usage limits, model routing based on task complexity, and caching strategies will keep evolving.

But the fundamentals haven’t changed: someone needs to own the code, understand what it does, and be able to explain it. AI just makes it easier than ever to skip that step. The discipline to not skip it is what will keep separating good engineering from code that merely “works.”