Code review as we know it is almost 20 years old. It's time to evolve.

The traditional pull request (PR) model has been the standard for two decades: developers write code, send it for review, and after iterating on comments, it gets merged. But this approach has a hidden cost: waiting time, late changes, and friction between teams. The proposal is simple and powerful: move code review before the code exists.

What does reviewing before code mean?

Instead of reviewing after writing, you review the design, architecture, and tests before implementation. This is achieved through asynchronous design reviews, where teams comment on design documents, flow diagrams, or even pseudocode. Tools like RFCs, ADRs (Architecture Decision Records), or simple shared documents allow detecting problems before they become costly code to change.

Impact for SysAdmins and DevOps

For system administrators and operations teams, this change drastically reduces failed deployments and maintenance windows. By validating architecture and infrastructure requirements before coding, surprises in production are avoided. Additionally, it aligns with practices like Infrastructure as Code (IaC) and GitOps, where early review of configuration changes prevents incidents. For the business, it translates into shorter time-to-market and lower development costs, since fixing an error in design costs much less than in production.

How to get started

It's not about eliminating PRs, but complementing them. Some practical actions:

• Include a design review phase in the workflow (e.g., before creating the branch).
• Use templates for design documents that include impact on infrastructure, security, and performance.
• Automate diagram generation from design (with tools like Mermaid or PlantUML) to facilitate review.

This approach fits the trend of shifting quality left, which we already apply in testing and security. Now it's time to apply it to code review.

Source: The New Stack. ForgeNEX analysis.