Pith. sign in

REVIEW 3 major objections 6 minor 46 references

From Generic to Personalized: Exploring Persona-Aware Code Review Explanations

T0 review · 3 major / 6 minor · reviewed 2026-07-13 · grok-4.5

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Developers prefer different styles of code-review explanations depending on problem-solving style, experience, and role; depth, learning support, practical suggestions, and risk awareness beat brevity.

desk verdict Honest workshop pilot with a real idea and thin data: persona-aligned review comments are worth exploring, but the preference claims rest on unvalidated stimuli and n=16. read the letter →

arxiv 2607.08990 v1 pith:CNIWWJPW submitted 2026-07-09 cs.SE

Shamse Tasnim Cynthia , Ratnadira Widyasari , Banani Roy , Italo Santos , David Lo This is my paper · ORCID
classification cs.SE
keywords codereviewpersona-awareexplanationsproblem-solvingstylesAI-assistedhuman-centeredsoftwareengineeringdeveloperpreferencesinclusivetools
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Code reviews often fail not because the feedback is wrong, but because different developers process the same comment differently. This paper argues that review comments can be written to match distinct problem-solving profiles, so that the same issue is explained in a process-oriented, risk-aware way for some people and a concise, action-oriented way for others. In an early mixed-methods study, developers rated original comments against two persona-aligned variants across several code snippets. Preferences shifted with problem-solving style, years of experience, and whether the person mainly authors or reviews code. Across those groups, people still wanted explanatory depth, learning support, practical fixes, and risk awareness more than pure brevity. The authors treat these results as early evidence for AI review tools that adapt feedback to the reader instead of emitting one generic style for everyone.

What carries the argument

Persona-aligned review comments: the same underlying issue is rewritten once in a structured, step-by-step, risk-averse style and once in a concise, action-oriented style, then shown unlabeled so developers can choose which explanation they prefer and rate which comment elements matter.

What would settle it

A larger study in which the two rewritten comment styles are matched for length, technical accuracy, and helpfulness would show no reliable difference in choice rates by problem-solving style, experience, or role, and no shared preference for depth and risk awareness over brevity.

Watch

Extended reading notes

Core claim

Preferences for code-review explanation style are not uniform: they vary with problem-solving style (process-oriented versus autonomy-oriented), experience (novice versus expert), and role (author, reviewer, or both). Across those profiles, developers consistently valued step-by-step depth, learning support, practical suggestions, and risk awareness more than conciseness, and most viewed adaptive persona-aware tools as useful if personalization stays transparent and correct.

Load-bearing premise

The survey questions and the generated comment variants must cleanly capture opposite problem-solving styles rather than mainly differing by length, tone, or generic helpfulness; otherwise choosing a comment cannot be read as a true persona preference.

Editorial extensions

If this is right

  • Adaptive review tools should tailor explanation style to problem-solving profile, experience, and role rather than emit one default voice.
  • Comment generators should prioritize explanatory depth, learning support, practical suggestions, and risk awareness even when personalizing.
  • Novice process-oriented developers and expert autonomy-oriented developers are the clearest early targets for different explanation styles.
  • Tool design must keep adaptation transparent so trust and correctness are not traded away for personalization.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If personalization is driven only by static survey personas, it may underperform relative to tools that learn preferred style from a developer's past review interactions.
  • The same preference structure could transfer to other developer-facing feedback, such as static-analysis warnings or AI coding-agent explanations.
  • Teams that standardize on brief, action-only review comments may systematically underserve process-oriented or lower-experience developers.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 6 minor

Summary. This manuscript presents preliminary findings from an ongoing mixed-methods user study (n=16 after attention checks) on persona-aware code review explanations. Using GenderMag facets, participants are mapped to Abi and Tim problem-solving personas; ChatGPT generates Abi-aligned (structured, process-oriented, risk-averse) and Tim-aligned (concise, action-oriented) comments for three code snippets, presented unlabeled with the original comment. RQ1 reports descriptive preference rates for persona-aligned comments by persona, experience (novice/expert at a 5-year cutoff), and role; RQ2 reports Likert preferences for comment elements (depth, learning support, practical suggestions, risk awareness vs. conciseness); RQ3 summarizes open-ended views on adaptive tools. The authors outline a vision for inclusive, human-centered AI-assisted code review that adapts feedback to problem-solving styles, with plans for larger samples, statistical analysis, and a prototype.

Significance. If the preference patterns hold under stronger validation and larger samples, the work would matter for inclusive software engineering and for the design of LLM-based review agents: it would motivate moving beyond one-size-fits-all review comments toward feedback that accounts for cognitive diversity (GenderMag-style problem-solving styles), experience, and role. Strengths include a clear problem motivation with concrete GitHub misalignment examples, explicit research questions, a publicly linked replication package (survey and prompts), transparent hedging as preliminary/ongoing work, and a concrete future plan (more participants, role imes persona interactions, prototype grounded in interaction history). The contribution is currently a vision-plus-early-evidence piece rather than a definitive empirical result.

major comments (3)
  1. §3.1 (Code Review Explanation) and §4 (RQ1–RQ2): The central interpretation—that selecting a comment or rating elements reflects GenderMag persona alignment—requires that GPT-generated Abi vs. Tim comments cleanly and differentially instantiate the intended facets. The manuscript describes prompt intent and unlabeled randomized presentation but reports no independent validation (e.g., expert or participant ratings of process-orientation, risk language, autonomy encouragement; length/structure matching; or non-persona helpfulness-matched baselines). Without this, Table 2 alignment rates and Fig. 2 element preferences may be driven by confounds (longer structured text, more risk language, more practical suggestions) rather than persona match. This is load-bearing for the persona-preference claim and should be addressed with a stimuli check or controlled baselines before stronger claims.
  2. Table 2 and §3.2–§3.3: With n=16 and several sparse cells (e.g., Both–Tim effectively n=1 with 0% across snippets; multiple 0% role×persona cells), the reported percentage patterns cannot support stable subgroup claims about persona×experience or persona×role differences. The text already notes exploratory status, but RQ1 answers and the abstract still frame preferences as varying across these factors. Either enlarge the sample and add appropriate inferential or uncertainty reporting, or substantially soften subgroup language and treat Table 2 as purely illustrative pending the planned larger study.
  3. §3.1 and free design choices: Experience is dichotomized at 5 years, personas are reduced to the two extremes Abi/Tim via five items from prior work, and comments are generated with fixed LLM prompt templates. These are reasonable starting points but are free parameters that affect mapping and stimuli. The manuscript should justify or sensitivity-check the cutoff and mapping (or report continuous facet scores), and state more clearly that focusing on extremes is a deliberate scope limit rather than a claim that intermediate styles (e.g., Pat) are unnecessary for adaptive review design.
minor comments (6)
  1. Front matter / ACM block: Copyright year and reference year appear as 2018 while the venue is JAWs 2026; fix template leftovers (also 'JA Ws' spacing in the header).
  2. §3.1: State model version and temperature/settings used for generation more precisely if available, and note whether comments were edited post-generation for correctness so readers can assess fidelity to the LLM output.
  3. Fig. 2: Ensure axis labels, sample sizes per persona panel, and the exact Likert wording are readable in the final layout; currently the narrative must carry most of the interpretation.
  4. §4 RQ1 text: 'Both–Tim remain inclusive due to a single participant' appears to mean 'inconclusive'; correct wording.
  5. Related Work §5: A short explicit contrast with non-persona personalization (e.g., experience- or expertise-only adaptive explanations) would sharpen novelty relative to recent LLM explanation work already cited.
  6. Table 1 / demographics: Report gender distribution if collected (demographics section says gender was asked) or state why it is omitted, given GenderMag framing.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: empirical preference study whose claims rest on participant choices, not on definitions or self-forced predictions.

full rationale

This paper reports preliminary results from a mixed-methods user study (n=16) in which developers are classified via GenderMag-style items, shown unlabeled original/Abi/Tim-aligned review comments generated by GPT prompts, and asked for preferences and element ratings (RQ1–RQ3, §3–§4, Tables 1–2, Fig. 2). The central claims—that preferences vary by problem-solving style, experience, and role, and that depth/learning/risk/practical elements are valued over conciseness—are observational summaries of those responses, not quantities derived from equations, fitted parameters, or uniqueness theorems. GenderMag personas and the five facet questions are imported from external validated work (Burnett et al.); comment generation is described as prompt engineering aligned to those personas, then judged by participants. Self-citations (e.g., Widyasari et al. [39] on varying interpretation of explanations, Santos et al. on experience cutoffs) supply motivation and methodological conventions but do not define or force the preference percentages or Likert distributions. There is no self-definitional loop, no fitted input renamed as prediction, no load-bearing uniqueness theorem from the authors, and no renaming of a known result as a new derivation. Validity concerns about whether the generated comments cleanly instantiate Abi vs Tim (length, structure, helpfulness confounds) are real but belong to construct validity, not circularity. The derivation chain is therefore self-contained against its own empirical inputs; score 0 is appropriate.

Assumptions & free parameters 3 free parameters · 4 assumptions · 1 invented entities

The load-bearing structure is methodological rather than mathematical: GenderMag extremes are treated as the right cognitive axes for review feedback; a 5-year experience cut and frequency-based role labels define subgroups; LLM prompts are assumed to operationalize personas. No physical constants or fitted scientific parameters appear; free choices are design decisions that shape the measured ‘preferences’.

free parameters (3)
  • experience_cutoff_years
    Novice vs expert split uses a 5-year threshold following prior SE studies; this hand-chosen cut drives the experience-segmented preference claims in Table 2.
  • GenderMag_five_item_mapping
    Five representative questions from prior work map participants to Abi vs Tim; item choice and scoring thresholds are design parameters that define the independent variable.
  • LLM_persona_prompt_templates
    ChatGPT (GPT-5.2) prompts define what counts as Abi- vs Tim-aligned comments; prompt wording is a free design choice that determines the stimuli participants judge.
assumptions (4)
  • domain assumption GenderMag facets (motivation, information processing, learning style, self-efficacy, risk attitude) are relevant axes of cognitive diversity for interpreting code-review explanations.
    Invoked in §1 and §3.1 as the basis for persona-aligned comments; GenderMag was developed for software inclusivity, not specifically validated for review-comment comprehension.
  • ad hoc to paper Focusing on the two extreme personas Abi and Tim is sufficient to study problem-solving style differences in this setting.
    Stated in §3.1; intermediate Pat persona and continuous facet scores are set aside.
  • domain assumption Self-contained snippets from prior datasets plus lay functionality notes are adequate proxies for real review contexts.
    §3.1 Code Snippets; reduces ecological validity risk but assumes preferences transfer to project-specific reviews.
  • domain assumption Role can be coded from self-reported frequency of authoring vs reviewing (author / reviewer / both).
    §3.3 following Ebert et al.; used for Table 2 role splits.
invented entities (1)
  • persona-aligned (Abi/Tim) code review explanations as a first-class adaptive feedback object
    purpose: Operationalize cognitive diversity in review comments via LLM generation for preference measurement and future tools.
    The paper’s core construct; not a new physical entity, but a design object whose validity depends on prompt fidelity and GenderMag transfer to review.

how reviews work

0 comments
Cite this review

Pith. "Pith review of From Generic to Personalized: Exploring Persona-Aware Code Review Explanations." pith.science (2026). https://pith.science/paper/CNIWWJPW

@misc{pith2026260708990,
  author       = {Pith},
  title        = {Pith review of: From Generic to Personalized: Exploring Persona-Aware Code Review Explanations},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/CNIWWJPW}},
  note         = {Machine review of arXiv:2607.08990}
}
read the original abstract

Code review is essential for ensuring software quality and supporting collaboration, yet prior work shows that developers can interpret code review comments differently. These differences can hinder effective communication, particularly in collaborative settings. To address this challenge, we explore the potential of personified code review explanations. We report initial findings from an ongoing mixed-methods user study in which developers evaluated persona-aligned review comments across multiple code snippets. Our results suggest that preferences for explanation styles vary across problem-solving styles, experience levels, and roles. Across problem-solving style profiles, developers valued explanatory depth, learning support, practical suggestions, and risk awareness over conciseness, highlighting the need to balance personalization with clarity and trust. Based on these findings, we outline a vision for inclusive, human-centered AI-assisted code review systems that adapt feedback to developers' problem-solving preferences.

Figures

Figures reproduced from arXiv: 2607.08990 by the authors.

Figure 1
Figure 1. Example of code review comments misaligned with [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Distribution of participants’ preferences for code [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

46 extracted references · 2 linked inside Pith

  1. [1]

    Adam Alami, Nathan Cassee, Thiago Rocha Silva, Elda Paja, and Neil A Ernst. 2025. Engagement in Code Review: Emotional, Behavioral, and Cognitive Dimensions in Peer vs. LLM Interactions.arXiv preprint arXiv:2512.05309(2025)

    arXiv 2025

  2. [2]

    Andrew Anderson, Jimena Noa Guevara, Fatima Moussaoui, Tianyi Li, Mihaela Vorvoreanu, and Margaret Burnett. 2024. Measuring user experience inclusivity in human-AI interaction via five user problem-solving styles.ACM Transactions on Interactive Intelligent Systems14, 3 (2024), 1–90

    2024

  3. [3]

    Andrew Anderson, David Piorkowski, Margaret Burnett, and Justin Weisz. 2025. An LLM’s Attempts to Adapt to Diverse Software Engineers’ Problem-Solving Styles: More Inclusive & Equitable?arXiv preprint arXiv:2503.11018(2025)

    arXiv 2025

  4. [4]

    Anonymous. 2024. FitFlex Pull Request #30. https://github.com/Open-Code- Crafters/FitFlex/pull/30. GitHub pull request. Accessed: 2026-01-19

    2024

  5. [5]

    Anonymous. 2024. Fix hide calender icon if no deadline on task (Pull Request #7465). GitHub pull request in twentyhq/twenty. https://github.com/twentyhq/ twenty/pull/7465 Merged Oct 10, 2024. Accessed Jan 19, 2026

    2024

  6. [6]

    From Generic to Personalized: Exploring Persona-Aware Code Review Explanations

    Anonymous. 2026. Replication Package for "From Generic to Personalized: Exploring Persona-Aware Code Review Explanations". https://anonymous.4open. science/r/Personified-Code-Review-5F54/README.md

    2026

  7. [7]

    Gabriele Bavota and Barbara Russo. 2015. Four eyes are better than two: On the impact of code reviews on software quality. In2015 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 81–90

    2015

  8. [8]

    Amiangshu Bosu, Jeffrey C Carver, Christian Bird, Jonathan Orbeck, and Christo- pher Chockley. 2016. Process aspects and social dynamics of contemporary code review: Insights from open source development and industrial practice at microsoft.IEEE Transactions on Software Engineering43, 1 (2016), 56–75

    2016

Show all 46 references
  1. [9]

    Michelle Brachman, Arielle Goldberg, Andrew Anderson, Stephanie Houde, Michael Muller, and Justin D Weisz. 2025. Towards Personalized and Contextual- ized Code Explanations. InAdjunct Proceedings of the 33rd ACM Conference on User Modeling, Adaptation and Personalization. 120–125

    2025

  2. [10]

    Margaret Burnett. 2021. From GenderMag to InclusiveMag: A Journey for Uni- versity IT. InProceedings of the 2021 ACM SIGUCCS Annual Conference. 1–2

    2021

  3. [11]

    Margaret Burnett, Anicia Peters, Charles Hill, and Noha Elarief. 2016. Finding gender-inclusiveness software issues with GenderMag: A field investigation. In Proceedings of the 2016 CHI conference on human factors in computing systems. 2586–2598

    2016

  4. [12]

    Margaret Burnett, Simone Stumpf, Jamie Macbeth, Stephann Makri, Laura Beck- with, Irwin Kwan, Anicia Peters, and William Jernigan. 2016. GenderMag: A method for evaluating software’s gender inclusiveness.Interacting with computers 28, 6 (2016), 760–787

    2016

  5. [13]

    Junkai Chen, Zhenhao Li, Qiheng Mao, Xing Hu, Kui Liu, and Xin Xia. 2025. Understanding Practitioners’ Expectations on Clear Code Review Comments. Proceedings of the ACM on Software Engineering2, ISSTA (2025), 1257–1279

    2025

  6. [14]

    Rudrajit Choudhuri, Bianca Trinkenreich, Rahul Pandita, Eirini Kalliamvakou, Igor Steinmacher, Marco Gerosa, Christopher Sanchez, and Anita Sarma. 2025. What Needs Attention? Prioritizing Drivers of Developers’ Trust and Adoption of Generative AI.arXiv preprint arXiv:2505.17418(2025)

    2025

  7. [15]

    Faith Culas, Amisha Singh, Atharva Arankalle, Priyanka Dhopade, and Kelly Blincoe. 2025. Newcomers’ experiences during debugging: A cognitive inclusivity perspective using GenderMag.Information and Software Technology(2025)

    2025

  8. [16]

    Rodrigo Magalhães dos Santos and Marco Aurélio Gerosa. 2018. Impacts of coding practices on readability. InProceedings of the 26th conference on program comprehension. 277–285

    2018

  9. [17]

    Felipe Ebert, Fernando Castor, Nicole Novielli, and Alexander Serebrenik. 2021. An exploratory study on confusion in code reviews.Empirical Software Engineer- ing26, 1 (2021), 12

    2021

  10. [18]

    Eduardo Guerra, Everaldo Gomes, Jeferson Ferreira, Igor Wiese, Phyllipe Lima, Marco Gerosa, and Paulo Meirelles. 2024. How do annotations affect Java code readability?Empirical Software Engineering29, 3 (2024), 62

    2024

  11. [19]

    Mariam Guizani, Igor Steinmacher, Jillian Emard, Abrar Fallatah, Margaret Bur- nett, and Anita Sarma. 2022. How to debug inclusivity bugs? a debugging process with information architecture. InProceedings of the 2022 ACM/IEEE 44th Interna- tional Conference on Software Engineer...

    2022

  12. [20]

    Md Montaser Hamid, Amreeta Chatterjee, Mariam Guizani, Andrew Anderson, Fatima Moussaoui, Sarah Yang, Isaac Escobar, Anita Sarma, and Margaret Burnett

  13. [21]

    InEquity, diversity, and inclusion in software engineering: Best practices and insights

    How to measure diversity actionably in technology. InEquity, diversity, and inclusion in software engineering: Best practices and insights. Apress Berkeley, CA, 469–485

  14. [22]

    Sonja M Hyrynsalmi, Sebastian Baltes, Chris Brown, Rafael Prikladnicki, Gema Rodriguez-Perez, Alexander Serebrenik, Jocelyn Simmonds, Bianca Trinkenreich, Yi Wang, and Grischa Liebel. 2025. Making Software Development More Diverse and Inclusive: Key Themes, Challenges, and Fut...

    2025

  15. [23]

    Jessup, Sasha M

    Sarah A. Jessup, Sasha M. Willis, Gene M. Alarcon, and Michael A. Lee. 2021. Using Eye-Tracking Data to Compare Differences in Code Comprehension and Code Per- ceptions between Expert and Novice Programmers. InHawaii International Con- ference on System Sciences. https://api.s...

    2021

  16. [24]

    SayedHassan Khatoonabadi, Diego Elias Costa, Rabe Abdalkareem, and Emad Shi- hab. 2023. On wasted contributions: Understanding the dynamics of contributor- abandoned pull requests–a mixed-methods study of 10 large open-source projects. ACM Transactions on Software Engineering ...

    2023

  17. [25]

    Shane McIntosh, Yasutaka Kamei, Bram Adams, and Ahmed E Hassan. 2014. The impact of code review coverage and code review participation on software quality: A case study of the qt, vtk, and itk projects. InProceedings of the 11th working conference on mining software repositori...

    2014

  18. [26]

    Christopher Mendez, Anita Sarma, and Margaret Burnett. 2018. Gender in open source software: what the tools tell. InProceedings of the 1st International workshop on gender equality in software engineering. 21–24

    2018

  19. [27]

    Rodrigo Morales, Shane McIntosh, and Foutse Khomh. 2015. Do code review practices impact design quality? a case study of the qt, vtk, and itk projects. In2015 IEEE 22nd international conference on software analysis, evolution, and reengineering (SANER). IEEE, 171–180

    2015

  20. [28]

    Emerson Murphy-Hill, Alberto Elizondo, Ambar Murillo, Marian Harbach, Bog- dan Vasilescu, Delphine Carlson, and Florian Dessloch. 2024. Gendermag im- proves discoverability in the field, especially for women: An multi-year case study of suggest edit, a code review feature. InP...

    2024

  21. [29]

    Stas Negara, Nicholas Chen, Mohsen Vakilian, Ralph E Johnson, and Danny Dig

  22. [30]

    InEuropean Conference on Object-Oriented Programming

    A comparative study of manual and automated refactorings. InEuropean Conference on Object-Oriented Programming. Springer, 552–576

  23. [31]

    Hema Susmita Padala, Christopher Mendez, Felipe Fronchetti, Igor Steinmacher, Zoe Steine-Hanson, Claudia Hilderbrand, Amber Horvath, Charles Hill, Logan Simpson, Margaret Burnett, et al. 2020. How gender-biased tools shape newcomer experiences in OSS projects.IEEE Transactions...

    2020

  24. [32]

    Irum Rauf, Helen Sharp, Tamara Lopez, and Michel Wermelinger. 2025. Human- Machine Teaming and Team Effectiveness in AI Tools for Software Engineering. In2025 IEEE/ACM 18th International Conference on Cooperative and Human Aspects of Software Engineering (CHASE). IEEE, 75–80

    2025

  25. [33]

    Adrian Santos, Sira Vegas, Oscar Dieste, Fernando Uyaguari, Ayşe Tosun, Davide Fucci, Burak Turhan, Giuseppe Scanniello, Simone Romano, Itir Karac, et al

  26. [34]

    A family of experiments on test-driven development.Empirical Software Engineering26, 3 (2021), 42

    2021

  27. [35]

    Italo Santos, Katia Romero Felizardo, Marco A Gerosa, and Igor Steinmacher

  28. [36]

    In2024 IEEE Symposium on Visual Languages and Human- Centric Computing (VL/HCC)

    Game elements to engage students learning the open source software contribution process. In2024 IEEE Symposium on Visual Languages and Human- Centric Computing (VL/HCC). IEEE, 59–70

  29. [37]

    Italo Santos, Katia Romero Felizardo, Igor Steinmacher, and Marco A Gerosa

  30. [38]

    In2025 IEEE/ACM 18th International Conference on Cooperative and Human Aspects of Software Engineering (CHASE)

    Great Power Brings Great Responsibility: Personalizing Conversational AI for Diverse Problem-Solvers. In2025 IEEE/ACM 18th International Conference on Cooperative and Human Aspects of Software Engineering (CHASE). IEEE, 93–95

  31. [39]

    Italo Santos, João Felipe Pimentel, Igor Wiese, Igor Steinmacher, Anita Sarma, and Marco A Gerosa. 2023. Designing for cognitive diversity: Improving the github experience for newcomers. In2023 IEEE/ACM 45th International Conference on Software Engineering: Software Engineerin...

    2023

  32. [40]

    Anita Sarma and Nina Chen. 2024. Effective teaching through code reviews: Patterns and anti-patterns.Proceedings of the ACM on Software Engineering1, FSE (2024), 1262–1283

    2024

  33. [41]

    Xiaohang Tang, Sam Wong, Marcus Huynh, Zicheng He, Yalong Yang, and Yan Chen. 2025. SPHERE: Supporting Personalized Feedback at Scale in Programming Classrooms with Structured Review of Generative AI Outputs. InProceedings of the Extended Abstracts of the CHI Conference on Hum...

    2025

  34. [42]

    Asif Kamal Turzo and Amiangshu Bosu. 2024. What makes a code review useful to opendev developers? an empirical investigation.Empirical Software Engineering 29, 1 (2024), 6

    2024

  35. [43]

    Antonio Vitale, Emanuela Guglielmi, Rocco Oliveto, and Simone Scalabrino. 2025. Personalized Code Readability Assessment: Are We There Yet?arXiv preprint arXiv:2503.07870(2025)

    2025 arXiv

  36. [44]

    Ratnadira Widyasari, Ting Zhang, Abir Bouraffa, Walid Maalej, and David Lo

  37. [45]

    Explaining explanations: An empirical study of explanations in code reviews.ACM Transactions on Software Engineering and Methodology34, 6 (2025), 1–30

    2025

  38. [46]

    Pavlína Wurzel Gonçalves, Gül Calikli, Alexander Serebrenik, and Alberto Bac- chelli. 2023. Competencies for code review.Proceedings of the ACM on Human- Computer Interaction7, CSCW1 (2023), 1–33

    2023

Pith tools

Reviewed July 13, 2026 · model on record in the stance chip above.