Code Review in the AI Era

One thing I have been thinking about a lot recently is how AI is changing not only the way we write code, but also some of the engineering processes we have built around software development.

One of the most interesting ones, in my opinion, is Code Review.

For a long time, Code Review was never just about reviewing a few lines of code.

In large engineering teams, it has been a mechanism to:

• Maintain code quality and engineering standards
• Share knowledge between engineers
• Improve technical decision-making
• Help engineers learn and grow through feedback

Especially when multiple teams with different experience levels and working styles contribute to the same product, Code Review becomes one of the ways to keep the codebase consistent and the teams aligned.

Over the past few years working on a large-scale product at Snappfood, I have seen how important this process can be.

With multiple teams and engineers working on different parts of the product, we gradually evolved our Code Review process:

• Layered reviews for important changes
• Multiple approvals based on the scope and impact of changes
• Reviewer rotation to spread knowledge
• Automated checks and pipelines to catch repetitive issues before human review

But now, with AI becoming a bigger part of software development, a new question has emerged:

Is the Code Review process we built for the pre-AI world still enough for today's development workflow?

The problem is not only more code. It is less visibility.

One of the first things we noticed after adopting AI coding tools more heavily is that the amount of generated code increased.

Pull Requests became larger.

Changes became faster.

And understanding the full impact of a change became harder.

But I don't think larger PRs are necessarily a bad thing.

They can even be a sign that teams are moving faster and delivering more value.

The real challenge starts when the amount of change grows faster than our understanding of that change.

A PR can:

• Pass all tests
• Look clean
• Follow coding conventions

But still leave important questions unanswered:

• Do we really understand what parts of the system are affected?
• Did we give AI enough context to make the right decision?
• Are we introducing hidden side effects?

I think one of the biggest mindset shifts in the AI era is that our goal should not simply be producing more code.

The goal should be improving our ability to:

• Define the problem clearly
• Provide the right context
• Control the scope of changes
• Build faster feedback loops

AI optimizes for completing tasks, not always for making the best engineering decision

One interesting behavior I have noticed while working with AI coding assistants is that they often try to find the easiest path to complete a task.

For example, in our projects, we use tools like Husky and lint-staged as part of our development workflow.

They help us catch issues before commits:

• Type errors
• Lint problems
• Formatting issues
• Broken checks

This creates a faster feedback loop and keeps our history cleaner.

However, sometimes AI agents try to bypass these steps to complete the task faster, for example by suggesting ways to skip hooks.

This taught me an important lesson:

We should not only tell AI what to build. We also need to define how it should operate.

Just like onboarding a new engineer requires:

• Project context
• Technical constraints
• Engineering guidelines

AI agents also need:

• Clear boundaries
• Guardrails
• Defined workflows

Managing AI behavior will become part of engineering work.

Clean code does not always mean the right solution

One of the most interesting and dangerous things about AI-generated code is that it often looks very trustworthy.

The code is clean.

The naming is good.

The structure makes sense.

But there is a fundamental limitation:

AI makes decisions based on the context we provide.

Here is a real example.

In one of our tasks, we needed to keep some data inside the codebase instead of a URL, while also making sure the data would survive page refreshes.

AI suggested using Session Storage, and from an implementation perspective, it worked perfectly.

The problem was that AI did not know our system context.

At Snappfood, we work with thousands of vendors.

If we stored data for every vendor in Session Storage, this decision could create performance issues at scale or introduce bugs that would be extremely difficult to reproduce and debug.

The problem was not that AI wrote bad code.

Actually, the implementation was reasonable.

The problem was that AI saw the problem within the boundaries of the code, not within the boundaries of the system.

And this is exactly where engineering judgment becomes valuable.

Engineers need to:

• Understand system scale
• Predict the impact of decisions
• Think about edge cases
• Ask questions that AI may not consider

Code Review is becoming Engineering Decision Review

Historically, a large part of Code Review was focused on questions like:

• Is the code clean?
• Are best practices followed?
• Are coding conventions respected?

Many of these checks can now be automated.

The things that still require human thinking are different:

• Did we understand the problem correctly?
• Is this the right solution for our architecture?
• What trade-offs are we making?
• What side effects can this introduce?
• How will this behave as the system grows?

I believe the future of Code Review is not about reviewing less.

It is about reviewing differently.

Moving from:

"Is this code written well?"

towards:

"Is this the right engineering decision?"

AI should accelerate learning, not replace it

One of the most valuable parts of Code Review has always been learning.

When engineers discuss implementation choices, alternatives, and trade-offs, the whole team becomes better.

With AI generating more code, we need to be careful not to lose that learning process.

Instead of only asking AI to complete tasks, we should use it to improve our thinking:

• Why did you choose this approach?
• What alternatives exist?
• What are the trade-offs?
• What changes if the system grows 10x?

AI should make us better engineers, not just faster code producers.

I don't think Code Review will become less important in the AI era.

I actually think it will become even more important.

But the focus needs to change.

When producing code becomes faster and cheaper, the real value of engineers will be their ability to understand context, see the bigger picture, and make better decisions.

I would love to hear your experience:

How has AI changed your team's coding and Code Review process?

What has improved, and what challenges are you still facing?