AI coding agents should optimize for less owned code

As AI makes code cheaper to produce, costs shift from generation to ownership. To avoid technical debt, coding agents need an open-source intelligence layer that helps them reuse trusted components before generating new code.

The dominant storyline around LLMs in software development is that cheaper code generation will disrupt the fundamentals of software engineering. More capable models are expected to generate more code, automate more workflows and build more applications.

But software development has never been primarily about producing more code. Most of the software industry today is about building ecosystems of modules and components that a global community of developers can combine, adapt and maintain.

The generation-first story is appealing because it matches how LLM providers are currently measured: larger models, larger context windows, more agentic workflows, more generated artifacts and more tokens processed in more data centers. From a software engineering perspective, however, this may be the wrong optimization target. Making code generation available everywhere can easily create " technical debt ": the accumulated cost of shortcuts, incomplete design decisions and deferred maintenance .

Modern systems are rarely built by generating greenfield code from scratch. They are assembled from operating systems, databases, cloud services, frameworks, APIs, libraries, containers and open-source infrastructure. Most engineering effort is no longer spent inventing algorithms, but selecting, integrating, configuring, securing, upgrading and maintaining components that already exist.

Black Duck’s annual Open Source Security and Risk Analysis reports show how deeply modern software depends on existing open-source modules. The 2026 report found that 97% of audited commercial codebases contained open source, that 70% of scanned code had its origin in open source, and that the average application contained 911 open-source components.

OpenAI described Codex as trained on natural language and “ billions of lines of source code ” from publicly available sources, including public Git repositories. If future coding models are to improve, they should not merely consume more code from this commons. They need an ecosystem layer oriented toward reuse: one that helps identify, preserve and separate high-quality, well-maintained source code from masses of duplicated or unverified AI-generated code.

The LLMs we know today would be unthinkable without two decades of rapid open-source innovation in machine learning software. That raises a simple but uncomfortable question:

If software development is increasingly about composition, why are AI systems still primarily optimized for generation?

Part of the answer lies in economics. Current AI systems are measured and monetized through tokens, and the most visible output of an AI coding assistant is generated code. Every generated artifact, code review, debugging session and agentic workflow increases the amount of context that must be processed.

This creates a gap between what benefits software and what benefits token consumption. The result is more software to maintain, more tokens to process, more infrastructure to power and a larger environmental burden, while the immediate revenue model rewards continued activity.

This trend will have a significant impact on the long-term quality of code, as highlighted in GitClear's latest report : "The data shows a 74% drop in long-term legacy updates and a 70% collapse in refactoring moves since 2023. Adding code has become a single keystroke, while understanding and consolidating existing systems takes too much effort. The result is a generation of repos stuck in "write-only mode" - growing outward in new v1 features while their older strata calcify untouched." Write-Only Mode: AI Code Quality in 2026

Experienced engineers have long internalized a different instinct. When asked to build a new feature, they first ask whether the problem can be solved by reusing an existing capability, adopting a mature dependency, extending a current service or eliminating the need altogether.

Many AI systems are optimized to answer: “How do I generate a solution?” The more fundamental question is: “Does this problem already have a solution?”

Before creating a new abstraction, one should understand the abstractions that already exist. Before generating a framework, one should ask whether a framework has already accumulated years of operational experience. The goal is to minimize unnecessary ownership and avoid creating new technical debt.

Open source has a powerful economic property that generated code lacks: successful solutions become shared assets. Once a problem is solved in the commons, the solution can be reused indefinitely. Each additional user can strengthen the ecosystem rather than fragment it. This mindset has an old lineage in the Unix philosophy .

Foreword to the Bell System Technical Journal

Generating completely new code is particularly critical when it comes to security risks. Frontier models supercharge vulnerability discovery, dependency analysis, code review and large-scale scanning. However, they are only available to a very small group of wealthy individuals who can afford the significant costs associated with modern LLM-based vulnerability scans. Securing the significant amount of new code generated would demand resources that are out of reach for most organisation.

Therefore, AI will help us create fewer modules from fewer, better-tested building blocks, and share the cost of security scans collaboratively. Software prototyping will become easier. However, producing secure, online-reachable and distributed software will still require highly skilled people and access to frontier LLM models.

Therefore, the future does not belong to pure code generation or pure automation. Rather, it belongs to ecosystem intelligence: knowing when to create new code, when to reuse existing secure code, and when to avoid adding software altogether.

To supercharge AI coding while keeping software easier for a broad community to review, AI systems need a structured understanding of the open-source ecosystem. They need information about code quality, human review, interfaces, available datasets, performance, licensing, security, maintenance activity, community health and more.

This requires something broader than a conventional package manager. It requires an ecosystem intelligence layer for coding agents and humans.

Such a layer would benefit both LLMs and humans-in-the-loop by helping them:

Platforms like ecosyste.ms will be key to provide trustworthy insights into how AI can combine software building blocks across open-source and domain-wide platforms. This trend is evident in the increasing number of OpenAI and Anthropic training bots accessing Ecosystems' APIs, with an average of around two million training requests per day.

Bots used for training LLMs account for about two million of the total 30 million ecosyste.ms API requests per day.

When code becomes cheap to produce, ownership becomes the real cost centre. Therefore, the next frontier in AI coding is not an agent that writes the most code. Rather, it is an agent that can justify the necessity of new code. By analysing the health of its own training corpus, we can develop a better understanding of how to sustain a healthy ecosystem. Such an ecosystem intelligence layer can help by:

Read more about our first attempt at an open-source-aware LLM context file .