pith. sign in

arxiv: 2605.17548 · v1 · pith:CYG4W763new · submitted 2026-05-17 · 💻 cs.SE · cs.AI

Rethinking Code Review in the Age of AI: A Vision for Agentic Code Review

H\"useyin \"Ozg\"ur Kamal{\i} , Erdem Tuna , Vahid Haratian , Eray T\"uz\"un This is my paper

Pith reviewed 2026-05-19 22:31 UTC · model grok-4.3

classification 💻 cs.SE cs.AI
keywords code reviewagentic AIpull requestssoftware engineeringhuman-AI collaborationLLMsAI in SE
0
0 comments X

The pith

AI agents combined with human quality gates can create an end-to-end code review workflow across five stages.

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

As AI coding assistants speed up code output, the volume of changes needing review grows and turns code review into a bottleneck. The paper proposes replacing today's fragmented tools with a coordinated system of specialized agents that handle distinct parts of the pull-request process. Humans remain at selected decision points to keep accountability and project understanding. If workable, the approach would let teams process more changes without proportional increases in manual effort while surfacing concrete risks such as bias and over-reliance on automation.

Core claim

The authors present a vision for an AI-powered code review workflow that combines specialized agents with human-controlled quality gates. The framework covers five stages—PR Creation, PR Augmentation, Reviewer Selection, AI-Assisted Code Review, and PR Retrospective—while keeping humans at key decision points to preserve judgment, accountability, and team-level understanding of the codebase.

What carries the argument

A five-stage agentic workflow that assigns distinct AI agents to tasks such as PR description generation, reviewer matching, and comment suggestion, with inserted human oversight gates.

If this is right

  • Code review effort can scale with the higher volume of AI-generated changes without proportional growth in human time.
  • Isolated AI tools for reviewer recommendation or comment suggestion can be unified into one coordinated pipeline.
  • Specific risks in reliability, bias, privacy, and automation bias become explicit targets for measurement and mitigation.
  • A research agenda is defined for studying effective human-AI hand-offs in software engineering tasks.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same staged-agent pattern could extend to related tasks such as automated testing or documentation updates.
  • Integration points with existing CI/CD systems would determine how quickly the workflow reaches everyday use.
  • Over time the model may shift developer roles toward higher-level oversight rather than line-by-line inspection.

Load-bearing premise

Current and near-future agentic AI systems can reach sufficient reliability and low bias for complex code review across varied projects so that humans at the quality gates can still detect and correct remaining errors.

What would settle it

Implement the five-stage workflow on several real codebases, run parallel traditional reviews, and compare the number and severity of issues caught by the AI-assisted path versus the human-only path after humans apply the gates.

Figures

Figures reproduced from arXiv: 2605.17548 by Eray T\"uz\"un, Erdem Tuna, H\"useyin \"Ozg\"ur Kamal{\i}, Vahid Haratian.

Figure 1
Figure 1. Figure 1: Overview of the traditional code review systems workflow. [PITH_FULL_IMAGE:figures/full_fig_p008_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Overview of AI-Powered Code Review Framework Workflow [PITH_FULL_IMAGE:figures/full_fig_p013_2.png] view at source ↗
read the original abstract

Code review has evolved for decades, from informal peer checking to today's pull request (PR) workflows, yet it remains a largely manual, uneven, and cognitively demanding process. The rise of Artificial Intelligence (AI) coding assistants has intensified this challenge: while these tools increase code production velocity, they also expand the volume of code requiring review, turning code review into a growing bottleneck. Current AI support remains fragmented, with tools focusing on isolated tasks such as reviewer recommendation, PR description generation, or comment suggestion rather than the end-to-end PR review workflow. In this paper, we review the historical evolution of code review practices and examine the shift driven by large language models (LLMs) and agentic AI systems. We then present a vision for an AI-powered code review workflow combining specialized agents with human-controlled quality gates. Our framework spans five stages: PR Creation, PR Augmentation, Reviewer Selection, AI-Assisted Code Review, and PR Retrospective, with humans retained at key decision points to preserve judgment, accountability, and team-level understanding. We identify major open challenges for responsible adoption, including reliability, bias, privacy, automation bias, transparency, and evaluation, and offer a research agenda for more effective human-AI collaboration in software engineering.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

0 major / 3 minor

Summary. The paper reviews the historical evolution of code review from informal peer checking to modern pull-request workflows, notes the bottleneck created by AI coding assistants, and presents a vision for an end-to-end AI-powered code-review workflow. The proposed framework combines specialized agents with human-controlled quality gates across five explicit stages—PR Creation, PR Augmentation, Reviewer Selection, AI-Assisted Code Review, and PR Retrospective—while flagging reliability, bias, privacy, automation bias, transparency, and evaluation as open challenges and offering a research agenda for human-AI collaboration in software engineering.

Significance. If realized, the structured five-stage workflow could meaningfully reduce the cognitive load and unevenness of current code review while preserving accountability through explicit human gates. The paper’s value lies in its coherent synthesis of historical context, identification of fragmentation in existing AI tools, and forward-looking research agenda; these elements provide a useful conceptual scaffold for subsequent empirical work even though the manuscript itself contains no performance data or validation experiments.

minor comments (3)
  1. [Abstract] The abstract states that the framework “spans five stages” but does not name them; listing the stage names in the abstract would improve immediate readability.
  2. [AI-Assisted Code Review] The description of the AI-Assisted Code Review stage mentions “specialized agents” for tasks such as bug detection and security analysis; a short paragraph clarifying how specialization is achieved (e.g., fine-tuning, retrieval-augmented generation, or role prompting) would make the proposal more concrete.
  3. [Research agenda] The research-agenda section lists challenges but does not indicate relative priority or suggested evaluation metrics; adding one or two example metrics (e.g., review latency, defect escape rate, or inter-rater agreement between human and agent comments) would help readers translate the agenda into actionable studies.

Simulated Author's Rebuttal

0 responses · 0 unresolved

We thank the referee for the positive and constructive assessment of our vision paper. We are encouraged by the recognition that the proposed five-stage agentic code review framework could reduce cognitive load while maintaining human accountability, and that it offers a useful conceptual scaffold for subsequent empirical research in human-AI collaboration for software engineering.

Circularity Check

0 steps flagged

Vision paper with no derivations, fits, or load-bearing self-citations

full rationale

The manuscript is a forward-looking position paper that reviews historical code review practices, describes a conceptual five-stage AI-augmented workflow, identifies open challenges (reliability, bias, privacy), and proposes a research agenda. No equations, parameters, predictions, or quantitative claims exist. The central contribution is the coherence of the proposed structure with explicit human quality gates; it does not reduce to self-definition, fitted inputs renamed as predictions, or chains of self-citations. External historical context and standard software-engineering literature provide independent grounding.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 1 invented entities

The vision depends on domain assumptions about AI agent capabilities and the sufficiency of human oversight rather than mathematical axioms or new entities with independent evidence.

axioms (2)
  • domain assumption Specialized AI agents can effectively handle distinct stages of the code review workflow.
    Invoked when describing the five-stage framework and agent roles.
  • domain assumption Retaining humans at key decision points will preserve judgment, accountability, and team-level understanding.
    Central premise stated in the description of human-controlled quality gates.
invented entities (1)
  • Specialized review agents no independent evidence
    purpose: To automate and structure the end-to-end PR review process
    Introduced as part of the proposed workflow without concrete implementation or external validation.

pith-pipeline@v0.9.0 · 5772 in / 1333 out tokens · 52974 ms · 2026-05-19T22:31:21.661695+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

244 extracted references · 244 canonical work pages · 3 internal anchors

  1. [1]

    Expectations, outcomes, and challenges of modern code review,

    A. Bacchelli and C. Bird, “Expectations, outcomes, and challenges of modern code review,” in2013 35th International Conference on Software Engineering (ICSE), pp. 712–721, IEEE, 5 2013

    work page 2013

  2. [2]

    Modern code review,

    C. Sadowski, E. Söderberg, L. Church, M. Sipko, and A. Bacchelli, “Modern code review,” inProceedings of the 40th International Conference on Software Engineering: Software Engineering in Practice, pp. 181–190, ACM, 5 2018

    work page 2018

  3. [3]

    Convergent contemporary software peer review practices,

    P. C. Rigby and C. Bird, “Convergent contemporary software peer review practices,” inProceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering, pp. 202–212, ACM, 8 2013

    work page 2013

  4. [4]

    https://github.com/, 2026

    GitHub. https://github.com/, 2026. Accessed: 11 May 2026

    work page 2026

  5. [5]

    https://about.gitlab.com, 2026

    GitLab. https://about.gitlab.com, 2026. Accessed: 10 May 2026

    work page 2026

  6. [6]

    https://bitbucket.org, 2026

    Bitbucket. https://bitbucket.org, 2026. Accessed: 10 May 2026

    work page 2026

  7. [7]

    An exploratory study of the pull-based software development model,

    G. Gousios, M. Pinzger, and A. V . Deursen, “An exploratory study of the pull-based software development model,”Proceedings - International Conference on Software Engineering, pp. 345–355, 5 2014

    work page 2014

  8. [8]

    Code reviewing in the trenches: Challenges and best practices,

    L. MacLeod, M. Greiler, M.-A. Storey, C. Bird, and J. Czerwonka, “Code reviewing in the trenches: Challenges and best practices,”IEEE Software, vol. 35, pp. 34–42, 7 2018

    work page 2018

  9. [9]

    Code review quality,

    O. Kononenko, O. Baysal, and M. W. Godfrey, “Code review quality,” inProceedings of the 38th International Conference on Software Engineering, pp. 1028–1038, ACM, 5 2016

    work page 2016

  10. [10]

    Investigating technical and non-technical factors influencing modern code review,

    O. Baysal, O. Kononenko, R. Holmes, and M. W. Godfrey, “Investigating technical and non-technical factors influencing modern code review,”Empirical Software Engineering, vol. 21, pp. 932–959, 6 2016

    work page 2016

  11. [11]

    Towards a taxonomy of code review smells,

    E. Do˘gan and E. Tüzün, “Towards a taxonomy of code review smells,”Information and Software Technology, vol. 142, p. 106737, 2 2022

    work page 2022

  12. [12]

    An empirical study of the impact of modern code review practices on software quality,

    S. McIntosh, Y . Kamei, B. Adams, and A. E. Hassan, “An empirical study of the impact of modern code review practices on software quality,”Empirical Software Engineering, vol. 21, pp. 2146–2189, 10 2016

    work page 2016

  13. [13]

    The impact of ai on developer productivity: Evidence from github copilot,

    S. Peng, E. Kalliamvakou, P. Cihon, and M. Demirer, “The impact of ai on developer productivity: Evidence from github copilot,” 2 2023

    work page 2023

  14. [14]

    The impact of generative ai on collaborative open-source software develop- ment: Evidence from github copilot,

    F. Song, A. Agarwal, and W. Wen, “The impact of generative ai on collaborative open-source software develop- ment: Evidence from github copilot,”SSRN Electronic Journal, 10 2024

    work page 2024

  15. [15]

    Human-ai synergy in agentic code review,

    S. Zhong, S. Noei, Y . Zou, S. Member, and B. Adams, “Human-ai synergy in agentic code review,” 3 2026

    work page 2026

  16. [16]

    Deep learning-based code reviews: A paradigm shift or a double-edged sword?,

    R. Tufano, A. Martin-Lopez, A. Tayeb, O. Dabi´c, S. Haiduc, and G. Bavota, “Deep learning-based code reviews: A paradigm shift or a double-edged sword?,”Proceedings - International Conference on Software Engineering, pp. 1640–1652, 2025

    work page 2025

  17. [17]

    Trust dynamics in ai-assisted development: Definitions, factors, and implications,

    S. Sabouri, P. Eibl, X. Zhou, M. Ziyadi, N. Medvidovic, L. Lindemann, and S. Chattopadhyay, “Trust dynamics in ai-assisted development: Definitions, factors, and implications,”Proceedings - International Conference on Software Engineering, pp. 1678–1690, 2025

    work page 2025

  18. [18]

    Mapping the trust terrain: Llms in software engineering - insights and perspectives,

    D. Khati, Y . Liu, D. N. Palacio, Y . Zhang, and D. Poshyvanyk, “Mapping the trust terrain: Llms in software engineering - insights and perspectives,”ACM Transactions on Software Engineering and Methodology, 3 2025

    work page 2025

  19. [19]

    Vibe coding in practice: Motivations, challenges, and a future outlook-a grey literature review,

    A. Fawzy, A. Tahir, and K. Blincoe, “Vibe coding in practice: Motivations, challenges, and a future outlook – a grey literature review,”arXiv preprint arXiv:2510.00328, vol. 1, 9 2025

    work page arXiv 2025

  20. [20]

    Software engineering by and for humans in an ai era,

    S. Abrahão, J. Grundy, M. Pezzè, M. A. Storey, and D. A. Tamburri, “Software engineering by and for humans in an ai era,”ACM Transactions on Software Engineering and Methodology, vol. 34, 5 2025

    work page 2025

  21. [21]

    Towards automating code review activities,

    R. Tufano, L. Pascarella, M. Tufano, D. Poshyvanyk, and G. Bavota, “Towards automating code review activities,” Proceedings - International Conference on Software Engineering, pp. 163–174, 11 2021. 33 A VISION FORAGENTICCODEREVIEW

    work page 2021

  22. [22]

    Using pre-trained models to boost code review automation,

    R. Tufano, S. Masiero, A. Mastropaolo, L. Pascarella, D. Poshyvanyk, and G. Bavota, “Using pre-trained models to boost code review automation,”Proceedings - International Conference on Software Engineering, vol. 2022-May, pp. 2291–2302, 7 2022

    work page 2022

  23. [23]

    Llama-reviewer: Advancing code review automation with large language models through parameter-efficient fine-tuning,

    J. Lu, L. Yu, X. Li, L. Yang, and C. Zuo, “Llama-reviewer: Advancing code review automation with large language models through parameter-efficient fine-tuning,”Proceedings - International Symposium on Software Reliability Engineering, ISSRE, pp. 647–658, 2023

    work page 2023

  24. [24]

    Commentfinder: a simpler, faster, more accurate code review comments recommendation,

    Y . Hong, C. Tantithamthavorn, P. Thongtanunam, and A. Aleti, “Commentfinder: a simpler, faster, more accurate code review comments recommendation,” inProceedings of the 30th ACM joint European software engineering conference and symposium on the foundations of software engineering, pp. 507–519, 2022

    work page 2022

  25. [25]

    Generative ai for pull request descriptions: Adoption, impact, and developer interventions,

    T. Xiao, H. Hata, C. Treude, and K. Matsumoto, “Generative ai for pull request descriptions: Adoption, impact, and developer interventions,”Proceedings of the ACM on Software Engineering, vol. 1, pp. 1043–1065, 7 2024

    work page 2024

  26. [26]

    Unity is strength: Collaborative llm-based agents for code reviewer recommendation,

    L. Wang, Y . Zhou, H. Zhuang, Q. Li, D. Cui, Y . Zhao, and L. Wang, “Unity is strength: Collaborative llm-based agents for code reviewer recommendation,”Proceedings - 2024 39th ACM/IEEE International Conference on Automated Software Engineering, ASE 2024, pp. 2235–2239, 10 2024

    work page 2024

  27. [27]

    Using an llm to help with code understanding,

    D. Nam, A. MacVean, V . Hellendoorn, B. Vasilescu, and B. Myers, “Using an llm to help with code understanding,” Proceedings - International Conference on Software Engineering, vol. 13, pp. 1184–1196, 5 2024

    work page 2024

  28. [28]

    Hydra-reviewer: A holistic multi-agent system for automatic code review comment generation,

    X. Ren, C. Dai, Q. Huang, Y . Wang, C. Liu, and B. Jiang, “Hydra-reviewer: A holistic multi-agent system for automatic code review comment generation,”IEEE Transactions on Software Engineering, vol. 51, pp. 3540– 3557, 2025

    work page 2025

  29. [29]

    Codeagent: Autonomous communicative agents for code review,

    X. Tang, K. Kim, Y . Song, C. Lothritz, B. Li, S. Ezzini, H. Tian, J. Klein, and T. F. Bissyandé, “Codeagent: Autonomous communicative agents for code review,”EMNLP 2024 - 2024 Conference on Empirical Methods in Natural Language Processing, Proceedings of the Conference, pp. 11279–11313, 2 2024

    work page 2024

  30. [30]

    A brief history of software engineering,

    N. Wirth, “A brief history of software engineering,”IEEE Annals of the History of Computing, vol. 30, pp. 32–39, 7 2008

    work page 2008

  31. [31]

    Backus,Programming in America in the 1950s—Some Personal Impressions, pp

    J. Backus,Programming in America in the 1950s—Some Personal Impressions, pp. 125–135. Elsevier, 1980

    work page 1980

  32. [32]

    Software engineering: Report of a conference sponsored by the nato science committee, garmisch, germany, 7-11 oct. 1968, brussels, scientific affairs division, nato,

    P. Naur and B. Randell, “Software engineering: Report of a conference sponsored by the nato science committee, garmisch, germany, 7-11 oct. 1968, brussels, scientific affairs division, nato,”NATO Science Committee, 1969

    work page 1968

  33. [33]

    G. M. Weinberg,The psychology of computer programming. Chapman and Hall, 1971

    work page 1971

  34. [34]

    Design and code inspections to reduce errors in program development,

    M. E. Fagan, “Design and code inspections to reduce errors in program development,”IBM Systems Journal, vol. 15, pp. 182–211, 1976

    work page 1976

  35. [35]

    Software inspections: an effective verification process,

    A. F. Ackerman, L. S. Buchwald, and F. H. Lewski, “Software inspections: an effective verification process,” IEEE software, vol. 6, pp. 31–36, 1989

    work page 1989

  36. [36]

    Experience with inspection in ultralarge-scale development,

    G. Russell, “Experience with inspection in ultralarge-scale development,”IEEE Software, vol. 8, pp. 25–31, 1 1991

    work page 1991

  37. [37]

    Advances in software inspections,

    M. E. Fagan, “Advances in software inspections,”IEEE Transactions on Software Engineering, vol. SE-12, pp. 744–751, 7 1986

    work page 1986

  38. [38]

    Active design reviews: principles and practices,

    D. L. Parnas and D. M. Weiss, “Active design reviews: principles and practices,” inProceedings of the 8th International Conference on Software Engineering, pp. 132–136, IEEE Computer Society Press, 1985

    work page 1985

  39. [39]

    Phased inspections and their implementation,

    J. C. Knight and E. A. Myers, “Phased inspections and their implementation,”ACM SIGSOFT Software Engineering Notes, vol. 16, pp. 29–35, 7 1991

    work page 1991

  40. [40]

    Icicle: groupware for code inspection,

    L. Brothers, V . Sembugamoorthy, and M. Muller, “Icicle: groupware for code inspection,” inProceedings of the 1990 ACM conference on Computer-supported cooperative work - CSCW ’90, pp. 169–181, ACM Press, 1990

    work page 1990

  41. [41]

    Icicle: Intelligent code inspection in a c language environment,

    V . Sembugamoorthy and L. Brothers, “Icicle: Intelligent code inspection in a c language environment,” in Proceedings., Fourteenth Annual International Computer Software and Applications Conference, pp. 146–154, IEEE Comput. Soc. Press, 10 1990

    work page 1990

  42. [42]

    Does every inspection need a meeting?,

    L. G. V otta, “Does every inspection need a meeting?,”ACM SIGSOFT Software Engineering Notes, vol. 18, pp. 107–114, 12 1993

    work page 1993

  43. [43]

    Does every inspection really need a meeting?,

    P. M. Johnson and D. Tjahjono, “Does every inspection really need a meeting?,”Empirical Software Engineering, vol. 3, pp. 9–35, 3 1998

    work page 1998

  44. [44]

    Raymond,The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary

    E. Raymond,The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. O’Reilly Media, Inc, 2001. 34 A VISION FORAGENTICCODEREVIEW

    work page 2001

  45. [45]

    Two case studies of open source software development,

    A. Mockus, R. T. Fielding, and J. D. Herbsleb, “Two case studies of open source software development,”ACM Transactions on Software Engineering and Methodology, vol. 11, pp. 309–346, 7 2002

    work page 2002

  46. [46]

    Distance, dependencies, and delay in a global collaboration,

    J. D. Herbsleb, A. Mockus, T. A. Finholt, and R. E. Grinter, “Distance, dependencies, and delay in a global collaboration,” inProceedings of the 2000 ACM conference on Computer supported cooperative work, pp. 319– 328, ACM, 12 2000

    work page 2000

  47. [47]

    Manifesto for agile software development,

    A. Alliance, “Manifesto for agile software development,” 2001

    work page 2001

  48. [48]

    Cvs ii: Parallelizing software development,

    B. Berliner, “Cvs ii: Parallelizing software development,”Proceedings of the USENIX Winter 1990 Technical Conference, vol. 341, p. 352, 1990

    work page 1990

  49. [49]

    Open source software peer review practices,

    P. C. Rigby, D. M. German, and M.-A. Storey, “Open source software peer review practices,” inProceedings of the 13th international conference on Software engineering - ICSE ’08, p. 541, ACM Press, 2008

    work page 2008

  50. [50]

    Understanding broadcast based peer review on open source software projects,

    P. C. Rigby and M.-A. Storey, “Understanding broadcast based peer review on open source software projects,” in Proceedings of the 33rd International Conference on Software Engineering, pp. 541–550, ACM, 5 2011

    work page 2011

  51. [51]

    Understanding open source software peer review review processes, parameters and statistical models, and underlying behaviours and mechanisms.,

    P. C. Rigby, M.-A. Storey, and D. M. German, “Understanding open source software peer review review processes, parameters and statistical models, and underlying behaviours and mechanisms.,” 2011

    work page 2011

  52. [52]

    K. Niall. https://web.archive.org/web/20220428173308/https://www.niallkennedy.com/blog/2006/11/google- mondrian.html, 2006. Accessed: 11 May 2026

    work page arXiv 2006

  53. [53]

    https://www.gerritcodereview.com/, 2026

    Gerrit. https://www.gerritcodereview.com/, 2026. Accessed: 11 May 2026

    work page 2026

  54. [54]

    Adopting code reviews for agile software development,

    M. Bernhart, A. Mauczka, and T. Grechenig, “Adopting code reviews for agile software development,”Proceed- ings - 2010 Agile Conference, AGILE 2010, pp. 44–47, 2010. reviewclipse product

    work page 2010

  55. [55]

    https://www.phacility.com/phabricator/, 2026

    Phabricator. https://www.phacility.com/phabricator/, 2026. Accessed: 11 May 2026

    work page 2026

  56. [56]

    https://web.archive.org/web/20140527012205/http://www.microsoft.com/en- us/news/features/2012/jan12/01-05CodeFlow.aspx, 2026

    Microsoft CodeFlow. https://web.archive.org/web/20140527012205/http://www.microsoft.com/en- us/news/features/2012/jan12/01-05CodeFlow.aspx, 2026. Accessed: 11 May 2026

    work page arXiv 2012

  57. [57]

    Improving code review by predicting reviewers and acceptance of patches,

    G. Jeong, S. Kim, T. Zimmermann, and K. Yi, “Improving code review by predicting reviewers and acceptance of patches,”Research on software analysis for error-free computing center Tech-Memo (ROSAEC MEMO 2009-006), pp. 1–18, 2009

    work page 2009

  58. [58]

    The influence of non-technical factors on code review,

    O. Baysal, O. Kononenko, R. Holmes, and M. W. Godfrey, “The influence of non-technical factors on code review,”Proceedings - Working Conference on Reverse Engineering, WCRE, pp. 122–131, 2013

    work page 2013

  59. [59]

    Using static analysis to find bugs,

    N. Ayewah, D. Hovemeyer, D. J. Morgenthaler, J. Penix, and W. Pugh, “Using static analysis to find bugs,”IEEE Software, vol. 25, pp. 22–29, 2008

    work page 2008

  60. [60]

    Assessing the value of branches with what-if analysis,

    C. Bird and T. Zimmermann, “Assessing the value of branches with what-if analysis,”Proceedings of the ACM SIGSOFT 20th International Symposium on the Foundations of Software Engineering, FSE 2012, 2012

    work page 2012

  61. [61]

    The effect of branching strategies on software quality,

    E. Shihab, C. Bird, and T. Zimmermann, “The effect of branching strategies on software quality,”International Symposium on Empirical Software Engineering and Measurement, pp. 301–310, 2012

    work page 2012

  62. [62]

    Work practices and challenges in pull-based development: The integrator’s perspective,

    G. Gousios, A. Zaidman, M.-A. Storey, and A. van Deursen, “Work practices and challenges in pull-based development: The integrator’s perspective,” in2015 IEEE/ACM 37th IEEE International Conference on Software Engineering, pp. 358–368, IEEE, 5 2015

    work page 2015

  63. [63]

    Continuous integration in a social-coding world: Empirical evidence from github,

    B. Vasilescu, S. V . Schuylenburg, J. Wulms, A. Serebrenik, and M. G. V . D. Brand, “Continuous integration in a social-coding world: Empirical evidence from github,”Proceedings - 30th International Conference on Software Maintenance and Evolution, ICSME 2014, pp. 401–405, 12 2014

    work page 2014

  64. [64]

    Creating a shared understanding of testing culture on a social coding site,

    R. Pham, L. Singer, O. Liskin, F. F. Filho, and K. Schneider, “Creating a shared understanding of testing culture on a social coding site,”Proceedings - International Conference on Software Engineering, pp. 112–121, 2013

    work page 2013

  65. [65]

    Quality and productivity outcomes relating to continuous integration in github,

    B. Vasilescu, Y . Yu, H. Wang, P. Devanbu, and V . Filkov, “Quality and productivity outcomes relating to continuous integration in github,”2015 10th Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering, ESEC/FSE 2015 - Proceedings, pp. 805–816, 8 2015

    work page 2015

  66. [66]

    Factors influencing code review processes in industry,

    T. Baum, O. Liskin, K. Niklas, and K. Schneider, “Factors influencing code review processes in industry,” in Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering, pp. 85–96, ACM, 11 2016

    work page 2016

  67. [67]

    Tricorder: Building a program analysis ecosystem,

    C. Sadowski, J. V . Gogh, C. Jaspan, E. Söderberg, and C. Winter, “Tricorder: Building a program analysis ecosystem,”Proceedings - International Conference on Software Engineering, vol. 1, pp. 598–608, 8 2015. 35 A VISION FORAGENTICCODEREVIEW

    work page 2015

  68. [68]

    Scaling static analyses at facebook,

    D. Distefano, M. Fähndrich, F. Logozzo, and P. W. O’Hearn, “Scaling static analyses at facebook,”Communica- tions of the ACM, vol. 62, pp. 62–70, 8 2019

    work page 2019

  69. [69]

    Impact of continuous integration on code reviews,

    M. M. Rahman and C. K. Roy, “Impact of continuous integration on code reviews,”IEEE International Working Conference on Mining Software Repositories, vol. 0, pp. 499–502, 6 2017

    work page 2017

  70. [70]

    The silent helper: The impact of continuous integration on code reviews,

    N. Cassee, B. Vasilescu, and A. Serebrenik, “The silent helper: The impact of continuous integration on code reviews,”SANER 2020 - Proceedings of the 2020 IEEE 27th International Conference on Software Analysis, Evolution, and Reengineering, pp. 423–434, 2 2020

    work page 2020

  71. [71]

    Pull request decisions explained: An empirical overview,

    X. Zhang, Y . Yu, G. Gousios, and A. Rastogi, “Pull request decisions explained: An empirical overview,”IEEE Transactions on Software Engineering, vol. 49, pp. 849–871, 2 2023

    work page 2023

  72. [72]

    Confusion in code reviews: Reasons, impacts, and coping strategies,

    F. Ebert, F. Castor, N. Novielli, and A. Serebrenik, “Confusion in code reviews: Reasons, impacts, and coping strategies,” in2019 IEEE 26th International Conference on Software Analysis, Evolution and Reengineering (SANER), pp. 49–60, IEEE, 2 2019

    work page 2019

  73. [73]

    Martini, V

    A. Martini, V . Stray, and N. B. Moe,Technical-, Social- and Process Debt in Large-Scale Agile: An Exploratory Case-Study, pp. 112–119. 2019

    work page 2019

  74. [74]

    Automatic generation of pull request descriptions,

    Z. Liu, X. Xia, C. Treude, D. Lo, and S. Li, “Automatic generation of pull request descriptions,” in2019 34th IEEE/ACM International Conference on Automated Software Engineering (ASE), pp. 176–188, IEEE, 11 2019

    work page 2019

  75. [75]

    How do software engineers understand code changes? an exploratory study in industry,

    Y . Tao, Y . Dang, T. Xie, D. Zhang, and S. Kim, “How do software engineers understand code changes? an exploratory study in industry,” inProceedings of the ACM SIGSOFT Symposium on the Foundations of Software Engineering (FSE), pp. 51–61, 2012

    work page 2012

  76. [76]

    Anti- patterns in modern code review: Symptoms and prevalence,

    M. Chouchen, A. Ouni, R. G. Kula, D. Wang, P. Thongtanunam, M. W. Mkaouer, and K. Matsumoto, “Anti- patterns in modern code review: Symptoms and prevalence,” in2021 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER), pp. 531–535, IEEE, 3 2021

    work page 2021

  77. [77]

    Towards unmasking lgtm smells in code reviews: A comparative study of comment-free and commented reviews,

    M. F. Gon, B. Yetistiren, and E. Tuzun, “Towards unmasking lgtm smells in code reviews: A comparative study of comment-free and commented reviews,”Proceedings - 2024 IEEE International Conference on Software Maintenance and Evolution, ICSME 2024, pp. 163–174, 2024

    work page 2024

  78. [78]

    Identification and management of technical debt: A systematic mapping study,

    N. S. Alves, T. S. Mendes, M. G. de Mendonça, R. O. Spínola, F. Shull, and C. Seaman, “Identification and management of technical debt: A systematic mapping study,”Information and Software Technology, vol. 70, pp. 100–121, 2 2016

    work page 2016

  79. [79]

    Impacts of agile requirements documentation debt on software projects,

    T. S. Mendes, M. A. de F. Farias, M. Mendonça, H. F. Soares, M. Kalinowski, and R. O. Spínola, “Impacts of agile requirements documentation debt on software projects,” inProceedings of the 31st Annual ACM Symposium on Applied Computing, pp. 1290–1295, ACM, 4 2016

    work page 2016

  80. [80]

    Associating working memory capacity and code change ordering with code review performance,

    T. Baum, K. Schneider, and A. Bacchelli, “Associating working memory capacity and code change ordering with code review performance,”Empirical Software Engineering, vol. 24, pp. 1762–1798, 8 2019

    work page 2019

Showing first 80 references.