CRs (Code Reviews) are the industry standard for keeping our code quality and sharing best practices between team members.
But if you think about what a CR is - it's someone reviewing your work after you're already done with it, and made a context-switch to a different task, and a different branch. Not a very effective way to ensure code quality.

Automation

Our coding practices evolved during the years. We tackle this problem by creating small commits, ensuring PRs (Pull Requests) are not getting stale and moving a large portion of code quality control to automated tools.

Code styling remarks are a thing of the past. We have linters and prettifiers, which means no more endless debates about code styling. Almost all errors are caught during coding time, and some are automatically fixed.

Most of these tasks already have automated tools that solve them.
Automated tests help verify the correctness of the code and regression.
We have automated checks that verify your code meets the performance metrics.

3rd party tools based on AI are starting to review our PRs automatically, and even create pull requests themselves, keeping industry standards, making patches to close security vulnerabilities, and updating open source packages.

What about code design and architecture?
If you think about it, if you've already written your code, wrote tests, and created a pull request - now it is probably a little too late for someone to suggest that you re-design your code.
Enter design reviews - ask for feedback before you write the code, and not after it.

The future of CRs - continuous review

Despite the current automation, we still do CRs. That's because we always want another pair of eyes on the code, and automation is still basic and can't understand the context of our code. So how will CRs change in the future?

In the future, more and more automation and collaboration will influence our coding environment. Thanks to AI, we will have tools that alert us in real-time if our code is duplicate or inefficient and if it conflicts with some other change that is being written by another developer. They will also suggest better names for our variables and methods and keep them consistent throughout the system.

The timespan between writing code and having it reviewed - by human and machine - will get shorter and shorter until it becomes continuous. The tools that shape our environment will become smarter, more real-time, and more collaborative.

The tools that allow us to collaborate will become more efficient and user friendly and will have a better and more intimate understanding of our work. These tools could, for example, allow us to review the history of comments and discussions around our code, who are the main contributors to it, ask for a review in real-time, and help us schedule the reviews to avoid bottlenecks and outdated branches.

So, unless AI can write code instead of us, and put us all out of work, I anticipate a bright future for developer productivity and happiness, and a future which lets us focus even more on what we like doing best - coding.