You can't fix code review with code review

Engineers never liked doing code reviews. Especially if there were lots of files, you got fewer reviews. That was so 2023. Today, in 2026, AI Coding agents generate most of the code, and the code review problem is much worse than it ever was. Paddo captures very well the disaster that is Amazon Kiro and Spect Driven Development. Everybody believe that code review is a bottleneck; let's be honest with the anti-pattern of vibe-coding, and when speed beats safety, bad things happen. Many companies are seeing twice as many incidents, including Microsoft GitHub and many others. Safety needs to come first and speed next, not the other way around. Industrial logic got that decades ago with Modern Agile. Modern agile was a second take on the agile movement with the addition of modern concepts. That is not new; in fact, Modern Agile was created back in 2016. One of the principles was "Make safety a prerequisite". 

More AI: Means more things to review

Many companies and people believe you can put out a fire with more fire. Meaning that if you throw more AI than you can handle, code review. That logic makes no sense; more AI means more things to review. Since 2014, Facebook(Meta) learned that Move Fast and Break Things " does not scale and got a new motto: "Move Fast with Stable Infra". It's the same idea as industrial logic, Modern Agile. Today, you might hear this as "guardrails". 

You are missing the retrofit and Automation

The problem with code review is that it is manual. AI coding agents already stole the joy of coding from us; do not allow AI to turn us into manual QA testers. What we need to do is introduce automation through code. Code is deterministic and reliable. The main issue is that people fix the same things in code review, over and over. Boris Cherny, the creator of the Claude code while working at Facebook (Meta), shared his approach to automating code review before creating Claude. The solution is pretty simple, analyze common patterns across multiple reviews and always turn into a retrofit. 

In case you did not get it, here are examples of proper retrofit in code reviews:

  • Do not keep repeating the same things over and over - go automate
  • Go improve your linter and add more rules.
  • Go improve you test suite and testing diversity and add more coverage and more forms of tests.
  • Go add automation and tests that do not exist.
  • Go invest in Canary, progressive rollouts, and traffic split

More Good Tests than Ever

Engineers fear and are always careful to not break anything. AI will break everything, all the time, forever and ever. Now we need to test things we never test as much (because it was more expensive and we always had bigger problems, but now we need to):

  • Amazing Test Suites
  • Reliable Tests
  • Test CSS
  • Test Observability
  • Test Infra
  • Test Configurations
  • Test DevOps components like Terraform, k8s, ArgoCD, and many others.
We also need to have critical sense and understanding what good tests look like and how bad tests look like, so we can judge if we are improving our tests or making them worse. 

Cheers,

Diego Pacheco

Popular posts from this blog

Cool Retro Terminal

Image
I often don't blog about this kind of stuff. Yesterday I friend of mine showed me this awesome project called  cool-retro-term . When you work with Cloud Computing and DevOps Engineering you spend lots of time on the black screen testing things on the cloud.  When I saw this project I got very excited because it brings some nostalgy back to my life. To be 100% clearI'm not that old as my friend :-) However I share his joy into this retro terminals. This also reminds me some old games like Fallout 1 . I just this is pure fun so I'm sharing here with you guys some screenshots and also how to run on Gnome Ubuntu 17.04.
read more »

Having fun with Zig Language

Image
Zig is a general-purpose language created in 2016 by Andrew Kelly .  Zig aims to fix the issues C language has while being pragmatic and simple at the same time. Zig really shines as being simple by not having any hidden control flows, not having hidden memory allocations, no pre-processors, and no macros. Basically, it's one language and one language only. Since pre-processors and macros can get really complex and become their own universe. Sure it's not the Zig Philosophy.  Zig Compiler(Zig cc) also is a C compiler, and the interoperability from C to Zig is very good. Clearly, we can see influence from other languages like Go and Rust; however, Zig is pretty unique and different from Go and Rust.  Zig is fast. Zig is perfect for system programming. I bet we will see a lot of solutions being built in Zig. As a languages aficionado, I like to learn at least one language per year and sometimes more; Zig was my 2021 pick, did not regret it. Even if you dont use all language...
Keep reading

GIT based wiki with Gollum

Image
We all need information. There are some many things we need to remember on a standard DevOps project. There are multiple things that we can forget pretty easy. I know so many teams that really only on Slack to track information and that is a big problem. IMHO no one wants complex and heavyweight tools to track information. Developers want simple, easy and pain-free tools like wikis. The problem with most of the wiki tools is that they are heavy and complex to manage. IMHO for small and medium projects we a better solution. I love Git and I love GitHub. GIT has some many nice properties like Easy to audit, easy to merge, we never lot updates, we know everything that happened, we can get back in time pretty easy. For those reasons I really like GIT based Wikies like Gollum . Gollum is built with Ruby and has a nice and clean UI. Using Gollum UI - Gollum translates all the changes into git commands and make commits for us. When we run Gollum, it takes care of everything - the only thing...
read more »