Pith. sign in

REVIEW 3 major objections 5 minor 32 references

From Developer Pairs to AI Copilots: A Comparative Study on Knowledge Transfer

T0 review · 3 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

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

Pith's one-line read This paper claims that knowledge transfer happens in both human-human pair programming and human-AI pair programming, but that developers trust GitHub Copilot's suggestions with less scrutiny than a human partner's.

desk verdict An interesting but statistically shaky comparison of knowledge transfer in human pairs vs Copilot; the TRUST finding is likely inflated by the monologue/dialogue asymmetry. read the letter →

arxiv 2506.04785 v1 pith:GEJY634T submitted 2025-06-05 cs.SE

Alisa Welter , Niklas Schneider , Tobias Dick , Kallistos Weis , Christof Tinnes , Marvin Wyrich , Sven Apel This is my paper
classification cs.SE
keywords knowledgetransferpairprogrammingGitHubCopilotAIcodingassistantstrustinempiricalstudythink-aloudprotocolepisodeanalysis
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

This paper tests whether an AI coding assistant can take over the knowledge-transfer role of a human pair-programming partner. In a controlled study, six pairs of developers worked together on a password-manager codebase while seven individual developers did the same task with GitHub Copilot, and the authors classified every knowledge-transfer episode in the recorded sessions using an extended framework. They find that knowledge transfer happens in both settings, with successful episodes occurring at similar rates and overlapping topics, and with two characteristic differences: developers accept Copilot's suggestions with less scrutiny than a human partner's input, and Copilot sometimes supplies subtle reminders (such as a missing database commit) that a human might overlook. If correct, this means AI assistants are genuine but asymmetric knowledge sources: they can teach and remind, yet their suggestions are trusted more readily than they deserve.

What carries the argument

The central mechanism is an episode-based knowledge-transfer framework that unifies prior work. A knowledge gap is a disparity between what a person knows and what a pair member considers relevant; an episode is a sequence of related utterances initiated by a need for or sharing of knowledge, and the customer is the person needing knowledge. Episodes are classified by finish type (ASSIMILATION, TRUST, GAVE UP, LOST SIGHT, UNNECESSARY) and by topic type (TOOL, PROGRAM, BUG, CODE, DOMAIN, TECHNIQUE), with length and depth capturing how much talk an episode contains and how deeply it is nested. The argument rests on a semi-automated pipeline that transcribes recordings, segments speech into utterances, annotates episodes, and statistically compares the two settings. This framework is what lets the authors claim that a Copilot suggestion accepted with "If Copilot says so, it'll be right" is a genuine, if shallow, knowledge transfer rather than a mere autocomplete.

What would settle it

A re-analysis at the participant level would settle the frequency claim: if per-participant episode rates are approximately equal (roughly 17.5 for pair members versus 18.0 for Copilot users), the Welch t-test significance reported for episode frequency disappears. A further check would run a solo-human think-aloud condition without Copilot; if solo humans produce the same lowered episode counts and TRUST rates, the differences attributed to the AI are actually artifacts of the think-aloud protocol.

Watch

Extended reading notes

Core claim

The paper's central claim is that knowledge transfer is not exclusive to human collaboration: it occurs when a developer works with GitHub Copilot, and with a similar frequency of successful outcomes as in human-human pair programming. The authors establish this by extending a knowledge-gap framework to human-AI interaction, annotating spoken sessions into episodes, and comparing the distributions of episode length, depth, topic, and finish type. Their key finding is an asymmetry in how the two partners are treated: Copilot users accept suggestions with minimal critical review (finish type TRUST occurs more than twice as often), while human pairs are more likely to get sidetracked and abandon an episode (LOST SIGHT). They also find that Copilot can act as a subtle, unsolicited teacher, for example by reminding developers to commit database changes, a form of passive knowledge push previously assumed to require a human. The overall conclusion is that AI assistants provide real knowledge transfer, but the trust imbalance points to a need for mechanisms that encourage critical evaluation.

Load-bearing premise

The load-bearing assumption is that a two-person dialogue and a single person thinking aloud are commensurable measures of the same phenomenon; if they are not, the observed differences in episode counts and lengths may reflect group size and verbalization mode rather than knowledge-transfer behavior.

Editorial extensions

If this is right

  • If knowledge transfer is comparable in both settings, organizations can expect solo developers using Copilot to gain some learning benefits, not just speed.
  • The higher TRUST rate implies that code review and verification steps become more important when AI assistants generate code.
  • The rarity of LOST SIGHT in Copilot sessions suggests AI-assisted work is more focused but less open to serendipitous, off-topic learning.
  • Copilot's unsolicited reminders, such as adding a database commit, show that push-mode knowledge transfer is possible without a human partner.
  • Combining AI assistance with human pair programming could preserve the breadth of human interaction while gaining the focus and efficiency of AI suggestions.

Reading between the lines

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

  • Re-analyzing the data per participant rather than per session would probably erase the reported difference in episode frequency, since pair sessions contain two speakers and Copilot sessions one.
  • A matched solo-human control group, thinking aloud without Copilot, would separate the effect of the AI from the effect of having a dialogue partner.
  • The trust gap may shrink in settings where errors have real consequences; the study itself notes that its lab task carried no stakes, so the TRUST result should be tested under production-like pressure.
  • A simple design intervention suggested by the authors' own framing is to require developers to articulate why a suggestion is correct before accepting it; this could convert TRUST episodes into ASSIMILATION episodes.
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 / 5 minor

Summary. The paper reports a controlled experiment comparing knowledge transfer in human–human pair programming (six pairs, 12 participants) with that in human–AI pair programming (seven individuals using GitHub Copilot). The authors extend the knowledge-transfer frameworks of Zieris and Prechelt and Kuttal et al., introduce a TRUST finish type, and analyze transcribed think-aloud/dialogue sessions through a semi-automated pipeline. They report that knowledge transfer occurs in both settings, that episode depths are similar, that human–AI sessions focus more on CODE topics, that Copilot can subtly remind developers of important details such as database commits, and that developers accept Copilot suggestions with less scrutiny than human partners' suggestions.

Significance. The question is timely and practically relevant: as AI coding assistants are increasingly framed as 'AI pair programmers,' evidence on whether and how they support knowledge transfer is important for trust calibration, tool design, and developer training. The paper's strengths include a clearly described extension of prior frameworks, a controlled task using a realistic codebase, a replication package, and a transparent discussion of several threats to validity. If the comparative findings were robust, they would be a meaningful contribution. However, as detailed below, the two most distinctive findings are undermined by asymmetric measurement between conditions and by an unadjusted unit-of-analysis confound.

major comments (3)
  1. [§V-B, Figure 2a, Finding 1] The frequency comparison is confounded by unequal session size. Pair sessions contain two speakers producing a dialogue, whereas Copilot sessions contain one speaker thinking aloud. The paper reports 35.0 episodes per session for pairs versus 18.0 for Copilot users and a significant Welch t-test, t(8.15) = -3.38, but does not normalize by the number of participants. Recomputing per participant, 210 episodes across 12 pair programmers equals 17.5 episodes per person, and 126 episodes across 7 Copilot users equals 18.0 episodes per person. Thus the claim in Finding 1 that human–human pair programmers 'tend to engage more actively' is not supported by the per-session comparison; a per-participant analysis or a mixed-effects model accounting for session size is needed.
  2. [§V-C, Figure 3a, Figure 4, §VI-A, Finding 5] The TRUST finish type is measured asymmetrically, making the 'less scrutiny' finding an artifact of monologue versus dialogue. In human–human sessions, episodes are built from two speakers' dialogue, so ASSIMILATION is credited when the customer rephrases, explains back, or otherwise demonstrates understanding; TRUST is assigned only when acceptance occurs without such evidence. In human–AI sessions, the think-aloud protocol records only the developer's speech, and Copilot's suggestions are not transcript utterances. A developer who reads a suggestion and says 'okay' or 'let's try it' cannot be distinguished from one who understands and accepts it, because the conversational probes that would elicit evidence of understanding are absent by design. The paper's own example in Figure 4 ('I don't know' / 'If GitHub Copilot says so, it'll be right') is a monologue in which the lack of elaboration is methodologically inevitable, not evidence of reduced scrutiny. The threats-to-validity section (VI-B) acknowledges think-aloud omissions and single-annotator risk, but it does not address this differential misclassification between finish types, and no inter-rater reliability is reported. The central claim that developers accept Copilot suggestions with less scrutiny is therefore not supported by the current data.
  3. [§V-B, §V-C, §IV-C] Statistical reporting is incomplete throughout the results. Significance claims lack p-values, effect sizes, and confidence intervals. The Welch t-test is reported only as t(8.15) = -3.38; the Mann-Whitney U tests for length and depth and the chi-square tests for topic and finish type distributions are described only as 'significant' or 'not significant'; and the individual finish-type chi-square comparisons are not reported with any statistic. Given the small number of sessions (six vs. seven), effect sizes are essential for evaluating whether the observed differences are meaningful. The replication package may contain these values, but the paper should report them in the text for each statistical claim.
minor comments (5)
  1. [§I, Abstract] There are several typographical errors, including 'assistent' for 'assistant' in the Introduction and missing spaces such as 'withAI pair programmers'.
  2. [§IV-A, RQ1] 'To what extend' should be 'To what extent'.
  3. [Table II, PROGRAM topic definition] The example text contains 'it’s syntax', which should be 'its syntax'.
  4. [Figure 3] The figure legend and the ordering of bars are confusing: the percentage values are not clearly aligned with the two groups, and the label order (Trust, Unnecessary, Lost Sight, Gave Up, Assimilation) does not match the natural order in the text. Please clarify the group assignment and bar mapping.
  5. [§V-C, Figure 5] The inline annotations in Figure 5 are awkwardly placed and partly duplicate the surrounding text; the formatting should be cleaned up for readability.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity; the central results are empirical measurements, not derivations from their own inputs.

full rationale

The paper's central claim is an observational comparison of knowledge-transfer episodes in human–human versus human–AI pair programming. The framework (episodes, finish types, topic types) is imported from prior work by Zieris and Prechelt and Kuttal et al., and the findings are counts and statistical tests over annotated transcripts. No fitted parameter is renamed as a prediction, and no equation or definition forces the reported distributions. The TRUST finish type is defined as acceptance without full understanding, and Finding 5 interprets the higher frequency of TRUST episodes as reduced scrutiny; this is an operationalization of the construct, not a derivation, and the comparison could in principle have gone the other way. The paper's own threats-to-validity section acknowledges think-aloud incompleteness and single-annotator risk; these are methodological limitations, not circularity. The only self-citations ([29], [31] include co-author Apel) are used for experience-measurement and validity vocabulary and are not load-bearing for the knowledge-transfer claim. No circular step can be exhibited by quoting a specific equation or definition that reduces to its own input.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The study's measurements rest on assumptions about the validity of spoken and think-aloud data, the transferability of a human-human KT framework to Copilot, and the comparability of pair versus individual sessions. No numerical parameters are fitted; the free parameter list is empty.

assumptions (4)
  • domain assumption Spoken utterances and think-aloud verbalizations are a valid and comparable proxy for knowledge transfer processes in both settings.
    The entire measurement relies on verbal data; think-aloud may miss unspoken cognitive processes, as acknowledged in Section VI-B Internal Validity.
  • domain assumption The knowledge transfer framework from Zieris and Prechelt and Kuttal et al. transfers to human-AI pair programming with GitHub Copilot.
    The paper extends an existing framework to a new setting; the definitions in Section III assume Copilot suggestions can serve as knowledge contributions comparable to a human partner.
  • domain assumption Episodes and utterance boundaries can be reliably identified from transcripts and screen recordings by a single annotator.
    Annotation is by one person with a random cross-check; no inter-rater reliability is reported (Section IV-C, Section VI-B).
  • ad hoc to paper Per-session episode counts can be compared between groups of different session size (pairs vs individuals) without normalization.
    The statistical comparison in Section V-B treats pair sessions and individual sessions as comparable units, an assumption that is not defended and is central to RQ1.

how reviews work

0 comments
Cite this review

Pith. "Pith review of From Developer Pairs to AI Copilots: A Comparative Study on Knowledge Transfer." pith.science (2026). https://pith.science/paper/GEJY634T

@misc{pith2026250604785,
  author       = {Pith},
  title        = {Pith review of: From Developer Pairs to AI Copilots: A Comparative Study on Knowledge Transfer},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/GEJY634T}},
  note         = {Machine review of arXiv:2506.04785}
}
read the original abstract

Knowledge transfer is fundamental to human collaboration and is therefore common in software engineering. Pair programming is a prominent instance. With the rise of AI coding assistants, developers now not only work with human partners but also, as some claim, with AI pair programmers. Although studies confirm knowledge transfer during human pair programming, its effectiveness with AI coding assistants remains uncertain. To analyze knowledge transfer in both human-human and human-AI settings, we conducted an empirical study where developer pairs solved a programming task without AI support, while a separate group of individual developers completed the same task using the AI coding assistant GitHub Copilot. We extended an existing knowledge transfer framework and employed a semi-automated evaluation pipeline to assess differences in knowledge transfer episodes across both settings. We found a similar frequency of successful knowledge transfer episodes and overlapping topical categories across both settings. Two of our key findings are that developers tend to accept GitHub Copilot's suggestions with less scrutiny than those from human pair programming partners, but also that GitHub Copilot can subtly remind developers of important code details they might otherwise overlook.

Figures

Figures reproduced from arXiv: 2506.04785 by the authors.

Figure 1
Figure 1. Overview of our data processing pipeline. While the annotated transcripts are primarily derived from voice recordings, [PITH_FULL_IMAGE:figures/full_fig_p006_1.png] view at source ↗
Figure 2
Figure 2. Comparison of episodes in terms of number (a), length (b), and depth (c). [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗
Figure 3
Figure 3. Distribution of finish types (a) and topic types (b). [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Episode with finish type TRUST. Guillemets mark single utterances. Bracketed text added for context. » Is there something like head or tail or first or something like that? » We will have to look it up, probably there is » Okay, so... » User [dot] login finish type: LO…
Figure 5
Figure 5. Figure 5: Episode with finish type LOST SIGHT. Guillemets mark single utterances. Bracketed text added for context. VI. DISCUSSION Even the most experienced programmer will reach a point in their day-to-day programming where some additional knowledge would be beneficial. In our …

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

32 extracted references · 25 canonical work pages

  1. [1]

    Are two heads better than one? on the effectiveness of pair programming,

    T. Dyb˚a, E. Arisholm, D. I. Sjoberg, J. E. Hannay, and F. Shull, “Are two heads better than one? on the effectiveness of pair programming,” IEEE software, vol. 24, no. 6, pp. 12–15, 2007

    work page 2007

  2. [2]

    What use is a backseat driver? A qualitative investigation of pair programming,

    D. L. Jones and S. D. Fleming, “What use is a backseat driver? A qualitative investigation of pair programming,” in2013 IEEE Symposium on Visual Languages and Human Centric Computing, C. Kelleher, M. M. Burnett, and S. Sauer, Eds. IEEE Computer Society, 2013, pp. 103–110

    work page 2013

  3. [3]

    Evaluating large language models trained on code,

    M. Chen, J. Tworek, H. Jun, Q. Yuan, H. Ponde, J. Kaplan, H. Edwards, Y . Burda, N. Joseph, G. Brockman, A. Ray, R. Puri, G. Krueger, M. Petrov, H. Khlaaf, G. Sastry, P. Mishkin, B. Chan, S. Gray, N. Ryder, M. Pavlov, A. Power, L. Kaiser, M. Bavarian, C. Winter, P. Tillet, F. P. Such, D. W. Cummings, M. Plappert, F. Chantzis, E. Barnes, A. Herbert-V oss, ...

    arXiv 2021

  4. [4]

    Expectation vs. experience: Evaluating the usability of code generation tools powered by large language models,

    P. Vaithilingam, T. Zhang, and E. L. Glassman, “Expectation vs. experience: Evaluating the usability of code generation tools powered by large language models,” inChi conference on human factors in computing systems extended abstracts, 2022, pp. 1–7

    2022

  5. [5]

    Measuring github copilot’s impact on productivity,

    A. Ziegler, E. Kalliamvakou, X. A. Li, A. Rice, D. Rifkin, S. Simister, G. Sittampalam, and E. Aftandilian, “Measuring github copilot’s impact on productivity,”Communications of the ACM, vol. 67, no. 3, pp. 54–63, 2024

    2024

  6. [6]

    On knowledge transfer skill in pair pro- gramming,

    F. Zieris and L. Prechelt, “On knowledge transfer skill in pair pro- gramming,” in2014 ACM-IEEE International Symposium on Empirical Software Engineering and Measurement, ESEM, M. Morisio, T. Dyb ˚a, and M. Torchiano, Eds. ACM, 2014, pp. 11:1–11:10

    work page 2014

  7. [7]

    Trade-offs for substituting a human with an agent in a pair programming context: The good, the bad, and the ugly,

    S. K. Kuttal, B. Ong, K. Kwasny, and P. Robe, “Trade-offs for substituting a human with an agent in a pair programming context: The good, the bad, and the ugly,” inCHI ’21: CHI Conference on Human Factors in Computing Systems, Y . Kitamura, A. Quigley, K. Isbister, T. Igarashi, P. Bjørn, and S. M. Drucker, Eds., 2021, pp. 243:1–243:20

    work page 2021

  8. [8]

    Knowledge transfer in pair programming: An in-depth analysis,

    L. Plonka, H. Sharp, J. Van der Linden, and Y . Dittrich, “Knowledge transfer in pair programming: An in-depth analysis,”International journal of human-computer studies, vol. 73, pp. 66–78, 2015

    work page 2015

Show all 32 references
  1. [9]

    Peer-to-peer teaching in higher education: A critical literature review,

    M. Stigmar, “Peer-to-peer teaching in higher education: A critical literature review,”Mentoring & Tutoring: partnership in learning, vol. 24, no. 2, pp. 124–136, 2016

    2016

  2. [10]

    Hattie,Visible learning: A synthesis of over 800 meta-analyses relating to achievement

    J. Hattie,Visible learning: A synthesis of over 800 meta-analyses relating to achievement. routledge, 2009

    2009

  3. [11]

    Is github copilot a substitute for human pair-programming? an empirical study,

    S. Imai, “Is github copilot a substitute for human pair-programming? an empirical study,” inProceedings of the ACM/IEEE 44th International Conference on Software Engineering: Companion Proceedings, 2022, pp. 319–321

    2022

  4. [12]

    Constructivism learning theory: A paradigm for teaching and learning,

    S. O. Bada and S. Olusegun, “Constructivism learning theory: A paradigm for teaching and learning,”Journal of Research & Method in Education, vol. 5, no. 6, pp. 66–70, 2015

    2015

  5. [13]

    When is it better to learn together? insights from research on collaborative learning,

    T. J. Nokes-Malach, J. E. Richey, and S. Gadgil, “When is it better to learn together? insights from research on collaborative learning,”Educational Psychology Review, vol. 27, pp. 645–656, 2015

    2015

  6. [14]

    The state of coopera- tive learning in postsecondary and professional settings,

    D. W. Johnson, R. T. Johnson, and K. Smith, “The state of coopera- tive learning in postsecondary and professional settings,”Educational psychology review, vol. 19, pp. 15–29, 2007

    2007

  7. [15]

    Peer teaching in higher education: A review,

    B. Goldschmid and M. L. Goldschmid, “Peer teaching in higher education: A review,”Higher education, vol. 5, no. 1, pp. 9–33, 1976

    1976

  8. [16]

    Vygotsky’s philosophy: Constructivism and its criticisms examined

    C. H. Liu and R. Matthews, “Vygotsky’s philosophy: Constructivism and its criticisms examined.”International education journal, vol. 6, no. 3, pp. 386–399, 2005

    2005

  9. [17]

    The psychogenesis of knowledge and its epistemological significance,

    J. Piaget, “The psychogenesis of knowledge and its epistemological significance,” inLanguage and Learning: The Debate Between Jean Piaget and Noam Chomsky, M. Piattelli-Palmarini, Ed. Harvard University Press, 1980, pp. 1–23

    1980

  10. [18]

    Embracing change with extreme programming,

    K. Beck, “Embracing change with extreme programming,”Computer, vol. 32, no. 10, pp. 70–77, 1999

    1999

  11. [19]

    Evaluating pair programming with respect to system complexity and programmer expertise,

    E. Arisholm, H. Gallis, T. Dyb ˚a, and D. I. K. Sjøberg, “Evaluating pair programming with respect to system complexity and programmer expertise,”IEEE Trans. Software Eng., vol. 33, no. 2, pp. 65–86, 2007

    2007

  12. [20]

    Pair programming: what’s in it for me?

    A. Begel and N. Nagappan, “Pair programming: what’s in it for me?” inProceedings of the Second ACM-IEEE international symposium on Empirical software engineering and measurement, 2008, pp. 120–128

    2008

  13. [21]

    Observations on knowledge transfer of profes- sional software developers during pair programming,

    F. Zieris and L. Prechelt, “Observations on knowledge transfer of profes- sional software developers during pair programming,” inProceedings of the 38th International Conference on Software Engineering, ICSE, L. K. Dillon, W. Visser, and L. A. Williams, Eds. ACM, 2016, pp. 242–250

    2016

  14. [22]

    Qualitative analysis of knowledge transfer in pair program- ming,

    F. Zieris, “Qualitative analysis of knowledge transfer in pair program- ming,” Ph.D. dissertation, 2020

    2020

  15. [23]

    An empirical evaluation of github copilot’s code suggestions,

    N. Nguyen and S. Nadi, “An empirical evaluation of github copilot’s code suggestions,” in19th IEEE/ACM International Conference on Mining Software Repositories, MSR. ACM, 2022, pp. 1–5

    2022

  16. [24]

    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,” 2023. [Online]. Available: https://arxiv.org/abs/2302.06590

    2023 arXiv

  17. [25]

    Is AI the better programming partner? Human-Human Pair Programming vs. Human-AI pAIr Programming,

    Q. Ma, T. Wu, and K. Koedinger, “Is AI the better programming partner? Human-Human Pair Programming vs. Human-AI pAIr Programming,”

  18. [26]

    Grounded copilot: How programmers interact with code-generating models,

    S. Barke, M. B. James, and N. Polikarpova, “Grounded copilot: How programmers interact with code-generating models,”Proceedings of the ACM on Programming Languages, vol. 7, no. OOPSLA1, pp. 85–111, 2023

    2023

  19. [27]

    Generative ai and developer workflows: How github copilot and chatgpt influence solo and pair programming,

    V . Stray, N. B. Moe, N. Ganeshan, and S. Kobbenes, “Generative ai and developer workflows: How github copilot and chatgpt influence solo and pair programming,” 2025

    2025

  20. [28]

    G. Fan, D. Liu, R. Zhang, and L. Pan, “The impact of ai-assisted pair programming on student motivation, programming anxiety, collaborative learning, and programming performance: a comparative study with traditional pair programming and individual approaches,”International Jou...

    2025

  21. [29]

    Measuring and modeling programming experience,

    J. Siegmund, C. K ¨astner, J. Liebig, S. Apel, and S. Hanenberg, “Measuring and modeling programming experience,”Empirical Software Engineering, vol. 19, pp. 1299–1334, 2014

    2014

  22. [30]

    The use of think-aloud methods in qualitative research an introduction to think-aloud methods,

    E. Charters, “The use of think-aloud methods in qualitative research an introduction to think-aloud methods,”Brock Education Journal, vol. 12, no. 2, 2003

    2003

  23. [31]

    Views on internal and external validity in empirical software engineering,

    J. Siegmund, N. Siegmund, and S. Apel, “Views on internal and external validity in empirical software engineering,” in2015 IEEE/ACM 37th IEEE International Conference on Software Engineering, vol. 1. IEEE, 2015, pp. 9–19

    2015

  24. [2023]

    Available: https://arxiv.org/abs/2306.05153

    [Online]. Available: https://arxiv.org/abs/2306.05153

    arXiv

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.