1 Introduction↩︎

Code review is a widely used technique for systematically examining code changes, aiming to increase software quality [1]. Code reviews provide several benefits for the project, including finding bugs, knowledge transfer, and assurance of adherence to project guidelines and coding style [2], [3]. An effective code review depends on active involvement and cooperation between reviewers and code authors. Prior research has identified several key characteristics of high-quality review comments, showing that explanatory feedback and a constructive tone promote understanding, whereas harsh language, superficial critiques, and impractical suggestions hinder knowledge transfer [4]–[6]. Moreover, review comments are perceived as more helpful when they help build positive relationships among developers [7]. However, recent findings by Widyasari et al. [8] indicate that the interpretation of code review explanations can vary substantially across developers. What appears obvious to one developer may not be equally clear to another, which might reflect the underlying cognitive diversity in how developers reason about, process, and act on feedback [9]. This oversight results in a critical research gap since current automated and manual code review systems rarely adapt explanations to individual reviewers’ problem-solving styles (e.g., differences in information processing, learning orientation, and motivation [10], [11]) or experience level (novice vs. expert). As a result, explanations may be misaligned, misunderstood, or even ignored, which leads to increased back-and-forth, slower reviews, and abandoned pull requests [12], [13]. Therefore, a systematic investigation is required to find out the effectiveness of personalized, need-driven code review comments that better support knowledge sharing among developers.

Recent advances in Large Language Models (LLMs) present a promising opportunity to bridge this gap. Prompt-engineered LLMs can generate explanations with varying tones, formats, and levels of detail [14], [15]. When combined with problem-solving profiling approaches such as the GenderMag framework [16], these models can be guided to produce persona-aligned code review explanations tailored to individual differences in problem-solving styles [17], [18].

Our study aims to explore how persona-aligned code review explanations influence developers’ trust, comprehension, and decision-making. Unlike most prior studies that treat developers uniformly and overlook cognitive diversity [6], [19], we build on an initial mixed-methods user study to examine how developers with different problem-solving styles perceive the usefulness and value of GenderMag persona-aligned code review comments. Our goal is to inform the design of inclusive and human-centered AI-assisted code review systems. In this paper, we outline our research goals, present preliminary results from our user study, and discuss the overall impact.

2 Motivational Example↩︎

Fig. 1 (a) illustrates a code review comment from a GitHub pull request [20] that highlights challenges arising from underspecified and cognitively misaligned explanations. The reviewer suggests a design improvement but provides limited context regarding the affected components, the issue location, or the rationale for the suggestion. As a result, the contributor is unable to interpret the feedback and requests clarification. The discussion subsequently shifts away from the original comment without resolving the initial concern, demonstrating how misaligned explanations can hinder effective communication and knowledge transfer in code review.

Fig. 1 (b) [21] represents another example where a contributor requests guidance for resolving a complex issue, reflecting a need for a structured, procedural explanation. The reviewer instead resolves the issue directly and provides a brief, high-level explanation. Although the interaction concludes successfully, it exposes a misalignment between the explanations offered and the developers’ actual needs. These examples motivate the need for adaptive code review explanations tailored to developers’ problem-solving preferences and information requirements.

3 Research Questions and Methodology↩︎

This study aims to establish an empirically grounded understanding of how cognitive diversity shapes developers’ interactions with code review explanations and how this understanding can inform more inclusive code review practices. Rather than assuming that a single explanation type is universally effective, we aim to examine how developers with different problem-solving styles perceive and engage with code review feedback. Thus, we seek to answer the following research questions (RQs):

RQ₁. How do developers’ preferences for code review explanations differ according to their problem-solving style, experience, and roles in the development? Developers vary in how they process information and respond to feedback, suggesting that code review explanations may not be uniformly effective [8], [22]. Problem-solving style, development experience, and role in the review process can each influence the type of explanation developers find most useful. Thus, in this RQ, we aim to examine whether and how these individual differences translate into distinct preferences for code review explanations, informing the design of more adaptive and human-centered review tools.

RQ₂. Which elements of review comments are preferred by developers belonging to different personas? Effective code review comments emphasize different elements, such as explanation depth, conciseness, or learning support, yet it remains unclear whether developers with different problem-solving styles value these elements similarly. Understanding persona-specific preferences is essential for designing effective and inclusive code review feedback.

RQ₃. How do developers perceive the usefulness of adaptive, persona-aware code review tools? While persona-aware code review explanations have the potential to better align feedback with developers’ problem-solving preferences, their practical value depends on how developers and reviewers perceive such adaptation. Understanding whether adaptive, persona-aware review tools are viewed as useful, desirable, or concerning is essential before pursuing broader adoption or tool development. To address these RQs, we adopt a mixed-methods user study to examine developers’ perceptions and assessments of persona-aligned code review explanations. The following sections describe the survey design and the participant recruitment process.

3.1 Survey Design↩︎

We use open, multiple-choice, and 5-point Likert scale questions (from 1-strongly disagree to 5-strongly agree). Below, we briefly explain the survey sections:

Demographics: Participants reported their profession, gender, years of development experience, and frequency of participation as code authors and reviewers.

Problem-solving style assessment: In this section, participants were asked how they behave when they approach unknown technology. The questions were used to evaluate participants’ GenderMag [16] facets. Based on their responses, participants are mapped to GenderMag personas representing different problem-solving profiles. GenderMag is a validated analytical method for identifying inclusivity barriers in software by explicitly considering differences in users’ problem-solving styles. It characterizes variation using three personas, i.e., “Abi",”Pat", and “Tim", across five problem-solving style types: motivation, information processing style, learning style, self-efficacy, and risk attitude. While GenderMag has been applied to evaluate inclusivity issues across various software systems [23], [24], its applicability to developer-facing workflows, such as code review, remains underexplored. In our study, we focus on the two extreme personas, Abi and Tim, which represent opposite ends of the facet spectrum, and use five representative questions from prior work [25] to categorize participants’ problem-solving styles based on their responses.

Code Snippets: Participants were presented with three self-contained code snippets, each accompanied by multiple code review comments addressing the same underlying issues but different in style, level of detail, and guidance. The snippets were selected from prior code review datasets [8] to represent realistic scenarios and required no project-specific knowledge [26], [27]. We conducted a pilot validation with two developers (with 3 and 7 years of development experience) outside the main study to ensure the snippets were understandable and the functionality explanations were accurate. To further reduce ambiguity, we provided a brief lay explanation of each snippet’s functionality.

Code Review Explanation: To generate persona-aligned code review comments, we used ChatGPT (GPT-5.2) with tailored prompts, following prior work [14]. We designed prompts aligned with the GenderMag personas Abi and Tim: Abi-aligned comments provide structured, step-by-step explanations reflecting a process-oriented and risk-averse style, while Tim-aligned comments are concise and action-oriented, encouraging experimentation and autonomy.

Finally, participants were shown the original code review comment along with Abi- and Tim-aligned comments in a randomized order, without any labels indicating their origin. After reviewing each explanation, participants completed a short questionnaire assessing their perceptions, followed by open-ended questions on their preferences, perceived benefits, and concerns regarding persona-aligned code review explanations. After design and proofreading, the survey was piloted with five participants to ensure clarity and understandability. The replication package, including the full survey and prompts used to generate the comments, is available at [28].

3.2 Participants↩︎

Participants were recruited via snowball sampling and were required to have prior experience with code review in academic, industrial, or open-source settings. In the first circulation phase, we received 18 non-empty responses, of which 16 passed attention checks and were included in the analysis. The demographics of our participants are summarized in Table 1. Among the 16 participants, more than half are from academia, with an equal number of novice and expert developers. While 25% of participants are classified as reviewers, equal proportions are authors or contribute similarly as both authors and reviewers. Finally, participants are evenly split between the Tim and Abi personas.

3.3 Data Analysis↩︎

(I) Likert-scale items: We measured participants’ agreement with code review elements, analyzed the data descriptively and visually. The sample was segmented by problem-solving style (Abi vs Tim), development experience (novice vs expert), and role (author vs reviewer). Following Santos et al. [29], we categorized experience on an ordinal scale. Similar to previous studies that used a 5-year cutoff [30], [31], developers with less than 5 years of experience were classified as novices, and those with 5 or more years as experts. Next, participants were classified as authors or reviewers based on which activity they reported performing more frequently, following the frequency distribution by Ebert et al. [32]. Participants who reported equal involvement in both reviewing and authoring code were assigned to a separate category, labeled Both. (II) Open questions: We used open-ended questions to gather deeper insights into participants’ perceptions of adaptive, persona-aware code review tools and qualitatively analyzed their responses.

4 Preliminary Results↩︎

Below, we present results from our ongoing study examining whether personified code review comments can support inclusive code review practices and developers with diverse problem-solving styles.

Note. Dev. = Developers; Acad. = Academic researcher.

Preferences for persona-aligned comments (RQ₁): Table 2 summarizes participants’ preferences for persona-aligned code review comments across three code snippets. We observe early indications that explanation preferences vary across personas, experience levels, and code contributors’ roles. Abi participants selected persona-aligned explanations in roughly half or more of the cases, whereas Tim participants showed lower alignment, particularly for the third code snippet. Differences become more pronounced when divided by development experience. Novice-Abi participants consistently preferred persona-aligned explanations, while novice-Tim participants showed limited alignment. The higher alignment among Novice-Abi participants likely reflects a compound effect of low experience and persona traits. Abi personas have lower self-efficacy and prefer supportive, process-oriented explanations [33], which can reduce cognitive load for novices and make feedback easier to follow. As a result, novice-Abi participants may benefit more from persona-aligned explanations than novice-Tim participants. In contrast, among the expert participants, Tim developers exhibited higher alignment than Abi developers. This result may be explained by Tim’s persona, characterized by high confidence in using technology and a belief in being effective at learning new features independently [34]. The lower alignment observed in Novice-Tim participants may originate from the lack of technical experience needed to fully benefit from Tim-aligned explanations. Whereas expert participants are more likely to find these explanations useful due to their expertise, a tendency also observed in prior studies on code comprehension as well [35]. Role-dependent patterns also indicate diverse preference structures, with participants having both author and reviewer roles showing stronger alignment among Abi participants. However, the results for Both-Tim remain inclusive due to a single participant. Although exploratory and based on a small sample, these findings motivate future large-scale studies and support the vision of an adaptive, persona-aware review system to support diverse developers’ needs.

Preferences in comment elements based on personas (RQ₂): We asked participants to rate their preferred elements in comments. Fig. 2 summarizes the participants’ agreement with different code review comment elements. Among Abi participants, step-by-step explanation, risk awareness, learning-oriented guidance, and practical suggestions received very high agreement, with approximately 80–100% indicating that they agree or strongly agree. However, concise/brief comments receive largely neutral or negative responses. These preferences, particularly step-by-step explanation, align with Abi persona’s process-oriented learning style and lower self-efficacy. Tim participants also show similar responses for learning-oriented comments, risk-aware guidance, and practical suggestions, but exhibit more mixed views on conciseness and direct fixes. These early findings indicate that, regardless of persona, developers tend to value explanatory depth, learning support, practical suggestion and risk awareness more than conciseness.

Perceived usefulness of adaptive code review tools (RQ₃): Most participants expressed a positive view towards a code review tool that adapts comments to individual preferences. Respondents noted that personalization could improve clarity and efficiency by aligning feedback with their problem-solving styles and reducing confusion, especially for novice developers. Several participants highlighted additional perceived benefits, including improved empathy, reduced toxicity, and better support for individuals with specific communication needs, as stated by P8 (an Abi), “Like I said I am autistic so I have very specific communication preferences. So yes, but I am not sure this would help "normal" people.” At the same time, participants raised concerns about over-simplification, loss of diverse perspectives, and the need for transparency and trust in the adaptation logic. Overall, these responses suggest that adaptive code review tools are promising, but their design must carefully balance personalization with correctness and diversity of feedback.

5 Related Work↩︎

Prior work has examined modern code review practices and effective review comments, showing that explanatory and constructive feedback supports developer understanding, while shallow or harsh comments hinder learning [4], [8], [36]. Other studies categorize review comment intents such as suggestions, defect identification, educational guidance, and design feedback [6], [19], [37], but largely assume that such comments are interpreted uniformly by developers. In parallel, research has addressed diversity gaps by modeling problem-solving styles with the GenderMag framework to identify inclusivity issues in software systems [25], [33], [38]–[40]. More recently, studies have begun exploring LLMs’ ability to support developers’ diverse learning styles [15] and have shown that GenderMag can effectively guide LLMs to account for cognitive diversity in designing more inclusive explanations [14], [22].

Building on these works, we examine how developers with different problem-solving styles perceive persona-aligned code review explanations, motivating adaptive and inclusive review practices.

6 Conclusion and Future Plan↩︎

In this paper, we presented a vision for more effective and inclusive code review practices that account for developers’ diverse problem-solving styles. Our preliminary results provided early evidence that developers’ preferences for explanations vary across problem-solving styles, experience levels, and roles. Our future work will focus on RQ1 and RQ2 to examine persona-aligned explanation preferences across problem-solving styles, while further exploring the feasibility of practical tools (RQ3) to support diverse developer needs. We seek to accommodate the following implications:

Personalized developers support. We plan to recruit more participants to investigate further how persona-aligned code review explanations influence developers’ productivity, trust, and decision-making, with more detailed statistical analyses to be reported in a subsequent full paper. This work has the potential to improve accessibility and inclusivity in code review, particularly for developers with specific cognitive or communication needs.

Guiding coding agents toward adaptive reviews. Future studies will explore how development experience (novice vs. expert) and review roles (authors vs. reviewers) interact with problem-solving personas. These insights can guide AI-based code review tools and coding agents toward adaptive, persona-aware feedback. Extending to tool prototyping and feasibility evaluation. We plan to design and evaluate a prototype for generating persona-aware code review comments grounded in developers’ observational history and GenderMag personas. We will collect user feedback on the tool’s design and preferred features. The tool will leverage prior interaction patterns, including preferred explanation styles and gaps between provided and preferred comments. We will evaluate usability, perceived usefulness, and workflow integration to assess support for diverse problem-solving styles.

References↩︎