Pith. sign in

REVIEW 3 major objections 4 minor 32 references

ACE: Automated Technical Debt Remediation with Validated Large Language Model Refactorings

T0 review · 3 major / 4 minor · reviewed 2026-08-06 · deepseek-v4-flash

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

Pith's one-line read A validation layer that filters large-language-model refactorings allows ACE to deliver code improvements that are behavior-preserving and CodeHealth-positive in 98% of accepted cases.

desk verdict A plausible tool paper whose headline precision is inherited from a different benchmark and circular on the quality half; worth reviewing but needs a direct evaluation. read the letter →

arxiv 2507.03536 v1 pith:56V2EK2I submitted 2025-07-04 cs.SE

Adam Tornhill , Markus Borg , Nadim Hagatulah , Emma Söderberg This is my paper · ORCID
classification cs.SE
keywords technicaldebtrefactoringlargelanguagemodelscodequalityHealthvalidationguardrailssoftwaremaintenanceAIassistants
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

ACE is a tool that automates code refactoring by letting large language models propose rewrites and then running each suggestion through a validation layer before showing it to the developer. The paper's central claim is that this filtering is effective: after discarding low-confidence LLM output, 98% of the remaining refactorings both improve the CodeHealth score and preserve the original behavior, compared to 37% correctness for the best raw LLM. That changes the economics of technical debt remediation, because developers can act on AI suggestions without manually re-verifying every change. The tool is positioned as a practical answer to the finding that program understanding consumes roughly 70% of developer time.

What carries the argument

The load-bearing element is the validation layer: a sequence of checks that assigns a confidence level to each LLM-generated refactoring and discards low-confidence rewrites. The first check is syntactic validation using a static analysis tool; the second compares the targeted code smell and the overall CodeHealth score before and after the change; the final steps compare original and refactored code to confirm behavior is preserved and only minimal, expected changes were introduced. The other component is contextual LLM selection, in which a machine learning model chooses among several LLMs based on the properties of the code, which improves recall and decouples the tool from any single model provider.

What would settle it

Run ACE on a fresh sample of CodeHealth issues and have independent engineers plus differential testing judge the accepted refactorings; if more than 2% of accepted rewrites fail behavioral equivalence or are rated worse than the original design, the 98% precision claim collapses.

Watch

Extended reading notes

Core claim

The paper claims that refactoring has two requirements that make raw LLM output unsafe: a change must improve the design, and it must preserve behavior. ACE addresses both with a layered validation pipeline that checks syntax, verifies that the targeted code smell is removed and that CodeHealth improves, and finally applies semantic checks tailored to the specific code smell. The central discovery is that this guardrail approach elevates refactoring precision from 37% to 98% at a recall of 52%, making automated AI refactoring reliable enough for everyday developer use. The authors further claim that the validation needs to be deliberately scoped to a finite set of structural changes, since general semantic equivalence is an undecidable problem.

Load-bearing premise

The argument assumes that CodeHealth is a valid, objective measure of code quality, so that "CodeHealth improved" means the design actually improved.

Editorial extensions

If this is right

  • Developers can accept ACE-proposed refactorings without full manual re-verification, because rejected suggestions are filtered out and accepted ones are validated.
  • About half of the detected code smells can be refactored automatically with high confidence, which is enough to meaningfully reduce technical debt in practice.
  • Because validation is code-smell specific, the approach works today on five common smells across JavaScript, TypeScript, and Java, with more languages planned.
  • The multi-LLM design both raises recall and lets the tool absorb new models as they become available without changing the validation logic.

Reading between the lines

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

  • If CodeHealth truly tracks maintainability, the same validation pattern could be applied to other quality metrics and languages, extending automated refactoring beyond the five current smells.
  • The 52% recall ceiling is a property of today's LLMs; as models improve, the same validation layer should yield higher recall at the same precision, which is a testable prediction.
  • The semantic validation relies on pattern matching rather than full equivalence proving, so adding differential testing or property-based checks could catch adversarial rewrites that slip through.
  • ACE only targets function-level smells, so the worst organizational debt at the architecture level remains out of scope for now.
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 / 4 minor

Summary. The paper introduces ACE (Augmented Code Engineering), a proprietary IDE tool that combines LLM-generated code refactorings with a validation layer to automate technical debt remediation. The tool targets five code smells (Complex Conditional, Complex Method, Deep Nested Logic, Bumpy Road, Large Method) in JavaScript, TypeScript, and Java. The architecture uses contextual LLM selection and a multi-step validator that checks syntactic validity, CodeHealth improvement, and semantic equivalence. The paper claims 98% precision and 52% recall for ACE, citing the authors' prior technical report [28], and presents anecdotal feedback from internal and alpha users. The central quantitative claim is that ACE elevates LLM refactoring precision from 37% to 98% by discarding incorrect solutions before presenting suggestions to developers.

Significance. If the 98% precision figure were established for ACE's own pipeline, the tool would be a valuable contribution to automated technical debt remediation, a space where acting on maintainability findings is known to be difficult. The overall architecture—generate many LLM candidates, then filter with validation guardrails—is a sensible and increasingly standard approach for improving reliability of AI-generated code. The paper is also admirably explicit about the limits of semantic equivalence checking and scopes its validation to a fixed set of code smells. However, the headline quantitative claim is currently borrowed from a non-archival technical report rather than measured for the system described in this paper, and the validation-layer design makes the CodeHealth-improvement part of that claim tautological. As a result, the significance of the contribution is prospective rather than demonstrated; the paper would need an actual precision/recall evaluation of ACE's own validator to support its central claim.

major comments (3)
  1. [Section 2 and Section 7] The central claim that "ACE elevates the precision from 37% to 98%" and the conclusion that "ACE delivers high-confidence refactorings with 98% precision" rest entirely on the non-archival technical report [28], which is not included or summarized. The validation pipeline described in Section 5.2 (syntactic analysis, CodeHealth comparison, and semantic-pattern rules) differs in mechanism from the benchmark's evaluation using "accompanying test suites" described in Section 2. No experiment in this paper measures precision or recall of ACE as described; Section 6 reports only subjective feedback from two pilot users. As written, the paper conflates a property of a separate benchmark pipeline with a property of ACE, so the headline quantitative result is not supported by evidence in this manuscript.
  2. [Section 5.2, second validation step] The validator discards any refactoring suggestion where the targeted code smell remains or the CodeHealth score is lower. Consequently, every accepted refactoring is guaranteed to improve CodeHealth (assuming the metric computation is correct), making the "98% of the remaining AI-generated refactorings improve CodeHealth" statement an artifact of the selection rule rather than an independent empirical finding. The only non-tautological part of the precision claim is behavior preservation, and the paper provides no quantitative evidence for ACE's semantic validation achieving a 98% behavior-preservation rate. The reported 52% recall is likewise asserted in Section 2 and attributed to Contextual LLM Selection in Section 4 without any measurement of ACE's actual recall in this paper.
  3. [Section 5.2, semantic validation] The semantic validation layer, which is the only component that could substantiate the behavior-preservation half of the precision claim, is described only in general terms: "recurring patterns" captured during development, "general language-specific rules," and "internal machine learning models." The paper explicitly states that "the exact details cannot be disclosed," and the "data lake" of ground-truth refactorings is invoked as the "secret sauce." Without at least a summarized description of the semantic patterns, a false-positive measurement, or a held-out evaluation of the semantic equivalence checks, the central correctness guarantee is not independently assessable. This is a load-bearing gap for a paper whose title promises "Validated" LLM refactorings.
minor comments (4)
  1. [Section 6, Scope bullet] The sentence "far from all code quality problems can currently by automatically fixed" contains a typo: "by" should be "be."
  2. [Section 2, CodeHealth objectivity] The paper asserts that CodeHealth provides an "objective" assessment of design improvement, citing [5] and [27], which are authored by the same research group and company behind ACE. A brief acknowledgment of this possible conflict, or a pointer to an independent evaluation, would help calibrate the reader's trust in the CodeHealth gate.
  3. [Section 4, Contextual LLM Selection] The claim that the multi-LLM approach "improves ACE's recall" is presented as a design rationale but is not backed by an experiment in this paper. If recall data are available from [28], they should be summarized here; otherwise this should be phrased as an expectation.
  4. [Section 5.2, proprietary language] The phrase "the exact details cannot be disclosed" followed by "The quality of ACE's data lake ... is the secret sauce, not the algorithms" is more appropriate for marketing material than for a scientific paper. The paper should either disclose enough detail for the semantic-validation methodology to be evaluated or clearly mark the claims as unverifiable trade secrets.

Circularity Check

2 steps flagged · score 7.0 of 10

ACE's headline 98% precision is partly a selection criterion — Section 5.2 rejects any refactoring that does not improve CodeHealth — and partly imported from the authors' own technical report [28] without an ACE-specific measurement.

  1. self definitional [Section 5.2, 'LLM Validation Layer', second validation step]
    "The second step validates that the targeted code smell has been resolved and that the overall CodeHealth has been improved by the LLM-generated refactoring suggestion. This step compares the code smell and CodeHealth score of the original and the refactored code for differences. If the targeted code smell remains or if the CodeHealth score is lower in the refactoring suggestion, then ACE discards that refactoring suggestion."

    ACE's acceptance predicate for a refactoring includes 'overall CodeHealth has been improved' and discards any suggestion whose CodeHealth is lower. Therefore, for the set of refactorings that ACE presents as validated, 'the refactoring improves CodeHealth' is true by construction, not by independent measurement. Section 2 nonetheless reports this property as the validated outcome: '98% of the remaining AI-generated refactorings improve CodeHealth while retaining the original behavior.' The CodeHealth-improvement half of the precision claim is the selection rule itself, so it cannot count as an empirical finding about the quality of the accepted refactorings.

  2. self citation load bearing [Section 2, 'Background'; echoed in Section 7, 'Conclusion']
    "By discarding incorrect solutions, 98% of the remaining AI-generated refactorings improve CodeHealth while retaining the original behavior [28]. That is, ACE elevates the precision from 37% to 98%."

    The 98% precision figure is imported from the authors' own technical report [28], whose validation pipeline is described as test-suite-based behavior evaluation plus CodeHealth assessment. No experiment in this paper measures precision or recall for ACE's actual validator described in Section 5.2, which uses syntactic checks, proprietary CodeHealth scoring, and learned semantic patterns. The conclusion nevertheless attributes the benchmark's precision to ACE: 'ACE delivers high-confidence refactorings with 98% precision.' Because the load-bearing quantitative claim is not established for the present tool and rests on a self-citation to [28], the paper's central precision claim reduces to an unverified transfer of a prior benchmark result to ACE.

full rationale

The paper's tool-building content — dynamic prompting, multi-LLM selection, integration with CodeScene, and user feedback — is self-contained and not circular. However, the headline quantitative claim is two-part, and each part has a circular or self-citation problem. The CodeHealth-improvement component is definitional for ACE: Section 5.2's second validation step discards every suggestion whose CodeHealth did not improve, so any refactoring shown to the user trivially passes that condition; reporting it as a validated 98% outcome conflates the acceptance filter with an independent result. The behavior-preservation component is the only empirically informative part, but the paper does not measure it for ACE; it borrows the 98% figure from the authors' own prior technical report [28], which used test-suite validation, while ACE's Section 5.2 semantic validation is described as proprietary 'recurring patterns' and internally learned models. No ACE-specific precision or recall experiment appears in the paper. Thus the central claim is partially circular by construction and partially load-bearing on self-citation. I do not count the CodeHealth validity citations [5, 27] as circular per se, because they are empirical correlation studies even though authored by the same group; the circularity lies in the selection rule and the borrowed precision number, not in the metric's external validation.

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

The central claim rests on CodeHealth as ground truth for quality and on undisclosed semantic heuristics. No independent benchmark is provided in this paper, and the main evaluation is carried over from the authors' own technical report. The success metric is also the acceptance filter, which creates a tautology for the quality dimension.

free parameters (1)
  • CodeHealth thresholds and CodeScene code-smell definitions = undisclosed
    The tool's detection and validation are driven by proprietary code-smell thresholds and CodeHealth aggregation weights. These are not reported in the paper, yet the precision and recall claims depend on them entirely.
assumptions (4)
  • domain assumption CodeHealth is a valid and objective measure of code design quality and maintainability.
    Section 2 asserts that comparing CodeHealth before and after refactoring objectively assesses design improvement. The cited evidence ([5], [27]) is authored within the same research group and company, and no independent validation is provided in this paper.
  • domain assumption The five targeted code smells (Complex Conditional, Complex Method, Deep Nested Logic, Bumpy Road, Large Method) are appropriate refactoring targets whose removal improves maintainability.
    Section 5.3 lists the supported smells, but the paper provides no external justification that these five classes dominate technical debt or that removing them improves maintainability independently of how CodeHealth defines them.
  • domain assumption The semantic validation heuristics are sufficient to detect behavior-changing refactorings for the supported smell set.
    Section 5.2 acknowledges semantic equivalence is undecidable and that validation is constrained to smell-specific structural patterns. The completeness and correctness of these patterns are not demonstrated.
  • domain assumption The data lake of hundreds of thousands of refactorings with known ground truths is reliable.
    Section 5.2 calls the data lake 'the secret sauce,' but the paper gives no details on how ground truths were labeled, verified, or made representative of real-world code.

how reviews work

0 comments
Cite this review

Pith. "Pith review of ACE: Automated Technical Debt Remediation with Validated Large Language Model Refactorings." pith.science (2026). https://pith.science/paper/56V2EK2I

@misc{pith2026250703536,
  author       = {Pith},
  title        = {Pith review of: ACE: Automated Technical Debt Remediation with Validated Large Language Model Refactorings},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/56V2EK2I}},
  note         = {Machine review of arXiv:2507.03536}
}
read the original abstract

The remarkable advances in AI and Large Language Models (LLMs) have enabled machines to write code, accelerating the growth of software systems. However, the bottleneck in software development is not writing code but understanding it; program understanding is the dominant activity, consuming approximately 70% of developers' time. This implies that improving existing code to make it easier to understand has a high payoff and - in the age of AI-assisted coding - is an essential activity to ensure that a limited pool of developers can keep up with ever-growing codebases. This paper introduces Augmented Code Engineering (ACE), a tool that automates code improvements using validated LLM output. Developed through a data-driven approach, ACE provides reliable refactoring suggestions by considering both objective code quality improvements and program correctness. Early feedback from users suggests that AI-enabled refactoring helps mitigate code-level technical debt that otherwise rarely gets acted upon.

Figures

Figures reproduced from arXiv: 2507.03536 by the authors.

Figure 1
Figure 1. The high-level architecture of the ACE tool for reliable LLM-enabled refactoring. [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. ACE offers automated refactoring of issues discovered in the CodeHealth quality gate. [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Flowchart for the validation layer for assigning a [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Example of a high confidence extract method refactoring. [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 5
Figure 5. Figure 5: Example of a mid confidence refactoring that simplifies cyclomatic complexity. [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

32 extracted references · 30 canonical work pages

  1. [28]

    Adam Tornhill, Markus Borg, and Enys Mones. 2024. Refactoring vs Refuctoring: Advancing the State of AI-automated Code Improvements . Technical Report. CodeScene. https://tinyurl.com/refuctoring

    work page 2024

  2. [1]

    Areti Ampatzoglou, Apostolos Ampatzoglou, Alexander Chatzigeorgiou, and Paris Avgeriou. 2015. The Financial Aspect of Managing Technical Debt: A Systematic Literature Review. Info. and Softw. Technology 64 (2015), 52–73

    work page 2015

  3. [2]

    Paris Avgeriou, Philippe Kruchten, Ipek Ozkaya, and Carolyn Seaman. 2016. Man- aging Technical Debt in Softw. Engineering (Dagstuhl Seminar 16162). Dagstuhl Reports 6, 4 (2016), 110–138

    work page 2016

  4. [3]

    Paris C. Avgeriou, Davide Taibi, Apostolos Ampatzoglou, Francesca Ar- celli Fontana, Terese Besker, Alexander Chatzigeorgiou, Valentina Lenarduzzi, Antonio Martini, Athanasia Moschou, Ilaria Pigazzini, Nyyti Saarimaki, Dar- ius Daniel Sas, Saulo Soares de Toledo, and Angeliki Agathi Tsintzira. 2021. An Overview and Comparison of Technical Debt Measurement...

    work page 2021

  5. [4]

    Markus Borg, Marwa Ezzouhri, and Adam Tornhill. 2024. Ghost Echoes Re- vealed: Benchmarking Maintainability Metrics and Machine Learning Predictions Against Human Assessments. InProc. of the 40th Int’l. Conf. on Softw. Maintenance and Evolution. 278–288

    work page 2024

  6. [5]

    Markus Borg, Ilyana Pruvost, Enys Mones, and Adam Tornhill. 2024. Increasing, Not Diminishing: Investigating the Returns of Highly Maintainable Code. InProc. of the 7th Int’l. Conf. on Technical Debt . 21–30

    work page 2024

  7. [6]

    Sayed Mehdi Hejazi Dehaghani and Nafiseh Hajrahimi. 2013. Which Factors Affect Softw. Projects Maintenance Cost More? Acta Informatica Medica 21, 1 (2013), 63–66

    work page 2013

  8. [7]

    Florian Deissenboeck and Markus Pizka. 2006. Concise and Consistent Naming. Softw. Quality Journal 14, 3 (2006), 261–282

    work page 2006

Show all 32 references
  1. [8]

    Neil Ernst, Rick Kazman, and Julien Delange. 2021. Technical Debt in Practice: How to Find It and Fix It . The MIT Press, Cambridge, Massachusetts

    2021

  2. [9]

    Sara Fernandes, Ademar Aguiar, and André Restivo. 2023. LiveRef: a Tool for Live Refactoring Java Code. In Proc. of the 37th IEEE/ACM Int’l. Conf. on Automated Softw. Engineering (Rochester, MI, USA). Article 161

    2023

  3. [10]

    Martin Fowler. 2018. Refactoring: Improving the Design of Existing Code (2 ed.). Addison-Wesley Professional

    2018

  4. [11]

    William Harding and Matthew Kloster. 2024. Coding on Copilot . Technical Report. GitClear. https://gitclear-public.s3.us-west-2.amazonaws.com/Coding- on-Copilot-2024-Developer-Research.pdf

    2024

  5. [12]

    Le, David Lo, Nhat-Hoa Tran, Bui Quang-Huy, and Quyet-Thang Huynh

    Thanh Le-Cong, Duc-Minh Luong, Xuan Bach D. Le, David Lo, Nhat-Hoa Tran, Bui Quang-Huy, and Quyet-Thang Huynh. 2023. Invalidator: Automated Patch Correctness Assessment Via Semantic and Syntactic Reasoning. IEEE Trans. Softw. Eng. 49, 6 (2023), 3411–3429

    2023

  6. [13]

    Claire Le Goues, Michael Pradel, and Abhik Roychoudhury. 2019. Automated Program Repair. Commun. ACM 62, 12 (2019), 56–65

    2019

  7. [14]

    Valentina Lenarduzzi, Fabiano Pecorelli, Nyyti Saarimaki, Savanna Lujan, and Fabio Palomba. 2023. A Critical Comparison on Six Static Analysis Tools: De- tection, Agreement, and Precision. Journal of Systems and Softw. 198 (2023), 111575

    2023

  8. [15]

    Valentina Lenarduzzi, Alberto Sillitti, and Davide Taibi. 2020. A Survey on Code Analysis Tools for Softw. Maintenance Prediction. In Proc. of the 6th Int’l. Conf. in Softw. Engineering for Defence Applications . Cham, 165–175

    2020

  9. [16]

    Zengyang Li, Paris Avgeriou, and Peng Liang. 2015. A Systematic Mapping Study on Technical Debt and Its Management. Journal of Systems and Softw. 101 (2015), 193–220

    2015

  10. [17]

    Bo Liu, Yanjie Jiang, Yuxia Zhang, Nan Niu, Guangjie Li, and Hui Liu. 2024. An Empirical Study on the Potential of LLMs in Automated Software Refactoring. (2024). https://doi.org/10.48550/arXiv.2411.04444

    2024 doi arXiv

  11. [18]

    Antonio Martini, Terese Besker, and Jan Bosch. 2018. Technical Debt Track- ing: Current State of Practice: A Survey and Multiple Case Study in 15 Large Organizations. Science of Computer Programming 163 (2018), 42–61

    2018

  12. [19]

    Roberto Minelli, Andrea Mocci, and Michele Lanza. 2015. I Know What You Did Last Summer - An Investigation of How Developers Spend Their Time. In Proc. of the 23rd Int’l. Conf. on Program Comprehension . 25–35

    2015

  13. [20]

    Murphy-Hill and G

    E. Murphy-Hill and G. Murphy. 2014. Recommendation Delivery. In Recom- mendation Systems in Softw. Engineering , M. Robillard, W. Maalej, R. Walker, and T. Zimmermann (Eds.). Springer, 223–242

    2014

  14. [21]

    Elise Paradis, Kate Grey, Quinn Madison, Daye Nam, Andrew Macvean, Nan Zhang, Ben Ferrari-Church, and Satish Chandra. 2024. How Much Does AI Impact Development Speed? An Enterprise-based Randomized Controlled Trial. http://arxiv.org/abs/2410.12944

    2024 arXiv

  15. [22]

    Sida Peng, Eirini Kalliamvakou, Peter Cihon, and Mert Demirer. 2023. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot

    2023

  16. [23]

    Dorin Pomian, Abhiram Bellur, Malinda Dilhara, Zarina Kurbatova, Egor Bogo- molov, Timofey Bryksin, and Danny Dig. 2024. Next-Generation Refactoring: Combining LLM Insights and IDE Capabilities for Extract Method. In Proc. of the 40th Int’l. Conf. on Softw. Maintenance and Evolution

    2024

  17. [24]

    Markus Schnappinger, Arnaud Fietzke, and Alexander Pretschner. 2020. Defining a Softw. Maintainability Dataset: Collecting, Aggregating and Analysing Expert Evaluations of Softw. Maintainability. In Proc. of the 36th Int’l. Conf. on Softw. Maintenance and Evolution. 278–289

    2020

  18. [25]

    Atsushi Shirafuji, Yusuke Oda, Jun Suzuki, Makoto Morishita, and Yutaka Watanobe. 2023. Refactoring Programs Using Large Language Models with Few-Shot Examples . In Proc. of the 30th Asia-Pacific Softw. Engineering Conf. 151–160

    2023

  19. [26]

    Stripe. 2018. The Developer Coefficient: Softw. engineering efficiency and its $3 trillion impact on global GDP . Technical Report. https://stripe.com/reports/ developer-coefficient-2018

    2018

  20. [27]

    Adam Tornhill and Markus Borg. 2022. Code Red: The Business Impact of Code Quality - A Quantitative Study of 39 Proprietary Production Codebases. In Proc. of the 5th Int’l. Conf. on Technical Debt . 11–20

    2022

  21. [29]

    Roberto Verdecchia, Philippe Kruchten, Patricia Lago, and Ivano Malavolta. 2021. Building and evaluating a theory of architectural technical debt in software- intensive systems. Journal of Systems and Softw. 176 (2021), 110925

    2021

  22. [30]

    Yi Wang, Christian Wagner, and Rachael Ip. 2009. An Empirical Investigation of the Key Factors for Refactoring Success in an Industrial Context. In Proc. of the 15th Americas Conf. on Information Systems (577)

    2009

  23. [31]

    Hassan, and Shan- ping Li

    Xin Xia, Lingfeng Bao, David Lo, Zhenchang Xing, Ahmed E. Hassan, and Shan- ping Li. 2018. Measuring program comprehension: a large-scale field study with professionals. In Proc. of the 40th Int’l. Conf. on Softw. Engineering . 584

    2018

  24. [32]

    Burak Yetistiren, Isik Ozsoy, and Eray Tuzun. 2022. Assessing the Quality of GitHub Copilot’s Code Generation. In Proc. of the 18th Int’l. Conf. on Predictive Models and Data Analytics in Softw. Engineering . 62–71

    2022

Pith tools

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