AI CI/CD Workflow

Always unblock others first

September 10, 2026

Lately, I often hear or read that code reviews are the new bottleneck in software engineering. You'll see companies showing their stats around merged MRs before vs. after the AI era. Consequently, people try to solve that in the most misguided ways possible. For example, by not reviewing the code. The true answer can be found in exactly the opposite direction. By making things that no one likes the highest priority instead of skipping them (looking at you, code review).

Scalable FastAPI Applications on AWS

Build scalable applications with FastAPI and Terraform that run on AWS!

Take Course

No one likes to review the code

Throughout my career, I've never met a software engineer who would rather review code than write it. Code reviews are usually treated as a necessary evil or as a place where you can assert your dominance. As no one likes to do it, everyone is "too busy" to jump at it right away. As it usually takes a long time for someone to review your code, you try to pack everything you can into a single MR. So you need to wait only once. But this leads to large MRs, which are hard and painful to review. So everyone procrastinates on the code review even longer. Do you see where this leads? Exactly towards the huge MRs with 250 changed files and 3500 new lines of code where you wait 3 days to either get a nitpick comment about some variable name or see "LGTM!" approval. Once you get here, you lose all the important parts of code review: context sharing, looking at the same problem and solution from a different perspective, alignment on how to do certain things. The only thing left is the annoying waiting until you're able to release.

Now that AI is writing the code, things can become orders of magnitude worse. What happens when a team generates 3x more code and everyone's procrastinating with the code review? Even more "LGTM!" reviews until you simply skip the code review altogether, as it's just pointless gatekeeping anyway.

The more it hurts, the sooner you should do it

Such an approach makes a lot of sense if you optimize for the largest amount of code produced in a given time window. But if you want to maximize the value that's delivered to your users, you need a different approach. Imagine what it would look like if your MR were reviewed right away ... That would be nice, wouldn't it? Waiting for such a short time that you'd rather wait for the review, doing nothing rather than starting something new.

If you want to improve your team's throughput, that's where you want to go. You need to make sure that MRs are reviewed and merged right away. So that there's always as little work in progress as possible. If you want to do that, you need to say goodbye to large MRs. They take a long time to prepare and a long time to review. By having smaller MRs, you make code review more pleasant, as no one needs to block their whole morning to review your changes. It's also much easier to spot problems and have a fruitful discussion as the scope is much more limited. Besides that, smaller changes have a smaller blast radius, and you can release them more confidently. Not to mention that it's easier to do course corrections based on what's happening in actual production.

What does that look like in practice? It comes down to a few habits the whole team agrees on. For example:

  • Keep MRs small enough to review in 15 minutes.
  • Give every MR a first look within the hour. If you can't do the review right away, a short "I'll get to it after this meeting" is enough - the author knows what to do next.
  • If a review needs more than two rounds of comments, jump on a call.

As you can see, you can turn the vicious circle of bad decisions into a virtuous circle of good ones. The ones that actually make life easier for everyone on your team. The ones that help you deliver more value to the customers faster while not sacrificing reliability. So instead of thinking about how you'll open your fifth MR today, focus on cleaning up the pile of open MRs by reviewing them and helping your teammates to release them to production.

Lead by example and show your team how much faster you can move as a whole if everyone always unblocks others first. You'll be surprised how drastically things can change if everyone does that. If nothing else, code review won't be your bottleneck - even if only AI is writing the code.

Become a better engineer, one article at a time.

Practices, mindsets, and habits that actually move the needle. Delivered weekly to your inbox.

Conclusion

When I was in university, my dad used to say: "Always do the hard exams first. From there, it's just smooth sailing." And he was right. Not only for exams, but in general - including code reviews. Everything else is much more fun if you don't have a millstone hanging around your neck. The sooner you deal with it, the better. So when the next Slack message or email asking for a code review comes in - drop everything and go do the review. Unblock others first and then continue preparing your fifth MR of the day.

Happy unblocking!

Share

← Is test-driven development still relevant?