Modern Code Review (MCR)

• Modern Code Review (MCR) is a lightweight, tool-mediated, asynchronous peer-review process that inspects proposed code changes to improve quality and foster team collaboration.
• It leverages persistent review artifacts like diffs, inline comments, and CI results to enable defect detection, knowledge sharing, and adherence to coding standards.
• Studies on MCR highlight challenges in reviewer participation, timing, and specialized reviews such as refactoring and security, while emphasizing the integration of AI-assisted tools.

Modern Code Review (MCR) is a lightweight, tool-mediated, asynchronous, change-based peer-review practice in which developers inspect proposed code changes before integration, discuss them through comments and votes, and decide whether a change should be merged, revised, or abandoned. In contrast to formal, meeting-centric inspections, MCR centers on diffs, continuous collaboration, and persistent review artifacts in platforms such as Gerrit, GitHub, GitLab, Bitbucket, Review Board, and Phabricator. Across the literature, its goals extend beyond defect finding to include code quality improvement, knowledge sharing, team awareness, collaborative problem solving, and adherence to coding standards and guidelines (Heumüller, 2021, Badampudi et al., 2024).

1. Process model and operational structure

MCR is typically organized around a submitted change set or patch. In Gerrit-based workflows, a patch is a proposed changeset uploaded to the review server; the patch owner and/or integrators explicitly add invited reviewers, who may respond by leaving a review score such as Code-Review $-2$, $-1$, $+1$, or $+2$, and/or textual comments. A common high-level workflow in the literature is: prepare the change and description, assign reviewers, notify reviewers, inspect diffs, discuss through comments, and decide whether to merge, request more revisions, or abandon the change (Ruangwan et al., 2018, Badampudi et al., 2024).

The operationalization of review activity in empirical MCR research is correspondingly precise. One widely used definition treats an invited reviewer as any human account added via Gerrit’s ReviewerAdded events, excluding bots, and defines participation as leaving at least one Code-Review score or review comment before patch closure. Mere subscription or silent viewing does not count as participation. Review completion time is often formalized as $T = T_c - T_s$, where $T_s$ is the timestamp when the review is created and $T_c$ is the timestamp when the review is completed, meaning that the change is either merged or abandoned (Ruangwan et al., 2018, Chouchen et al., 2021).

This operational focus distinguishes MCR from earlier inspection models. Traditional inspections were formal, structured, and meeting-driven; MCR is asynchronous, tool-assisted, and embedded in routine development. Review artifacts such as diffs, inline comments, patch sets, CI results, and acceptance decisions persist in repositories and can therefore be mined, modeled, and used for retrospective process improvement or automation (Unterkalmsteiner et al., 2024, Davila et al., 2021).

2. Functions, benefits, and socio-technical role

The literature consistently presents MCR as both a quality-assurance mechanism and a socio-technical coordination practice. It is used to improve software quality, reduce post-integration defects, enforce conventions, and scrutinize design and architectural decisions, but it also contributes to knowledge sharing, team awareness, alternative solution discovery, and code ownership. One cited measure of knowledge transfer reports that conducting peer review can increase the number of distinct files a developer knows about by 66–150% depending on the project (Heumüller, 2021).

Empirical syntheses further characterize MCR as a locus where technical and social effects are entangled. Reviewed commits are reported to be less likely to introduce bugs than unreviewed ones, while higher review coverage and participation are associated with better outcomes in several studies. At the same time, MCR provides traceability of rationale, exposes misunderstandings, and distributes architectural and domain knowledge through discussion (Yang et al., 2024, Badampudi et al., 2024).

MCR also interacts closely with surrounding engineering infrastructure. It complements CI/CD pipelines rather than replacing them: passed CI builds increase participation and merging likelihood, and automated analyzers or bots can remove part of the repetitive review burden. Yet the literature repeatedly emphasizes that MCR is not reducible to automated checking, because many review concerns involve rationale, maintainability, design trade-offs, and context that are not fully captured by static rules (Badampudi et al., 2024, Vijayvergiya et al., 2024).

A recurring misconception is that MCR exists primarily to find functionality-blocking bugs. The surveyed literature treats this as incomplete. Reviews are often more influential on evolvability, readability, refactoring quality, standards conformance, and team learning than on the discovery of catastrophic defects alone (Heumüller, 2021, Yang et al., 2024).

3. Participation, reviewer assignment, and review timing

A central MCR problem is not only who should review, but who will actually participate and how long the process will take. In a case study of 230,090 patches across Android, LibreOffice, OpenStack, and Qt, non-response proved common: 16%–66% of patches had at least one invited reviewer who did not respond. The same study found that human factors played an important role in predicting participation decisions, and that reviewer participation rate and code authoring experience were the strongest positive predictors, whereas concurrent workload reduced the likelihood of response. The core predictive formulation was logistic regression,

$$\text{logit}(p)=\ln\left(\frac{p}{1-p}\right)=\beta_0+\sum_i \beta_i X_i,$$

with odds ratios $\text{OR}_i=e^{\beta_i}$ used to interpret effect size (Ruangwan et al., 2018).

This line of work aligns with reviewer recommendation research more broadly. In a corporate Gerrit dataset with 21,796 reviews, features related to code ownership had the best individual prediction power for both reviewer participation and amount of feedback, while all proposed features together with lines of code made the best predictions. The same study reported that training windows of 3, 6, 9, and 12 months produced similar results, implying that short timeframes can suffice for model training with negligible impact on predictive performance (Witter et al., 2023).

Timing has been treated as a separate predictive target. One Gerrit-based framework models review completion time as a regression problem over 50 features spanning date metrics, collaboration graph metrics, code metrics, text metrics, owner experience metrics, and file history metrics. Its explicit outcome variable is $y=T_c-T_s$, measured in hours, with time-aware validation designed to reflect deployment conditions rather than random hindsight evaluation (Chouchen et al., 2021). A related industrial case study at Ericsson proposed Pineapple, a Bayesian Network system that prioritizes incoming review requests by combining merge probability with rule-based grouping on merge conflicts and change type. In live deployment, Pineapple achieved RMSE = 0.21 and MAE = 0.15, while 82.6% of users believed it provides reliable prioritisation results and 56.5% believed it helps reduce code review lead time (Saini et al., 2021).

These results complicate another common assumption: adding more candidate reviewers does not automatically improve responsiveness. Several studies describe overload, low participation, or diffusion of responsibility as consequences of over-broad assignment, suggesting that reviewer selection in MCR is fundamentally a socio-technical resource-allocation problem rather than a simple expertise-matching exercise (Ruangwan et al., 2018, Badampudi et al., 2024).

4. Review criteria for difficult changes: refactoring, smells, and security

Refactoring has become one of the most intensively studied special cases in MCR because it stresses the boundary between structural improvement and behavioral preservation. In OpenStack, a study of 11,010 reviews found that refactoring-related reviews required significantly more effort than non-refactoring reviews across all measured dimensions, including number of reviewers, comments, inline comments, revisions, changed files, review duration, discussion length, description length, and code churn. The same study derived a taxonomy of 28 review criteria grouped into six categories: Quality, Refactoring, Objective, Testing, Integration, and Management (AlOmar et al., 2022).

Industrial evidence from Xerox converges on similar themes but emphasizes documentation. Surveyed developers reported no proper shared procedure for documenting refactoring for review, and the study proposed the “three I’s”—Intent, Instruction, and Impact—as a documentation template. Reported challenges included avoiding regression, understanding quality impact, inadequate documentation, unclear motivation, and difficulty reviewing refactorings in a timely manner (AlOmar et al., 2021).

Refactoring, however, is not uniformly associated with slower review. In Qt, a study of 2,154 reviews showed that refactoring reviews in a dedicated Refactor branch took significantly less time to resolve than both refactoring reviews in other branches and non-refactoring reviews, with fewer comments, fewer inline comments, fewer revisions, and shorter discussions. The same work found that developer intent was documented more sparsely in the Refactor branch and derived a separate taxonomy of 12 refactoring review criteria grouped into Quality, Refactoring mechanics, Objective, and Testing (AlOmar, 2024). This suggests that branch structure and organizational expectations can substantially alter the cost profile of refactoring review.

Code smells are another distinct review target. In a study of OpenStack and Qt communities, 1,539 smell-related reviews were identified from 25,415 manually checked comments, corresponding to approximately 6.05% of the examined comments and about 0.35% of all human comments mined. Smells were therefore not commonly identified in code reviews, but when they were identified, reviewers usually provided constructive feedback, developers generally followed those recommendations, 85% of smells were fixed overall, and 83% of fixes occurred within one week (Han et al., 2022).

Security presents a different pattern. In a survey of 182 practitioners, only 9 respondents explicitly mentioned security when asked openly what they focus on during code review; after security was introduced explicitly, 111 respondents reported that they always consider security during code review. The same study found that most companies expect developers to ensure security, but most do not provide security training, and that lack of training and security knowledge were the main challenges reported by developers (Braz et al., 2022). Security in MCR is therefore simultaneously acknowledged as important and treated as under-supported.

5. Automation, contextual support, and AI-assisted review

The support-system literature has moved from isolated recommenders and visualizations toward increasingly integrated, learning-based review assistance. A classification of 53 research papers identified four major support types for understanding code in MCR: code reorganization, data integration, refactoring support, and change impact analysis. The central critique in that work is that most existing tools provide narrow support along one dimension, whereas reviewers need broader contextualization across code, design, history, requirements, usage, ownership, and CI state; this motivates the proposed vision of contextualized code reviews through a Code Review Contextualizer environment (Unterkalmsteiner et al., 2024).

AI-based support has developed along several fronts. One thesis proposal frames core MCR problems such as reviewer recommendation, prioritization, patch risk prediction, and standards conformance as graph-learning problems, arguing that MCR data is inherently relational and heterogeneous and therefore suitable for graph neural methods (Heumüller, 2021). At a more deployed end of the spectrum, AutoCommenter uses a LLM to learn coding best-practice violations from historical comments linked to guideline URLs. In industrial deployment across C++, Java, Python, and Go, AutoCommenter achieved a useful ratio above 80% in production, covered 68% of historical human comments that include a URL, and showed an estimated resolution rate of about 40%, while 33 of the top 50 frequently predicted best practices were judged to be beyond traditional static analysis scope (Vijayvergiya et al., 2024).

Generative support for reviewer comments has also advanced. CoRAL, a 2025 framework for code review comment generation, combines supervised fine-tuning with reinforcement learning and reward models based on semantic similarity and downstream code refinement usefulness. On its test set, the best variant, CoRAL_crystal, achieved a BLEU median of 8.67 compared with 7.05 for the SFT-only baseline, and in an LLM-as-judge comparison it won 70% of pairwise cases against the SFT baseline and 55% against DISCOREV (Sghaier et al., 4 Jun 2025). Parallel survey work on automating code review emphasizes that evaluation remains highly fragmented: 24 automation studies yielded 48 task–metric combinations, 22 unique to a single paper, with limited dataset reuse and frequent risks of temporal bias (Heumüller et al., 25 Aug 2025).

The dominant methodological trend is therefore not full replacement of human reviewers, but assistive augmentation: prioritizing which changes deserve attention, recommending participants, generating draft comments, predicting completion time, surfacing policy or style violations, and separating semantically different categories of edits such as refactorings and behavior changes. The literature is correspondingly cautious about over-reliance, false positives, and misalignment, and repeatedly advocates human-in-the-loop controls, explanation mechanisms, and rigorous time-aware evaluation (Vijayvergiya et al., 2024, Heumüller et al., 25 Aug 2025).

6. Research landscape, unresolved issues, and emerging directions

Secondary studies show that MCR has become a substantial research area. A preliminary systematic mapping identified 177 papers on MCR between 2005 and 2018 (Badampudi et al., 2023). A later systematic literature review selected 139 papers and organized them into foundational studies, proposals, and evaluations, noting that foundational work was the most represented category and that evaluations of MCR-supporting approaches had been done mostly offline, without involving human subjects (Davila et al., 2021). Subsequent surveys expanded the corpus to 244 primary studies up to and including 2021 and 231 surveyed papers respectively, highlighting both the breadth of the field and a strong recent increase in publication volume (Badampudi et al., 2024, Yang et al., 2024).

These syntheses also identify a recurrent research–practice tension. Practitioners are reported to be positive about research on the impact of MCR on product quality and on process properties, while being negative about much of the human factor- and support systems-related research, indicating a misalignment between the state of the art and the themes deemed important by many respondents (Badampudi et al., 2024). A plausible implication is that MCR research has often been better at describing review phenomena than at delivering interventions that practitioners immediately perceive as useful.

Several limitations recur across the literature. Many empirical studies are concentrated in OSS and Gerrit-based contexts, which constrains external validity. Organizational roles, off-platform communication, and informal coordination are often only partially observable. Automation studies frequently rely on paper-specific datasets, random or underspecified splits, and heterogeneous metrics, which complicates cross-paper comparison and can introduce temporal bias or leakage (Ruangwan et al., 2018, Heumüller et al., 25 Aug 2025). Even where predictive performance is strong, adoption depends on trust, explanation, workload effects, and local policy integration.

Current future directions are comparatively consistent. They include richer contextual review environments, better integration of requirements, ownership, operational data, and CI into review interfaces; time-aware and cross-project evaluation protocols; refactoring-aware and security-aware tooling; explainable AI for prioritization and comment generation; and larger, more extensible datasets that capture end-to-end review processes rather than isolated artifacts (Unterkalmsteiner et al., 2024, Yang et al., 2024). Taken together, these lines of work define MCR not merely as a lightweight gate before merging, but as a central socio-technical mechanism through which contemporary software projects coordinate quality, expertise, and change.