CRDM: Code Review as Decision-Making

• CRDM is a cognitive framework that redefines code review as a goal-directed process where understanding, experience, and pattern recognition guide decisions.
• The model is built on ethnographic think-aloud studies and process coding, revealing how reviewers transition from context-building to iterative analytical assessment.
• CRDM informs tool design and automation by recommending integrated dashboards and decision-support features to enhance reviewer judgment and mitigate biases.

Code Review as Decision-Making (CRDM) is a cognitive model that explains code review not just as “reading diffs and finding bugs,” but as a structured decision-making process driven by experience, pattern recognition, and iterative assessment. It formalizes how reviewers move from first seeing a change to ultimately deciding how to comment and how to vote, and it connects this process explicitly to recognition‑primed decision‑making (RPD) from cognitive psychology. In this formulation, comprehension is necessary but not sufficient: understanding the change is a prerequisite for deciding whether to review now or later, whether more context is needed, whether the implementation is acceptable, which issues merit comments, whether to rerun continuous integration or run code locally, and how to vote (Heander et al., 13 Jul 2025).

1. Conceptual foundation

CRDM begins from three premises. First, code review is treated as intentional, goal-directed behavior in the sense of the theory of planned behavior: opening a change, reading a file, writing a comment, running tests, and choosing a vote are analyzed as purposeful actions. Second, explicit and implicit questions asked during review are taken to reveal the reviewer’s current cognitive goals, uncertainties, and decisions, in a way inspired by Letovsky’s work on program comprehension. Third, decision-making theories apply: when review activity is analyzed closely, reviewers appear to recognize patterns, form expectations, mentally simulate consequences, and then take the first action that seems “good enough” (Heander et al., 13 Jul 2025).

This framing does not replace code comprehension models. Rather, it places comprehension inside a larger decision process whose output is not merely understanding but action. The relevant questions are therefore not only how a reviewer constructs a mental model of a change, but also whether the change should be reviewed now or later, whether the rationale is adequate, whether the implementation is acceptable for the project’s goals and risks, and whether comments, local execution, CI verification, or particular votes are warranted (Heander et al., 13 Jul 2025). Related observational work on code review comprehension likewise described a context-building phase, code inspection, and decision, and emphasized opportunistic strategies and the construction of expected and ideal mental models against which the actual implementation is evaluated (Gonçalves et al., 27 Mar 2025).

2. Empirical basis and model construction

CRDM was built from an ethnographic think-aloud study involving 10 participants and 34 real code reviews in a multinational software company’s tools department. The participants were professional developers, architects, and team leads with an average of 8 years of code review experience. Review durations ranged from 1 to 75 minutes, with a mean of 19 minutes, and voting outcomes covered the full range $(–1, \pm0, +1, +2)$, often with comments. Researchers sat physically next to participants at their normal workstation and asked them to think aloud while performing their normal reviews (Heander et al., 13 Jul 2025).

The data collection and analysis pipeline combined qualitative and quantitative elements. Sessions and follow-up interviews were audio-recorded, manually transcribed in Swedish with software engineering terminology, and validated through a member-checking focus group with 6 participants. The transcripts were coded using process coding, yielding 157 distinct process codes applied to 1,159 coded segments. These codes were grouped into 7 themes and then into 2 higher-level topics: three orientational themes and four analytical themes. The authors then normalized each review to a timeline from 0 to 1, computed theme distributions across that timeline, constructed a transition probability table between themes, and derived a state-transition diagram (Heander et al., 13 Jul 2025).

The result was a clear two-phase pattern. Related observational work on 25 real code reviews, also based on think-aloud observation and interviews with experienced reviewers, independently identified context building, code inspection, and decision, and argued that review work is opportunistic rather than uniformly linear (Gonçalves et al., 27 Mar 2025). This convergence strengthens the claim that CRDM captures more than an idiosyncratic local workflow.

3. Structure of the model

CRDM consists of two linked phases: an orientation phase that establishes context, expectations, and rationale, and an analytical phase that iteratively develops understanding, assessment, and next-step planning. The orientation phase is described as linear, with reviewers moving forward through three themes and rarely going back. The analytical phase is iterative and cyclic, with repeated movement among four themes until a final decision is reached (Heander et al., 13 Jul 2025).

Phase	Theme	Core cognitive question
Orientation	Selecting a review task	“Which change should I review now?”
Orientation	Understanding context	“Where does this change live, and in what environment?”
Orientation	Understanding rationale	“Why does this change exist? What problem or goal does it address?”
Analytical	Understanding implementation	“How does this code actually behave?”
Analytical	Assessing implementation	“Is this a good, safe, idiomatic way to implement this?”
Analytical	Assessing change	“Given the bigger system and environment, is this change acceptable?”
Analytical	Selecting next action	“What should I do next with what I now know?”

The orientation phase foregrounds time availability, urgency, social considerations, reviewer expertise, repository and component context, author identity and habits, patchset history, commit messages, linked issues, requirements, and prior team discussions. These orientational themes cluster early in the review, with mean normalized timestamps around $0.2$ to $0.3$, and transitions are strongly forward: selecting a task, then context, then rationale. Once reviewers move into rationale, they almost never go back to selecting another change unless they abandon the review (Heander et al., 13 Jul 2025).

The analytical phase distributes across the middle and end of the review, with mean normalized timestamps around $0.5$ to $0.6$. Here reviewers trace execution flow, inspect calls and data structures, compare before-and-after diffs, assess correctness, readability, conventions, APIs, patterns, tests, risks, performance, scalability, interoperability, and long-term architectural fit. The “selecting next action” theme is central in the transition network, because reviewers repeatedly decide whether to navigate further, write a comment, consult external sources, run code or tests locally, verify CI, or cast a vote (Heander et al., 13 Jul 2025).

Interrupted reviews further illustrate the model’s dynamics. When resuming, in about two-thirds of cases reviewers jump directly back into assessing implementation or selecting next action, whereas in about one-third of cases they restart reading from the beginning to reconstruct the mental model before making a decision (Heander et al., 13 Jul 2025). This pattern supports the claim that review is not merely linear diff scanning but a cognitively organized activity dependent on maintaining a coherent internal representation of code and context.

4. Recognition-primed decision-making and classes of decision

Klein’s RPD model describes how experienced decision-makers operate under time pressure by recognizing situations through cues and patterns, generating expectancies, relevant cues, plausible goals, and typical actions, mentally simulating candidate actions, and then executing the first action that seems “good enough.” CRDM maps code review onto this framework in two steps. The orientation phase corresponds to the front half of RPD, in which reviewers experience the situation, recognize similarities and differences, and elicit expectancies, plausible goals, and plausible actions. The analytical phase corresponds to a full RPD cycle repeatedly executed while reading diffs and CI outputs in light of the established story (Heander et al., 13 Jul 2025).

Several decision classes are explicit in the empirical material. There are task-level decisions, such as which review to pick next and how much time to allocate now versus later. There are information-seeking decisions, such as whether to open the issue tracker, documentation, CI logs, patchset history, or previous comments, and whether to run code locally or rely on automated tests. There are interpretation and assessment decisions about ambiguous or complex code, implementation acceptability, and global risk. There are communication decisions about whether to write a comment at all, how detailed or soft it should be, and whether an issue belongs in code review or another channel. Finally, there are outcome decisions about votes such as $(–2, –1, \pm0, +1, +2)$, including whether to approve despite minor outstanding issues under local conventions of trust and process guarantees (Heander et al., 13 Jul 2025).

A plausible implication is that CRDM provides a general umbrella for narrower automated decision tasks. One line of work formalizes early prediction of merged versus abandoned code changes from 25 features spanning reviewer, author, project, text, and code dimensions; the best model, a LightGBM-based classifier, achieves around 85% AUC on average and identifies reviewer dimensions as the most informative (Islam et al., 2019). Another line of work formulates the binary triage problem “does this code change require manual review?” and reports comparable performance for classifiers trained on real C++ data and on synthetic C++ data translated from Java, with held-out real C++ results around Accuracy $0.65$, Precision $0.65$, Recall $0.68$, and $F1$ $0.2$0 for the synthetic setting (Cohen et al., 5 Sep 2025). These systems model narrower decision boundaries inside the larger CRDM process rather than replacing it.

5. Tool support, automation, and process design

CRDM directly motivates changes in tool design and review process. Current GitHub- and Gerrit-style interfaces are centered on textual diffs and inline comments. That supports understanding implementation and assessing implementation, but offers weak support for orientation and for the metacognitive work of selecting the next action. As a consequence, reviewers must manually orchestrate a multi-tool workflow across issue trackers, CI dashboards, team chat, documentation, and local development environments (Heander et al., 13 Jul 2025).

Using CRDM as a design lens yields several concrete features. For the orientation phase, tools can provide review selection dashboards surfacing priority, age, size, risk indicators, and “who is waiting on you” cues; context panels showing linked issues, recent related changes, and architectural location; and rationale summarization from commit history, issue text, and code changes. For the analytical phase, tools can provide integrated decision-support views inspired by Integrated Decision Support Systems, combining code diff, run-time monitoring, logs, and test results; impact-scope visualization; progress tracking over what has been inspected and what remains; and action recommendations that highlight likely risks or missing tests without replacing the reviewer’s judgment (Heander et al., 13 Jul 2025).

The model also informs adjacent strands of automation research. Example-based explanation systems such as EDRE aim to detect unclear review comments and retrieve similar, clearer examples; in an industrial study over 3,722 code reviews, TF–IDF with an SVM classifier achieved 92% F-score and 90% Accuracy for identifying comment clarity, and the retrieved examples were intended to reduce communication overhead in understanding review decisions (Rahman et al., 2022). Work on automatic review-comment generation has also moved toward explicitly decision-oriented objectives: CoRAL treats comment generation as a reinforcement-learning problem with rewards based on semantic similarity and usefulness for downstream code refinement, and its CrystalBLEU-based variant achieved a median BLEU of 8.67 compared with 7.05 for supervised fine-tuning and 7.51 for DISCOREV, while winning 70% of pairwise LLM-as-judge comparisons against the supervised baseline and 55% against DISCOREV (Sghaier et al., 4 Jun 2025). Evaluation work such as DeepCRCEval further argues that less than 10% of benchmark comments are high quality for automation and proposes nine criteria—readability, relevance, explanation clarity, problem identification, actionability, completeness, specificity, contextual adequacy, and brevity—as a more decision-relevant basis for assessing generated comments (Lu et al., 2024).

At the organizational level, scorecard-style monitoring systems extend CRDM from individual cognition to managerial governance. An industrial experience report at Samsung Research Bangladesh defines metrics such as Comment Usefulness Density, Issue Density, Review Efficiency, and Review Impact, automates usefulness classification, and reports that managers and developers found the resulting dashboard useful for day-to-day decision making about reviewer recognition, project monitoring, and improvement opportunities (Hasan et al., 2021). This suggests that CRDM can operate simultaneously as a cognitive model of individual review episodes and as a framework for process-level decision support.

6. Limitations, controversies, and broader significance

The original CRDM study is explicit about its limits. All participants came from one multinational company’s tools department in Sweden, used Gerrit with a specific voting setup, shared similar educational backgrounds and Swedish nationality, and were likely more communicative and reflective than average because they volunteered and worked in an outward-facing department. The think-aloud protocol and physical observation may also have led to more careful and explicit reviewing than usual. For these reasons, CRDM is presented as a theoretical model that is well-grounded in this specific context, consistent with existing comprehension research and broader decision-making literature, but still in need of further empirical testing across domains, languages, organizations, and toolchains (Heander et al., 13 Jul 2025).

A central controversy concerns automation. CRDM explicitly warns that fully automating code review risks erasing interpersonal benefits such as knowledge transfer, shared ownership, and social cohesion (Heander et al., 13 Jul 2025). A survey of 92 professional developers across SAP, Ericsson, a large European bank, and JetBrains similarly treats code review as a socio-technical practice concerned with maintainability, accountability, ownership, and governance, and reports that 47.3% expect to spend more time on review in 5 years, 30.8% expect about the same, and 22.0% expect less. That work frames future AI involvement along two dimensions—human versus LLM author and human versus LLM reviewer—and warns of erosion of understanding, accountability, and trust if review becomes an “empty shell” of rubber-stamped AI output (Dorner et al., 9 Aug 2025). A later agentic vision therefore proposes an AI-powered workflow across PR creation, PR augmentation, reviewer selection, AI-assisted code review, and PR retrospective, but retains humans at key decision points to preserve judgment, accountability, and team-level understanding (Kamalı et al., 17 May 2026).

Bias and conflict further complicate the decision picture. A proposal on automatic bias detection in source code review treats review as a bounded human decision process and suggests modeling gaze trajectories with the “spotlight model of attention” plus Markov Models, Recurrent Neural Networks, and Conditional Random Fields to detect potentially biased interactions (Alebachew et al., 25 Apr 2025). Complementary debiasing prototypes for confirmation bias and decision fatigue show that some techniques could be implemented in existing review tools and were well accepted by reviewers (Jetzen et al., 2024). Interpersonal-conflict research likewise argues that conflicts during code review are commonplace, anticipated, and seen as normal; although they can have negative effects, they can also create value and bring improvement if resolved constructively (Gonçalves et al., 2022). These findings suggest that CRDM should not be read as a purely technical or purely individual model, but as a socio-technical account of decisions made under uncertainty, under norms, and often under interpersonal tension.

The broader literature indicates that CRDM is especially useful where review criteria become complex and multi-objective. In scientific software, just-in-time review of small code changes is reported as more likely to succeed than large-scale end-of-work reviews, which suggests that decision quality depends strongly on review granularity and timing (Petre et al., 2014). In industrial and open-source studies of refactoring review, reviewers rely on explicit criteria such as regression risk, test adequacy, quality impact, change scope, and backward compatibility, and refactoring reviews take significantly longer and generate more discussion than non-refactoring reviews (AlOmar et al., 2021, AlOmar et al., 2022). These neighboring results are consistent with the CRDM claim that code review is a multi-criteria decision process rather than a single act of defect spotting.

Taken together, CRDM reframes code review as a decision-making activity under uncertainty in which comprehension, pattern recognition, mental simulation, communication, and voting are tightly coupled. Its primary contribution is not to deny the importance of understanding code, but to specify that understanding is mobilized in service of situated decisions: what to inspect, what to ask, what to trust, what to test, what to comment on, and what to approve.