pith. sign in

arxiv: 2603.02512 · v4 · pith:YAZMDOR7new · submitted 2026-03-03 · 💻 cs.ET · cs.AI· cs.SE

Human-Certified Module Repositories for the AI Age

Szil\'ard Enyedi This is my paper

Pith reviewed 2026-05-21 12:45 UTC · model grok-4.3

classification 💻 cs.ET cs.AIcs.SE
keywords module repositoriesAI-assisted developmentsoftware supply chaincertificationprovenanceinterface contractstrustworthy software
0
0 comments X

The pith

Human-certified module repositories can secure AI-assembled software by requiring curated components with explicit contracts and tracked origins.

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

The paper introduces Human-Certified Module Repositories as a new model for building reliable software when AI systems generate and combine code. Today's risks stem from modules whose origins are unclear, whose security has not been reviewed, and whose behavior in combination cannot be predicted. HCMRs would apply human oversight together with automated checks to certify modules, record their provenance, and define their interfaces. This approach aims to let both human developers and AI agents assemble systems that remain safe and auditable even as automation increases. The authors outline a reference architecture, a certification workflow, relevant threat models, and lessons drawn from recent supply-chain failures.

Core claim

HCMRs are proposed as an architectural framework that blends human oversight with automated analysis to certify reusable modules, ensuring they are curated, security-reviewed, provenance-rich, and equipped with explicit interface contracts so that both humans and AI agents can assemble trustworthy software systems.

What carries the argument

Human-Certified Module Repositories (HCMRs), a certification and provenance workflow that combines human review with automated analysis to produce modules with documented origins and defined interfaces.

If this is right

  • AI-generated code can be composed from pre-certified building blocks with known behavior and provenance.
  • Software supply-chain attacks become harder because every module carries explicit review records and interface guarantees.
  • Governance of AI-constructed systems gains an auditable substrate through standardized certification and provenance trails.
  • Development workflows can shift from ad-hoc module selection to predictable assembly supported by both humans and automated agents.

Where Pith is reading between the lines

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

  • Existing package managers could add certification gates that reject uncertified modules during AI-driven dependency resolution.
  • Interface contracts might need to include behavioral specifications that AI code generators can verify before assembly.
  • A pilot implementation could track whether certification overhead slows initial module availability but reduces downstream remediation costs.

Load-bearing premise

Human oversight combined with automated analysis can scale to certify modules at the volume and speed demanded by widespread AI-assisted development while remaining effective against evolving threats.

What would settle it

Measure the rate of security incidents or unpredictable failures when AI agents assemble applications using modules from an HCMR versus the same task using modules from a conventional repository over a fixed period and codebase size.

Figures

Figures reproduced from arXiv: 2603.02512 by Szil\'ard Enyedi.

Figure 1
Figure 1. Figure 1: SLSA-inspired provenance generation and attestation pipeline. [PITH_FULL_IMAGE:figures/full_fig_p005_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: HCMR certification pipeline, showing the four stages of intake, [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Identity-based signing and transparency logging workflow inspired [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
read the original abstract

Human-Certified Module Repositories (HCMRs) are introduced in this work as a new architectural model for constructing trustworthy software in the era of AI-assisted development. As large language models increasingly participate in code generation, configuration synthesis, and multi-component integration, the reliability of AI-assembled systems will depend critically on the trustworthiness of the building blocks they use. Today's software supply-chain incidents and modular development ecosystems highlight the risks of relying on components with unclear provenance, insufficient review, or unpredictable composition behavior. We argue that future AI-driven development workflows require repositories of reusable modules that are curated, security-reviewed, provenance-rich, and equipped with explicit interface contracts. To this end, we propose HCMRs, a framework that blends human oversight with automated analysis to certify modules and support safe, predictable assembly by both humans and AI agents. We present a reference architecture for HCMRs, outline a certification and provenance workflow, analyze threat surfaces relevant to modular ecosystems, and extract lessons from recent failures. We further discuss implications for governance, scalability, and AI accountability, positioning HCMRs as a foundational substrate for reliable and auditable AI-constructed software systems.

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

3 major / 2 minor

Summary. The paper introduces Human-Certified Module Repositories (HCMRs) as a new architectural model for trustworthy software in AI-assisted development. It argues that AI-driven workflows require curated, security-reviewed, provenance-rich repositories with explicit interface contracts, and proposes a framework blending human oversight with automated analysis to certify modules for safe assembly by humans and AI agents. The manuscript presents a reference architecture, outlines a certification and provenance workflow, analyzes threat surfaces, extracts lessons from recent failures, and discusses governance, scalability, and AI accountability implications.

Significance. If the HCMR framework can be realized with concrete mechanisms that scale effectively, it would address critical software supply-chain risks amplified by AI code generation, providing a foundational substrate for auditable and predictable AI-constructed systems. The conceptual proposal draws on real-world incidents and positions HCMRs as a governance-oriented solution, but its impact remains prospective given the absence of empirical validation or formal specification.

major comments (3)
  1. [Certification and Provenance Workflow] The central claim that HCMRs can blend human oversight with automated analysis to certify modules at the volume and speed required by AI-assisted development rests on an unelaborated assumption about scalability and effectiveness against evolving threats. No specific integration mechanism, workload model, or pilot evaluation is provided to substantiate this blend.
  2. [Reference Architecture] The reference architecture is described at a high level without defining component interfaces, data flows, or verification properties that would support the claim of 'safe, predictable assembly' by AI agents. This makes it difficult to assess whether the architecture actually mitigates the identified provenance and composition risks.
  3. [Threat Surfaces and Lessons from Recent Failures] The analysis of threat surfaces and lessons from recent failures is presented conceptually but does not include a mapping from those threats to concrete certification requirements or countermeasures within the HCMR workflow, leaving the framework's risk-reduction argument ungrounded.
minor comments (2)
  1. The manuscript would benefit from clearer section numbering and explicit cross-references between the architecture description and the workflow outline to improve readability.
  2. [Implications for Governance, Scalability, and AI Accountability] Consider adding a dedicated section or subsection on potential implementation challenges or metrics for evaluating HCMR effectiveness, as the current discussion of scalability remains qualitative.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for their constructive comments on our manuscript proposing Human-Certified Module Repositories. We address each of the major comments below, clarifying the scope of our conceptual contribution and indicating revisions where appropriate.

read point-by-point responses

  1. Referee: [Certification and Provenance Workflow] The central claim that HCMRs can blend human oversight with automated analysis to certify modules at the volume and speed required by AI-assisted development rests on an unelaborated assumption about scalability and effectiveness against evolving threats. No specific integration mechanism, workload model, or pilot evaluation is provided to substantiate this blend.

    Authors: We agree that the manuscript does not provide a detailed workload model or pilot evaluation, as it is positioned as a high-level architectural proposal rather than an empirical study. The blend is substantiated through reference to existing practices in software engineering, such as hybrid review processes in open-source projects. To strengthen the response, we will revise the certification workflow section to include a high-level workload model based on estimated module submission rates and a discussion of integration with automated tools like static analysis and AI-assisted review. We will also note that full pilot evaluations are planned as future work. revision: partial

  2. Referee: [Reference Architecture] The reference architecture is described at a high level without defining component interfaces, data flows, or verification properties that would support the claim of 'safe, predictable assembly' by AI agents. This makes it difficult to assess whether the architecture actually mitigates the identified provenance and composition risks.

    Authors: The reference architecture is intentionally presented at a conceptual level to outline the key components and their roles in supporting trustworthy module assembly. While specific interface definitions and formal verification properties are not included in this initial proposal, we will expand the architecture description in the revision to include example data flows and high-level verification properties, such as provenance tracking via cryptographic signatures and interface contract enforcement. This will help ground the claims about safe assembly without requiring a full formal specification, which we believe is beyond the scope of this paper. revision: yes

  3. Referee: [Threat Surfaces and Lessons from Recent Failures] The analysis of threat surfaces and lessons from recent failures is presented conceptually but does not include a mapping from those threats to concrete certification requirements or countermeasures within the HCMR workflow, leaving the framework's risk-reduction argument ungrounded.

    Authors: We acknowledge that the mapping from threats to specific countermeasures is presented at a conceptual level. In the revision, we will add a table or subsection that explicitly maps each identified threat surface (e.g., supply-chain attacks, interface mismatches) to corresponding certification requirements and HCMR workflow steps, such as automated scanning for known vulnerabilities and human review for behavioral contracts. This will make the risk-reduction argument more concrete while maintaining the paper's focus on the overall framework. revision: yes

Circularity Check

0 steps flagged

No significant circularity in conceptual proposal

full rationale

The manuscript is a high-level conceptual proposal introducing HCMRs as an architectural framework for trustworthy software in AI-assisted development. It describes a reference architecture, certification workflow, threat analysis, and governance implications without presenting any equations, derivations, fitted parameters, formal proofs, or closed logical systems. No load-bearing steps exist that could reduce by construction to self-definitions, fitted inputs called predictions, or self-citation chains. The central claims rest on argumentative positioning rather than internal reductions, rendering the work self-contained against external benchmarks with no circularity present.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

The work is a high-level proposal that introduces HCMRs as a new construct and rests on assumptions about the trajectory of AI-assisted software development; no free parameters or formal axioms are defined.

axioms (1)
  • domain assumption AI-assisted development will increasingly rely on modular components whose provenance and behavior are currently unclear.
    This premise is stated in the abstract as the motivation for introducing HCMRs.
invented entities (1)
  • Human-Certified Module Repositories (HCMRs) no independent evidence
    purpose: To serve as curated, security-reviewed repositories of reusable modules with provenance and interface contracts for AI and human assembly.
    HCMRs are introduced by the paper as a new architectural model without independent evidence of prior existence or external validation.

pith-pipeline@v0.9.0 · 5726 in / 1284 out tokens · 53562 ms · 2026-05-21T12:45:18.950432+00:00 · methodology

discussion (0)

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

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

What do these tags mean?
matches
The paper's claim is directly supported by a theorem in the formal canon.
supports
The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends
The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses
The paper appears to rely on the theorem as machinery.
contradicts
The paper's claim conflicts with a theorem or certificate in the canon.
unclear
Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.

Reference graph

Works this paper leans on

48 extracted references · 48 canonical work pages · 2 internal anchors

  1. [1]

    Lessons of the SolarWinds Hack,

    M. Willett, “Lessons of the SolarWinds Hack,”Survival, vol. 63, no. 2, pp. 7–26, Mar. 2021. [Online]. Available: https://www.tandfonline.com/ doi/full/10.1080/00396338.2021.1906001

    work page doi:10.1080/00396338.2021.1906001 2021

  2. [2]

    Software Supply Chain Attacks, a Threat to Global Cybersecurity: SolarWinds’ Case Study,

    J. Mart ´ınez and J. M. Dur ´an, “Software Supply Chain Attacks, a Threat to Global Cybersecurity: SolarWinds’ Case Study,”International Journal of Safety and Security Engineering, vol. 11, no. 5, pp. 537–545, Oct. 2021. [Online]. Available: https://www.iieta.org/journals/ijsse/paper/ 10.18280/ijsse.110505

    work page doi:10.18280/ijsse.110505 2021

  3. [3]

    A Longitudinal Measurement Study of Log4Shell Exploitation from a Reactive Network Telescope

    A. Singh, K. S. Yadav, V . A. Kumar, S. Ghosh, P. Baro, and B. B. Prasanth, “A Longitudinal Measurement Study of Log4Shell Exploitation from an Active Network Telescope,”arXiv, 2026, version Number: 1. [Online]. Available: https://arxiv.org/abs/2601.04281

    work page internal anchor Pith review Pith/arXiv arXiv 2026

  4. [4]

    The Log4j Incident: A Comprehensive Measurement Study of a Critical Vulnerability,

    R. Hiesgen, M. Nawrocki, T. C. Schmidt, and M. W ¨ahlisch, “The Log4j Incident: A Comprehensive Measurement Study of a Critical Vulnerability,”IEEE Transactions on Network and Service Management, vol. 21, no. 6, pp. 5921–5934, Dec. 2024. [Online]. Available: https://ieeexplore.ieee.org/document/10628102/

    work page arXiv 2024

  5. [5]

    An empirical characterization of IFTTT: ecosystem, usage, and performance,

    X. Mi, F. Qian, Y . Zhang, and X. Wang, “An empirical characterization of IFTTT: ecosystem, usage, and performance,” inProceedings of the 2017 Internet Measurement Conference. London United Kingdom: ACM, Nov. 2017, pp. 398–404. [Online]. Available: https://dl.acm.org/doi/10.1145/3131365.3131369

    work page doi:10.1145/3131365.3131369 2017

  6. [6]

    Azure Verified Modules,

    C. Galanopoulos, “Azure Verified Modules,” Mar. 2025. [Online]. Available: https://learn.microsoft.com/en-us/community/content/ azure-verified-modules

    work page 2025

  7. [7]

    Azure Verified Modules,

    A. V . M. Team, “Azure Verified Modules,” Feb. 2026. [Online]. Available: https://azure.github.io/Azure-Verified-Modules/

    work page 2026

  8. [8]

    Azure verified modules (A VM) — governance and index repository,

    Azure, “Azure verified modules (A VM) — governance and index repository,” 2025, accessed 2026-03-02. [Online]. Available: https: //github.com/Azure/Azure-Verified-Modules

    work page 2025

  9. [9]

    Solution development guidance for A VM,

    Azure Verified Modules Team, “Solution development guidance for A VM,” 2025, accessed 2026-03-02. [Online]. Available: https: //azure.github.io/Azure-Verified-Modules/usage/sol-dev/

    work page 2025

  10. [10]

    Azure Verified Modules - Monthly Update Jan 24’,

    C. Sidebotham, “Azure Verified Modules - Monthly Update Jan 24’,” Feb. 2024. [Online]. Available: https://techcommunity.microsoft.com/blog/azuretoolsblog/ azure-verified-modules---monthly-update-jan-24/4048910

    work page 2024

  11. [11]

    Illegal: The SolarWinds Hack under International Law,

    A. Coco, T. Dias, and T. Van Benthem, “Illegal: The SolarWinds Hack under International Law,”European Journal of International Law, vol. 33, no. 4, pp. 1275–1286, Dec. 2022. [Online]. Available: https://academic.oup.com/ejil/article/33/4/1275/6881099

    work page 2022

  12. [12]

    From SolarWinds to Kaseya: The rise of supply chain attacks in a digital world,

    H. Ghanbari, K. Koskinen, and Y . Wei, “From SolarWinds to Kaseya: The rise of supply chain attacks in a digital world,”Journal of Information Technology Teaching Cases, pp. 1–8, Nov. 2024. [Online]. Available: https://journals.sagepub.com/doi/10.1177/20438869241299823

    work page doi:10.1177/20438869241299823 2024

  13. [13]

    On the critical path to implant backdoors and the effectiveness of potential mitigation techniques: Early learnings from XZ,

    M. Lins, R. Mayrhofer, M. Roland, D. Hofer, and M. Schwaighofer, “On the critical path to implant backdoors and the effectiveness of potential mitigation techniques: Early learnings from XZ,” arXiv, Apr. 2024, arXiv:2404.08987 [cs]. [Online]. Available: http://arxiv.org/abs/2404.08987

    work page arXiv 2024

  14. [14]

    Unveiling the Critical Attack Path for Implanting Backdoors in Supply Chains: Practical Experience from XZ,

    M. Lins, R. Mayrhofer, and M. Roland, “Unveiling the Critical Attack Path for Implanting Backdoors in Supply Chains: Practical Experience from XZ,” inCryptology and Network Security, Y . Kim, A. Miyaji, and M. Tibouchi, Eds. Singapore: Springer Nature Singapore, 2026, vol. 16351, pp. 521–541, series Title: Lecture Notes in Computer Science. [Online]. Avai...

    work page 2026

  15. [15]

    Comprehensive formal verification of an OS microkernel,

    G. Klein, J. Andronick, K. Elphinstone, T. Murray, T. Sewell, R. Kolanski, and G. Heiser, “Comprehensive formal verification of an OS microkernel,” ACM Transactions on Computer Systems, vol. 32, no. 1, pp. 1–70, Feb

    work page

  16. [16]

    Available: https://dl.acm.org/doi/10.1145/2560537

    [Online]. Available: https://dl.acm.org/doi/10.1145/2560537

    work page doi:10.1145/2560537

  17. [17]

    seL4: formal verification of an OS kernel,

    G. Klein, K. Elphinstone, G. Heiser, J. Andronick, D. Cock, P. Derrin, D. Elkaduwe, K. Engelhardt, R. Kolanski, M. Norrish, T. Sewell, H. Tuch, and S. Winwood, “seL4: formal verification of an OS kernel,” in Proceedings of the ACM SIGOPS 22nd symposium on Operating systems principles. Big Sky Montana USA: ACM, Oct. 2009, pp. 207–220. [Online]. Available: ...

    work page doi:10.1145/1629575.1629596 2009

  18. [18]

    Communications of the ACM 52(7), pp

    X. Leroy, “Formal verification of a realistic compiler,”Communications of the ACM, vol. 52, no. 7, pp. 107–115, Jul. 2009. [Online]. Available: https://dl.acm.org/doi/10.1145/1538788.1538814

    work page doi:10.1145/1538788.1538814 2009

  19. [19]

    SLSA provenance specification (v0.1),

    SLSA Project, “SLSA provenance specification (v0.1),” 2026, accessed 2026-03-02. [Online]. Available: https://slsa.dev/spec/v0.1/provenance

    work page 2026

  20. [20]

    SLSA provenance predicate (v0.2),

    ——, “SLSA provenance predicate (v0.2),” 2026, accessed 2026-03-02. [Online]. Available: https://devmoran.github.io/slsa/provenance/v0.2

    work page 2026

  21. [21]

    SLSA Framework: The Definitive Guide for Securing Your Software Supply Chain,

    V . Kumar, “SLSA Framework: The Definitive Guide for Securing Your Software Supply Chain,” Feb

    work page

  22. [22]

    Available: https://www.practical-devsecops.com/ slsa-framework-guide-software-supply-chain-security/

    [Online]. Available: https://www.practical-devsecops.com/ slsa-framework-guide-software-supply-chain-security/

    work page

  23. [23]

    Language-agnostic GitHub actions SLSA provenance generator,

    SLSA Framework, “Language-agnostic GitHub actions SLSA provenance generator,” 2023, accessed 2026-03-02. [Online]. Available: https: //github.com/slsa-framework/slsa-github-generator

    work page 2023

  24. [24]

    Sigstore: Software Signing for Everybody,

    Z. Newman, J. S. Meyers, and S. Torres-Arias, “Sigstore: Software Signing for Everybody,” inProceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security. Los Angeles CA USA: ACM, Nov. 2022, pp. 2353–2367. [Online]. Available: https://dl.acm.org/doi/10.1145/3548606.3560596

    work page doi:10.1145/3548606.3560596 2022

  25. [25]

    Sigstore overview: Identity-based signing, Fulcio, and Rekor transparency,

    Sigstore Project, “Sigstore overview: Identity-based signing, Fulcio, and Rekor transparency,” 2026, accessed 2026-03-02. [Online]. Available: https://docs.sigstore.dev/about/overview/

    work page 2026

  26. [26]

    Why Johnny Adopts Identity-Based Software Signing: A Usability Case Study of Sigstore

    K. G. Kalu, S. Okorafor, T. Singla, S. Chen, S. Torres-Arias, and J. C. Davis, “Why Johnny Signs with Next-Generation Tools: A Usability Case Study of Sigstore,”arXiv, 2025, version Number: 5. [Online]. Available: https://arxiv.org/abs/2503.00271

    work page internal anchor Pith review Pith/arXiv arXiv 2025

  27. [27]

    IFTTT measurement dataset and source code (IMC’17),

    X. Mi, “IFTTT measurement dataset and source code (IMC’17),” 2017, accessed 2026-03-02. [Online]. Available: https://github.com/ mixianghang/IFTTT measurement

    work page 2017

  28. [28]

    IoT Based HOME AUTOMATION Using Node-RED,

    R. K. Kodali and A. Anjum, “IoT Based HOME AUTOMATION Using Node-RED,” in2018 Second International Conference on Green Computing and Internet of Things (ICGCIoT). Bangalore, India: IEEE, Aug. 2018, pp. 386–390. [Online]. Available: https: //ieeexplore.ieee.org/document/8753085/

    work page arXiv 2018

  29. [29]

    The CVE Wayback Machine: Measuring Coordinated Disclosure from Exploits against Two Years of Zero-Days,

    E. Pauley, P. Barford, and P. McDaniel, “The CVE Wayback Machine: Measuring Coordinated Disclosure from Exploits against Two Years of Zero-Days,” inProceedings of the 2023 ACM on Internet Measurement Conference. Montreal QC Canada: ACM, Oct. 2023, pp. 236–252. [Online]. Available: https://dl.acm.org/doi/10.1145/3618257.3624810

    work page doi:10.1145/3618257.3624810 2023

  30. [30]

    CoreTrustSeal – trusted digital repository,

    ICPSR, “CoreTrustSeal – trusted digital repository,” https://www.icpsr. umich.edu/sites/icpsr/about/policies/coretrustseal, 2024, accessed 2026- 03-02

    work page 2024

  31. [31]

    ISO 16363:2025 – audit and certification of trustworthy digital repositories,

    International Organization for Standardization, “ISO 16363:2025 – audit and certification of trustworthy digital repositories,” https://www.iso.org/ standard/87472.html, 2025, accessed 2026-03-02

    work page 2025

  32. [32]

    Towards an approach for developing and testing Node-RED IoT systems,

    D. Clerissi, M. Leotta, G. Reggio, and F. Ricca, “Towards an approach for developing and testing Node-RED IoT systems,” inProceedings of the 1st ACM SIGSOFT International Workshop on Ensemble-Based Software Engineering. Lake Buena Vista FL USA: ACM, Nov. 2018, pp. 1–8. [Online]. Available: https://dl.acm.org/doi/10.1145/3281022.3281023

    work page doi:10.1145/3281022.3281023 2018

  33. [33]

    Node-RED and IoT Analytics: A Real-Time Data Processing and Visualization Platform,

    I. U. Onwuegbuzie, “Node-RED and IoT Analytics: A Real-Time Data Processing and Visualization Platform,” Sep. 2024. [Online]. Available: https://zenodo.org/doi/10.5281/zenodo.13856860

    work page doi:10.5281/zenodo.13856860 2024

  34. [34]

    Kaspersky analysis of the backdoor in XZ,

    Kaspersky GReAT, “Kaspersky analysis of the backdoor in XZ,” Apr. 2024. [Online]. Available: https://securelist.com/ xz-backdoor-story-part-1/112354/

    work page 2024

  35. [35]

    A foot in the backdoor: Applying systems control theory to the 2024 XZ utils backdoor cyberattack,

    R. Bondi, J. Thomas, G. Holthaus, and R. Barroso, “A foot in the backdoor: Applying systems control theory to the 2024 XZ utils backdoor cyberattack,” 2025, mIT STAMP Conference deck; Accessed 2026-03-

    work page 2024

  36. [36]

    Available: https://psas.scripts.mit.edu/home/wp-content/ uploads/2025/2025-03-25-1110 A Foot in the Backdoor PUB.pdf

    [Online]. Available: https://psas.scripts.mit.edu/home/wp-content/ uploads/2025/2025-03-25-1110 A Foot in the Backdoor PUB.pdf

    work page 2025

  37. [37]

    Why AI is pushing developers toward typed languages,

    C. Williams, “Why AI is pushing developers toward typed languages,” Jan. 2026. [Online]. Available: https://github.blog/ai-and-ml/llms/ why-ai-is-pushing-developers-toward-typed-languages/

    work page 2026

  38. [38]

    Why AI Is Forcing Developers To Abandon Untyped Code,

    M. Giannelis, “Why AI Is Forcing Developers To Abandon Untyped Code,” Jan. 2026, section: Blogs. [Online]. Available: https://www.techbusinessnews.com.au/blog/ why-ai-is-forcing-developers-to-abandon-untyped-code/

    work page 2026

  39. [39]

    The great vibecoding debate: Do typed languages really help AI programming?

    Signals Editorial Team, “The great vibecoding debate: Do typed languages really help AI programming?” Sep. 2025. [Online]. Available: https://signals.aktagon.com/articles/2025/09/ the-great-vibecoding-debate-do-typed-languages-really-help-ai-programming/

    work page 2025

  40. [40]

    Rust: The unlikely engine of the vibe coding era,

    P. Jiang, “Rust: The unlikely engine of the vibe coding era,”Forbes, Mar. 2026. [Online]. Avail- able: https://www.forbes.com/councils/forbestechcouncil/2026/03/03/ rust-the-unlikely-engine-of-the-vibe-coding-era/

    work page 2026

  41. [41]

    Understanding security risks in AI-generated code,

    A. Stiefel, “Understanding security risks in AI-generated code,” Jul

    work page

  42. [42]

    Available: https://cloudsecurityalliance.org/blog/2025/07/ 09/understanding-security-risks-in-ai-generated-code

    [Online]. Available: https://cloudsecurityalliance.org/blog/2025/07/ 09/understanding-security-risks-in-ai-generated-code

    work page 2025

  43. [43]

    Cybersecurity risks of AI-generated code,

    J. Ji, J. Jun, M. Wu, and R. Gelles, “Cybersecurity risks of AI-generated code,” 2024. [Online]. Available: https://cset.georgetown.edu/publication/ cybersecurity-risks-of-ai-generated-code/

    work page 2024

  44. [44]

    Security degradation in iterative AI code generation: A systematic analysis of the paradox,

    S. Shukla, H. Joshi, and R. Syed, “Security degradation in iterative AI code generation: A systematic analysis of the paradox,”arXiv, May

    work page

  45. [45]

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

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

    work page arXiv

  46. [46]

    Endor Labs launches free tool AURI after study finds only 10% of AI-generated code is secure,

    M. Nu ˜nez, “Endor Labs launches free tool AURI after study finds only 10% of AI-generated code is secure,” Mar. 2026. [Online]. Available: https://venturebeat.com/technology/ endor-labs-launches-free-tool-auri-after-study-finds-only-10-of-ai-generated

    work page 2026

  47. [47]

    Introducing AURI: Security intelligence for AI coding agents and developers,

    Endor Labs, “Introducing AURI: Security intelligence for AI coding agents and developers,” 2026, company blog, March 3, 2026; Accessed 2026-03-03. [Online]. Available: https://www.endorlabs.com/learn/ introducing-auri-security-intelligence-for-ai-coding-agents-and-developers

    work page 2026

  48. [48]

    Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks,

    S. Zhao, D. Wang, K. Zhang, J. Luo, Z. Li, and L. Li, “Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks,”arXiv, Feb. 2026, arXiv:2512.03262 [cs]. [Online]. Available: http://arxiv.org/abs/2512.03262

    work page arXiv 2026