CCCE: A Continuous Code Calibration Engine for Autonomous Enterprise Codebase Maintenance via Knowledge Graph Traversal and Adaptive Decision Gating

Santhosh Kusuma Kumar Parimi

arxiv: 2604.13102 · v1 · submitted 2026-04-10 · 💻 cs.SE · cs.AI

CCCE: A Continuous Code Calibration Engine for Autonomous Enterprise Codebase Maintenance via Knowledge Graph Traversal and Adaptive Decision Gating

Santhosh Kusuma Kumar Parimi This is my paper

Pith reviewed 2026-05-10 17:12 UTC · model grok-4.3

classification 💻 cs.SE cs.AI

keywords enterprise code maintenanceknowledge graphbidirectional traversalrisk-based gatingAI agentic systemscontinuous learningdependency managementautonomous calibration

0 comments

The pith

The Continuous Code Calibration Engine uses a dynamic knowledge graph and adaptive risk gating to autonomously maintain large enterprise codebases and reduce remediation time.

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

Enterprise codebases that span many repositories, languages, and packages are difficult to keep secure and current because existing tools work in isolation and need heavy manual work to propagate changes. The paper introduces the Continuous Code Calibration Engine as an event-driven AI system that builds a live knowledge graph of dependencies and uses bidirectional traversal to calculate change impacts and test needs in both directions. An adaptive gating system then scores each possible calibration action by learned risk and , routing low-risk actions to automatic execution while reserving higher tiers for human review. Demonstrations in three enterprise scenarios show this approach coordinates cross-repository updates and lowers mean time to remediation.

Core claim

The CCCE formalizes a dynamic knowledge graph with bidirectional traversal algorithms that compute forward impact propagation and backward test adequacy analysis, an adaptive multi-stage gating framework that classifies calibration actions into four risk tiers using learned risk-confidence scoring, and a multi-model continuous learning architecture that refines strategies and policies from operational feedback. In three representative enterprise scenarios the system produces atomic, semantically verified patches with progressive validation and rollback, delivering end-to-end traceability and reduced mean time to remediation through coordinated, cross-repository calibrations with human-in-the

What carries the argument

The bidirectional traversal algorithms on the dynamic knowledge graph that simultaneously compute forward impact propagation and backward test adequacy to inform risk-based calibration decisions.

If this is right

The system generates atomic patches that are semantically verified before execution and support intelligent rollback.
Calibration actions are classified into four risk tiers so that only high-risk cases invoke human oversight.
Continuous learning at multiple time scales updates risk models and organizational policies from feedback.
All actions maintain end-to-end traceability from the triggering event through execution and outcome recording.

Where Pith is reading between the lines

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

If the traversal scales efficiently, the same engine could support codebases larger than the three demonstrated scenarios.
The learned gating could be extended to incorporate security vulnerability scores as an additional risk dimension.
Integration points with existing continuous-integration pipelines would allow the system to trigger automatically on commit events.

Load-bearing premise

The knowledge graph accurately captures all relevant code dependencies and test coverage across multiple languages and repositories, and the learned risk-confidence models generalize without introducing new errors or excessive false positives.

What would settle it

A run of the system on a multi-repository enterprise codebase in which a calibration action misses a hidden cross-language dependency and produces an unpredicted build or test failure.

Figures

Figures reproduced from arXiv: 2604.13102 by Santhosh Kusuma Kumar Parimi.

**Figure 2.** Figure 2: Three-gate decision logic for calibration action classi [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗

read the original abstract

Enterprise software organizations face an escalating challenge in maintaining the integrity, security, and freshness of codebases that span hundreds of repositories, multiple programming languages, and thousands of interdependent packages. Existing approaches to codebase maintenance -- including static analysis, software composition analysis (SCA), and dependency management tools -- operate in isolation, address only narrow subsets of maintenance concerns, and require substantial manual intervention to propagate changes across interconnected systems. We present the Continuous Code Calibration Engine (CCCE), an event-driven, AI-agentic system that autonomously maintains enterprise codebases throughout the Software Development Life Cycle (SDLC). The CCCE introduces three key technical innovations: (1) a dynamic knowledge graph with bidirectional traversal algorithms that simultaneously compute forward impact propagation and backward test adequacy analysis; (2) an adaptive multi-stage gating framework that classifies calibration actions into four risk tiers using learned risk-confidence scoring rather than static rules; and (3) a multi-model continuous learning architecture operating at multiple temporal scales to refine calibration strategies, risk models, and organizational policies from operational feedback. We formalize the system's graph model, traversal algorithms, and decision logic, and demonstrate through three representative enterprise scenarios that the CCCE reduces mean time to remediation by enabling coordinated, cross-repository calibrations with human-in-the-loop (HITL) oversight where appropriate. The system generates atomic, semantically verified patches with progressive validation and intelligent rollback capabilities, providing end-to-end traceability from triggering events through calibration execution and outcome learning.

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.

Desk Editor's Note private letter to a colleague

CCCE lays out a coherent architecture for graph-based impact analysis and adaptive code calibration but rests its MTTR reduction claim on three high-level scenarios that supply no numbers, baselines, or controls.

read the letter

The main takeaway is that this paper describes a named system combining bidirectional knowledge-graph traversal, four-tier learned risk gating, and multi-scale continuous learning to handle cross-repository code changes with minimal human input. The formalization of the graph model and traversal algorithms is the clearest piece of new work here, as it ties forward propagation and backward test adequacy into one pass rather than treating them separately. The adaptive gating that replaces static rules with confidence scores and the multi-model feedback loop are presented as integrated rather than bolted-on, which is a reasonable engineering step even if the individual pieces draw from existing graph and RL literature. The end-to-end traceability and rollback mechanism are also practical additions that address real deployment concerns in large codebases. The paper does a service by spelling out how these components interact across the SDLC and by including human-in-the-loop as an explicit option rather than an afterthought. That said, the central claim that the system reduces mean time to remediation is supported only by narrative descriptions of three scenarios. No before-and-after values, no comparison to static analysis or SCA tools, no false-positive rates, and no details on how the scenarios were constructed or measured appear in the text. Without those, the demonstration stays at the level of illustration. The assumption that the dynamic graph captures all relevant dependencies and test coverage across languages and repositories is stated but not stress-tested, and the continuous-learning loop could introduce circularity if performance signals are reused for both training and evaluation. Readers working on enterprise maintenance tooling or AI agents for software engineering will find the architecture useful as a reference design. Academics looking for a new theorem or a controlled experiment will not. The formal sections are solid enough to merit referee time, so the paper should go to review rather than be desk-rejected; the referees can then require concrete metrics and baseline comparisons.

Referee Report

2 major / 2 minor

Summary. The paper introduces the Continuous Code Calibration Engine (CCCE), an event-driven AI-agentic system for autonomous maintenance of enterprise codebases spanning multiple repositories and languages. Key innovations include a dynamic knowledge graph with bidirectional traversal for forward impact propagation and backward test adequacy analysis, an adaptive multi-stage gating framework classifying actions into four risk tiers using learned risk-confidence scoring, and a multi-model continuous learning architecture that refines strategies from operational feedback. The authors formalize the graph model, traversal algorithms, and decision logic, and claim to demonstrate MTTR reduction through three representative enterprise scenarios involving coordinated cross-repository calibrations with HITL oversight, atomic patch generation, progressive validation, and intelligent rollback.

Significance. If the empirical claims hold, this work could significantly advance automated codebase maintenance by integrating knowledge graphs, adaptive decision-making, and continuous learning to handle complex, interdependent systems beyond isolated static analysis or SCA tools. The formalization of the graph model, traversal algorithms, and decision logic provides a solid theoretical foundation and is a clear strength.

major comments (2)

[§5 (Scenario Demonstrations)] §5 (Scenario Demonstrations): The central claim that CCCE reduces mean time to remediation is not supported by any quantitative evidence such as before/after MTTR values, baseline comparisons to SCA or static tools, false-positive rates, rollback statistics, or error bars. The three scenarios remain high-level narrative descriptions without controls or metrics, leaving the demonstration unverified.
[§4 (Adaptive Gating Framework) and §3 (Knowledge Graph Model)] §4 (Adaptive Gating Framework) and §3 (Knowledge Graph Model): The four-tier risk classification and bidirectional traversal assume the graph captures all dependencies and that learned models generalize without new errors, but no precision/recall figures, cross-language validation, or ablation on traversal completeness are reported to substantiate this.

minor comments (2)

[Abstract and §1] Abstract and §1: Clarify the construction details of the three enterprise scenarios (e.g., languages, repository sizes, triggering events) to improve reproducibility.
[§3] Notation in §3: Ensure consistent symbols for graph nodes, edges, and traversal directions across equations and text.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive feedback on our manuscript. We address each major comment below and describe the revisions we will make to improve clarity and balance.

read point-by-point responses

Referee: [§5 (Scenario Demonstrations)] The central claim that CCCE reduces mean time to remediation is not supported by any quantitative evidence such as before/after MTTR values, baseline comparisons to SCA or static tools, false-positive rates, rollback statistics, or error bars. The three scenarios remain high-level narrative descriptions without controls or metrics, leaving the demonstration unverified.

Authors: We agree that the manuscript does not provide quantitative MTTR data, baselines, or statistical measures. The three scenarios in §5 are narrative illustrations of the end-to-end workflow (impact propagation, atomic patching, progressive validation, and rollback) drawn from representative enterprise cases, rather than controlled experiments. The abstract and introduction use the term 'demonstrate' to describe how the mechanisms enable faster remediation, but this is not supported by numerical evidence. In revision, we will change the language in the abstract and §5 to state that the scenarios illustrate the potential for MTTR reduction via the described processes. We will add a dedicated 'Evaluation Limitations and Future Work' subsection that explicitly notes the absence of quantitative metrics and outlines plans for future controlled studies with before/after measurements and tool comparisons. revision: yes
Referee: [§4 (Adaptive Gating Framework) and §3 (Knowledge Graph Model)] The four-tier risk classification and bidirectional traversal assume the graph captures all dependencies and that learned models generalize without new errors, but no precision/recall figures, cross-language validation, or ablation on traversal completeness are reported to substantiate this.

Authors: The referee is correct that §§3 and 4 present the graph model, traversal algorithms, and four-tier gating logic without accompanying empirical validation such as precision/recall for dependency extraction, cross-language results, or ablation studies on traversal completeness. The manuscript focuses on formalization and algorithmic design rather than a comprehensive experimental evaluation. We do not have these specific metrics available for the current submission. In the revised version, we will insert a new 'Limitations' section that openly acknowledges the assumptions regarding graph completeness and model generalization, notes the lack of reported validation statistics, and describes planned future work on cross-language experiments and ablation analyses. This addition will not change the core technical contributions but will provide necessary context. revision: partial

Circularity Check

0 steps flagged

No circularity in derivation chain

full rationale

The abstract and description formalize a dynamic knowledge graph with bidirectional traversal, an adaptive four-tier gating framework using learned risk-confidence scoring, and a multi-model continuous learning architecture that refines strategies from operational feedback. No equations, self-referential definitions, fitted parameters renamed as predictions, or self-citation chains appear in the provided text. The three enterprise scenarios are presented as demonstrations of MTTR reduction but contain no quantitative metrics, baselines, or closed-loop evaluation details that would reduce claims to construction from inputs. The central claims rest on described mechanisms and narrative scenarios rather than any tautological reduction, making the derivation self-contained.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

Full text unavailable; abstract implies but does not enumerate free parameters such as risk-tier thresholds, learning rates, or graph-construction heuristics. No explicit axioms or invented entities are stated.

pith-pipeline@v0.9.0 · 5567 in / 1226 out tokens · 40194 ms · 2026-05-10T17:12:12.495277+00:00 · methodology

discussion (0)

Reference graph

Works this paper leans on

25 extracted references · 25 canonical work pages

[1]

An empirical comparison of dependency network evolution in seven software packaging ecosystems,

A. Decan, T. Mens, and P. Grosjean, “An empirical comparison of dependency network evolution in seven software packaging ecosystems,” Empirical Software Engineering, vol. 24, no. 1, pp. 381–416, 2019

work page 2019
[2]

Vuln4Real: A methodology for counting actually vulnerable depen- dencies,

I. Pashchenko, H. Plate, S. E. Ponta, A. Sabetta, and F. Massacci, “Vuln4Real: A methodology for counting actually vulnerable depen- dencies,”IEEE Transactions on Software Engineering, vol. 48, no. 5, pp. 1592–1609, 2022

work page 2022
[3]

How developers engage with static analysis tools in different contexts,

C. Vassallo, S. Panichella, F. Palomba, S. Proksch, A. Zaidman, and H. C. Gall, “How developers engage with static analysis tools in different contexts,”Empirical Software Engineering, vol. 25, no. 2, pp. 1419– 1457, 2020

work page 2020
[4]

Impact assessment for vulnera- bilities in open-source software libraries,

H. Plate, S. E. Ponta, and A. Sabetta, “Impact assessment for vulnera- bilities in open-source software libraries,” inProc. IEEE International Conference on Software Maintenance and Evolution (ICSME), 2015, pp. 411–420

work page 2015
[5]

Structure and evolution of package dependency networks,

R. Kikas, G. Gousios, M. Dumas, and D. Pfahl, “Structure and evolution of package dependency networks,” inProc. IEEE/ACM International Conference on Mining Software Repositories (MSR), 2017, pp. 102–112

work page 2017
[6]

Continuous integration, delivery and deployment: A systematic review on approaches, tools, challenges and practices,

M. Shahin, M. A. Babar, and L. Zhu, “Continuous integration, delivery and deployment: A systematic review on approaches, tools, challenges and practices,”IEEE Access, vol. 5, pp. 3909–3943, 2017

work page 2017
[7]

Small world with high risks: A study of security threats in the npm ecosystem,

M. Zimmermann, C. A. Staicu, C. Tenny, and M. Pradel, “Small world with high risks: A study of security threats in the npm ecosystem,” in Proc. USENIX Security Symposium, 2019, pp. 995–1010

work page 2019
[8]

Managing architectural technical debt: A unified model and systematic literature review,

T. Besker, A. Martini, and J. Bosch, “Managing architectural technical debt: A unified model and systematic literature review,”Journal of Systems and Software, vol. 135, pp. 1–16, 2018

work page 2018
[9]

VulDeePecker: A deep learning-based system for vulnerability detec- tion,

Z. Li, D. Zou, S. Xu, X. Ou, H. Jin, S. Wang, Z. Deng, and Y . Zhong, “VulDeePecker: A deep learning-based system for vulnerability detec- tion,” inProc. Network and Distributed System Security Symposium (NDSS), 2018, pp. 1–15

work page 2018
[10]

An empirical analysis of vulnerabilities in Python packages for web applications,

J. Ruohonen, S. Hyrynsalmi, and V . Lepp¨anen, “An empirical analysis of vulnerabilities in Python packages for web applications,” inProc. Inter- national Workshop on Emerging Trends in Software Metrics (WETSoM), 2018, pp. 25–31

work page 2018
[11]

Empirical analysis of security vulnerabilities in Python packages,

M. Alfadel, D. E. Costa, and E. Shihab, “Empirical analysis of security vulnerabilities in Python packages,”Empirical Software Engineering, vol. 26, no. 3, pp. 1–31, 2021

work page 2021
[12]

GenProg: A generic method for automatic software repair,

C. Le Goues, T. Nguyen, S. Forrest, and W. Weimer, “GenProg: A generic method for automatic software repair,”IEEE Transactions on Software Engineering, vol. 38, no. 1, pp. 54–72, 2012

work page 2012
[13]

SemFix: Program repair via semantic analysis,

H. D. T. Nguyen, D. Qi, A. Roychoudhury, and S. Chandra, “SemFix: Program repair via semantic analysis,” inProc. International Conference on Software Engineering (ICSE), 2013, pp. 772–781

work page 2013
[14]

SequenceR: Sequence-to-sequence learning for end- to-end program repair,

Z. Chen, S. J. Kommrusch, M. Tufano, L. Pouchet, D. Poshyvanyk, and M. Monperrus, “SequenceR: Sequence-to-sequence learning for end- to-end program repair,”IEEE Transactions on Software Engineering, vol. 47, no. 9, pp. 1943–1959, 2021

work page 1943
[15]

Conversational automated program repair,

C. S. Xia and L. Zhang, “Conversational automated program repair,” inProc. IEEE/ACM International Conference on Automated Software Engineering (ASE), 2023, pp. 1–13

work page 2023
[16]

Deep code search,

X. Gu, H. Zhang, and S. Kim, “Deep code search,” inProc. International Conference on Software Engineering (ICSE), 2018, pp. 933–944

work page 2018
[17]

Holistic combination of structural and textual code information for context based API recommendation,

C. Chen, X. Peng, Z. Xing, J. Sun, X. Wang, Y . Zhao, and W. Zhao, “Holistic combination of structural and textual code information for context based API recommendation,”IEEE Transactions on Software Engineering, vol. 48, no. 8, pp. 2987–3003, 2022

work page 2022
[18]

D2A: A dataset built for AI-based vulnerability detection methods using differential analysis,

Y . Zheng, S. Pujar, B. Lewis, L. Buratti, E. Epstein, B. Yang, J. Laredo, A. Morari, and Z. Su, “D2A: A dataset built for AI-based vulnerability detection methods using differential analysis,” inProc. International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), 2021, pp. 111–120

work page 2021
[19]

A survey of DevOps concepts and challenges,

L. Leite, C. Rocha, F. Kon, D. Milojicic, and P. Meirelles, “A survey of DevOps concepts and challenges,”ACM Computing Surveys, vol. 52, no. 6, pp. 1–35, 2019

work page 2019
[20]

AIOps: Real-world challenges and research innovations,

Y . Dang, Q. Lin, and P. Huang, “AIOps: Real-world challenges and research innovations,” inProc. International Conference on Software Engineering: Companion (ICSE-Companion), 2019, pp. 4–5

work page 2019
[21]

Surviving software dependencies,

R. Cox, “Surviving software dependencies,”Communications of the ACM, vol. 62, no. 9, pp. 36–43, 2019

work page 2019
[22]

When and how to make breaking changes: Policies and practices in 18 open source software ecosystems,

C. Bogart, C. K ¨astner, J. Herbsleb, and F. Thung, “When and how to make breaking changes: Policies and practices in 18 open source software ecosystems,”ACM Transactions on Software Engineering and Methodology, vol. 30, no. 4, pp. 1–56, 2021

work page 2021
[23]

Can automated pull requests encourage software developers to upgrade out-of-date dependencies?,

S. Mirhosseini and C. Parnin, “Can automated pull requests encourage software developers to upgrade out-of-date dependencies?,” inProc. IEEE/ACM International Conference on Automated Software Engineer- ing (ASE), 2017, pp. 84–94

work page 2017
[24]

Do developers update their library dependencies?,

R. G. Kula, D. M. German, A. Ouni, T. Ishio, and K. Inoue, “Do developers update their library dependencies?,”Empirical Software Engineering, vol. 23, no. 1, pp. 384–417, 2018

work page 2018
[25]

What are weak links in the npm supply chain?,

N. Zahan, T. Zimmermann, P. Godefroid, B. Murphy, C. Maddila, and L. Williams, “What are weak links in the npm supply chain?,” inProc. International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), 2022, pp. 331–340

work page 2022

[1] [1]

An empirical comparison of dependency network evolution in seven software packaging ecosystems,

A. Decan, T. Mens, and P. Grosjean, “An empirical comparison of dependency network evolution in seven software packaging ecosystems,” Empirical Software Engineering, vol. 24, no. 1, pp. 381–416, 2019

work page 2019

[2] [2]

Vuln4Real: A methodology for counting actually vulnerable depen- dencies,

I. Pashchenko, H. Plate, S. E. Ponta, A. Sabetta, and F. Massacci, “Vuln4Real: A methodology for counting actually vulnerable depen- dencies,”IEEE Transactions on Software Engineering, vol. 48, no. 5, pp. 1592–1609, 2022

work page 2022

[3] [3]

How developers engage with static analysis tools in different contexts,

C. Vassallo, S. Panichella, F. Palomba, S. Proksch, A. Zaidman, and H. C. Gall, “How developers engage with static analysis tools in different contexts,”Empirical Software Engineering, vol. 25, no. 2, pp. 1419– 1457, 2020

work page 2020

[4] [4]

Impact assessment for vulnera- bilities in open-source software libraries,

H. Plate, S. E. Ponta, and A. Sabetta, “Impact assessment for vulnera- bilities in open-source software libraries,” inProc. IEEE International Conference on Software Maintenance and Evolution (ICSME), 2015, pp. 411–420

work page 2015

[5] [5]

Structure and evolution of package dependency networks,

R. Kikas, G. Gousios, M. Dumas, and D. Pfahl, “Structure and evolution of package dependency networks,” inProc. IEEE/ACM International Conference on Mining Software Repositories (MSR), 2017, pp. 102–112

work page 2017

[6] [6]

Continuous integration, delivery and deployment: A systematic review on approaches, tools, challenges and practices,

M. Shahin, M. A. Babar, and L. Zhu, “Continuous integration, delivery and deployment: A systematic review on approaches, tools, challenges and practices,”IEEE Access, vol. 5, pp. 3909–3943, 2017

work page 2017

[7] [7]

Small world with high risks: A study of security threats in the npm ecosystem,

M. Zimmermann, C. A. Staicu, C. Tenny, and M. Pradel, “Small world with high risks: A study of security threats in the npm ecosystem,” in Proc. USENIX Security Symposium, 2019, pp. 995–1010

work page 2019

[8] [8]

Managing architectural technical debt: A unified model and systematic literature review,

T. Besker, A. Martini, and J. Bosch, “Managing architectural technical debt: A unified model and systematic literature review,”Journal of Systems and Software, vol. 135, pp. 1–16, 2018

work page 2018

[9] [9]

VulDeePecker: A deep learning-based system for vulnerability detec- tion,

Z. Li, D. Zou, S. Xu, X. Ou, H. Jin, S. Wang, Z. Deng, and Y . Zhong, “VulDeePecker: A deep learning-based system for vulnerability detec- tion,” inProc. Network and Distributed System Security Symposium (NDSS), 2018, pp. 1–15

work page 2018

[10] [10]

An empirical analysis of vulnerabilities in Python packages for web applications,

J. Ruohonen, S. Hyrynsalmi, and V . Lepp¨anen, “An empirical analysis of vulnerabilities in Python packages for web applications,” inProc. Inter- national Workshop on Emerging Trends in Software Metrics (WETSoM), 2018, pp. 25–31

work page 2018

[11] [11]

Empirical analysis of security vulnerabilities in Python packages,

M. Alfadel, D. E. Costa, and E. Shihab, “Empirical analysis of security vulnerabilities in Python packages,”Empirical Software Engineering, vol. 26, no. 3, pp. 1–31, 2021

work page 2021

[12] [12]

GenProg: A generic method for automatic software repair,

C. Le Goues, T. Nguyen, S. Forrest, and W. Weimer, “GenProg: A generic method for automatic software repair,”IEEE Transactions on Software Engineering, vol. 38, no. 1, pp. 54–72, 2012

work page 2012

[13] [13]

SemFix: Program repair via semantic analysis,

H. D. T. Nguyen, D. Qi, A. Roychoudhury, and S. Chandra, “SemFix: Program repair via semantic analysis,” inProc. International Conference on Software Engineering (ICSE), 2013, pp. 772–781

work page 2013

[14] [14]

SequenceR: Sequence-to-sequence learning for end- to-end program repair,

Z. Chen, S. J. Kommrusch, M. Tufano, L. Pouchet, D. Poshyvanyk, and M. Monperrus, “SequenceR: Sequence-to-sequence learning for end- to-end program repair,”IEEE Transactions on Software Engineering, vol. 47, no. 9, pp. 1943–1959, 2021

work page 1943

[15] [15]

Conversational automated program repair,

C. S. Xia and L. Zhang, “Conversational automated program repair,” inProc. IEEE/ACM International Conference on Automated Software Engineering (ASE), 2023, pp. 1–13

work page 2023

[16] [16]

Deep code search,

X. Gu, H. Zhang, and S. Kim, “Deep code search,” inProc. International Conference on Software Engineering (ICSE), 2018, pp. 933–944

work page 2018

[17] [17]

Holistic combination of structural and textual code information for context based API recommendation,

C. Chen, X. Peng, Z. Xing, J. Sun, X. Wang, Y . Zhao, and W. Zhao, “Holistic combination of structural and textual code information for context based API recommendation,”IEEE Transactions on Software Engineering, vol. 48, no. 8, pp. 2987–3003, 2022

work page 2022

[18] [18]

D2A: A dataset built for AI-based vulnerability detection methods using differential analysis,

Y . Zheng, S. Pujar, B. Lewis, L. Buratti, E. Epstein, B. Yang, J. Laredo, A. Morari, and Z. Su, “D2A: A dataset built for AI-based vulnerability detection methods using differential analysis,” inProc. International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), 2021, pp. 111–120

work page 2021

[19] [19]

A survey of DevOps concepts and challenges,

L. Leite, C. Rocha, F. Kon, D. Milojicic, and P. Meirelles, “A survey of DevOps concepts and challenges,”ACM Computing Surveys, vol. 52, no. 6, pp. 1–35, 2019

work page 2019

[20] [20]

AIOps: Real-world challenges and research innovations,

Y . Dang, Q. Lin, and P. Huang, “AIOps: Real-world challenges and research innovations,” inProc. International Conference on Software Engineering: Companion (ICSE-Companion), 2019, pp. 4–5

work page 2019

[21] [21]

Surviving software dependencies,

R. Cox, “Surviving software dependencies,”Communications of the ACM, vol. 62, no. 9, pp. 36–43, 2019

work page 2019

[22] [22]

When and how to make breaking changes: Policies and practices in 18 open source software ecosystems,

C. Bogart, C. K ¨astner, J. Herbsleb, and F. Thung, “When and how to make breaking changes: Policies and practices in 18 open source software ecosystems,”ACM Transactions on Software Engineering and Methodology, vol. 30, no. 4, pp. 1–56, 2021

work page 2021

[23] [23]

Can automated pull requests encourage software developers to upgrade out-of-date dependencies?,

S. Mirhosseini and C. Parnin, “Can automated pull requests encourage software developers to upgrade out-of-date dependencies?,” inProc. IEEE/ACM International Conference on Automated Software Engineer- ing (ASE), 2017, pp. 84–94

work page 2017

[24] [24]

Do developers update their library dependencies?,

R. G. Kula, D. M. German, A. Ouni, T. Ishio, and K. Inoue, “Do developers update their library dependencies?,”Empirical Software Engineering, vol. 23, no. 1, pp. 384–417, 2018

work page 2018

[25] [25]

What are weak links in the npm supply chain?,

N. Zahan, T. Zimmermann, P. Godefroid, B. Murphy, C. Maddila, and L. Williams, “What are weak links in the npm supply chain?,” inProc. International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), 2022, pp. 331–340

work page 2022