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:
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:
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?
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:
But still leave important questions unanswered:
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:
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:
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:
AI agents also need:
Managing AI behavior will become part of engineering work.
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:
Historically, a large part of Code Review was focused on questions like:
Many of these checks can now be automated.
The things that still require human thinking are different:
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?"
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:
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?