Part II: The Case for Disposable Code

Introduction

In Part I, I argued that open source solved exactly the problem we had. Software was expensive to build, so sharing implementations made sense. If thousands of teams needed the same HTTP client, JSON parser or logging framework, building and maintaining one shared implementation was far more efficient than having every team create its own.

Agentic AI may change that calculation. Code is becoming cheaper to generate, understand, test and replace. At the same time, software supply-chain risk is making inherited code more expensive to carry. Every dependency brings an implementation, a release cycle, a transitive dependency graph and a collection of future CVEs.

That led me to a thought experiment I have started calling Project Theseus: What if we could identify the exact behavior an application consumes from a dependency, generate a smaller replacement and prove that the application still behaves the same way?

Part I was mostly about why that question may be worth asking. Part II is about what we might gain by doing it, what it would actually take and the economic problem that could keep the whole idea from working.

The Dependency Dance

When a vulnerability is discovered in first-party code, the path is at least conceptually straightforward. We find the vulnerable behavior, change the code and run it through our testing and verification process. It may be difficult, but the work is ours to do and the timeline is largely ours to control.

A vulnerability in a third-party dependency is different. First, we wait for the maintainers to investigate the issue, develop a patch and publish a release. Then we determine which release contains the fix, whether we can upgrade directly and what else changed along the way.

Sometimes the fix is available in a minor version. Sometimes it requires a major framework upgrade. Sometimes one dependency forces another to move, which forces another to move, until a flaw in a small piece of code becomes a much larger modernization effort.

Then the dependency dance begins: update the build, resolve compatibility problems, inspect the new transitive dependency graph and regression-test everything that moved. Most of that effort may have very little to do with the vulnerable behavior we were trying to fix.

Upgrading from Spring Boot 2 to Spring Boot 3 may be good and necessary engineering, but it does not eliminate dependency risk. It exchanges one inherited implementation and dependency graph for another. We solve yesterday's CVEs by accepting tomorrow's.

First-Party Code Gives Us Agency

If the same behavior lived in a small first-party implementation, we could address the vulnerability directly. We would still need to understand the flaw, change the code and prove that the application remains correct. But we would control the process. We would not have to wait for a maintainer or absorb a collection of unrelated changes simply to get one security fix.

Agentic AI makes that distinction more important. If models can help us understand the vulnerability, generate a remediation and run the implementation through a repeatable verification process, then fixing narrowly scoped first-party code may become considerably easier than upgrading a large third-party dependency.

This does not mean all third-party code should become first-party code. Owning an implementation also means owning its defects, security and maintenance. Historically, that responsibility was one of the strongest arguments for using a mature shared library.

But if implementations become inexpensive to regenerate while behavioral contracts and verification evidence remain durable, owning the code may no longer carry the same cost it once did. The advantage is not merely that the replacement is smaller. The advantage is that when something goes wrong, we have the authority and the ability to fix it ourselves.

Breaking the Software Monoculture

There may be another security advantage to replacing common dependencies with application-specific implementations. Attackers know a great deal about the software inside our applications because we all use many of the same components.

When a vulnerability is discovered in a popular library, attackers do not have to understand every affected application individually. They can study the shared implementation, develop an exploit and scan the internet for recognizable versions or behaviors. One vulnerability can produce thousands or millions of potential targets.

A CVE becomes more than a warning to defenders. It can also become a roadmap for attackers: here is the vulnerable component, here are the affected versions and, increasingly, here is working exploit code.

Project Theseus could disrupt that model by introducing implementation diversity. If two applications consume the same behavior but use independently generated implementations, they may no longer share the same underlying vulnerability. An exploit developed against one implementation may not work against the other. There is no package name to search for, no shared version fingerprint and no guarantee that the vulnerable code path exists.

This cannot be reduced to security through obscurity. Attackers can still probe an application, discover flaws and develop exploits. Generated code can contain vulnerabilities of its own. If every implementation is produced by the same model using the same patterns, we could even create a new monoculture based on shared model behavior instead of shared source code.

The stronger argument is economic. Implementation diversity could prevent one reliable exploit from scaling across an entire ecosystem. Open source let us share behavior by sharing code, but it also created software monocultures in which one flaw can expose a significant portion of the internet at once. Theseus asks whether applications can continue sharing the behavior without sharing the same vulnerability.

The goal is not to hide the code. It is to stop giving attackers one exploit that works everywhere.

The Uncomfortable Economics of AI

There is an obvious problem with this idea: generating code may be getting cheaper, but it is not free.

A system like Theseus could consume an enormous number of tokens. It would need to analyze application code, dependency trees, tests, runtime traces and external specifications. It may need to revisit the same code repeatedly as it extracts contracts, generates replacements, investigates differences and attempts new implementations.

Verification could consume even more compute than generation. One agent producing a replacement is relatively cheap. Several agents reasoning across a large enterprise application, generating test cases, investigating failures and repeating the process until they have enough evidence to support a production change is something else entirely.

At today's prices, that cost could be prohibitive, especially for an organization trying to apply the process across thousands of applications. We could easily replace one expensive dependency-management problem with an expensive token-consumption problem.

The economics have to be evaluated across the full lifecycle of the dependency. What does it cost to identify and replace the implementation? What does it cost to verify the replacement? How does that compare with years of vulnerability scanning, emergency patching, framework upgrades, regression testing and operational support?

Theseus would also have to be selective about where intelligence is actually required. Dependency discovery, static analysis and test execution should remain deterministic. Smaller or locally hosted models may be sufficient for classification and contract extraction. Expensive frontier models should be reserved for reasoning problems that justify their cost.

Cost is not a minor implementation detail. It may determine whether Project Theseus becomes a practical security model or remains an interesting thought experiment. The bet is not simply that code generation becomes cheap. It is that generating and verifying a narrow implementation eventually becomes cheaper than inheriting, monitoring and repeatedly upgrading a broad one.

This Is Not Another Code-Generation Agent

The obvious version of this idea is also the least interesting one: point an AI coding agent at a dependency and tell it to rewrite the library.

That might produce code, but it does not solve the underlying problem. We would have traded code written by an open-source project for code generated by a model without creating a convincing reason to trust the replacement.

Generation is not the hard part. The hard part is determining exactly what behavior the application depends on and producing enough evidence to show that the replacement preserves it.

How Theseus Might Work

A Theseus workflow would begin by identifying which dependencies create the greatest combination of risk, maintenance cost and unnecessary code. It would then determine which parts of a selected dependency the application actually uses — not merely which package is installed, but which methods are called, which inputs are accepted, which outputs are expected and which errors or side effects the application relies upon.

Those observations would be turned into explicit behavioral contracts: signatures, data shapes, error conditions, side effects, performance constraints and applicable external standards. The system would distinguish specified behavior from behavior observed at runtime and from behavior that has merely been inferred.

From those contracts, an agent could generate a small first-party implementation containing only the behavior the application needs. The preferred result would be local, standard-library-first where practical, narrow enough for a human to understand and designed to be deleted and regenerated rather than lovingly maintained forever.

The replacement would then be tested against the original through existing tests, differential testing, captured runtime traffic, fuzzing and applicable conformance suites. Every result would remain traceable from the original dependency through the observed behavior, generated contract, replacement implementation and verification evidence.

This workflow could be performed by specialized agents — a Scout to discover dependencies, a Cartographer to observe runtime behavior, an Extractor to create contracts, a Forger to generate replacements, a Verifier to test equivalence and a Reporter to preserve the evidence. But the names are less important than the separation of responsibilities.

Theseus decomposes, contracts, rebuilds and proves. Generation is only one step, and probably not the hardest one.

Verification Is the Real Product

Existing tests are only the beginning. They tell us what a team previously thought was important enough to test, which is not necessarily everything the application depends on.

A credible Verifier would run the existing suites against both implementations, replay captured inputs, perform differential testing, fuzz malformed and boundary inputs, run relevant conformance tests and compare exceptions, side effects, state changes, performance and resource consumption.

When the implementations disagree, the system should not automatically assume the original is correct. The difference may reveal an undocumented dependency, an existing defect or accidental behavior we no longer want to preserve. That is a decision for a human engineer.

The goal is not a magical green check mark labeled proven equivalent. It is a defensible body of evidence explaining what was verified, what differed and what remains unknown.

That evidence should form an unbroken chain: dependency, discovery, observation, contract, implementation, verification and decision. An engineer, security reviewer or auditor should be able to start with any generated replacement and work backward to understand why it exists and what supports it.

What Happens When a New CVE Appears?

If a vulnerability is later found in a Theseus-generated implementation, the response could look different from today's dependency upgrade process. The affected behavior and its contract are already known. The implementation is disposable. A security agent can analyze the flaw, regenerate the code under new constraints and pass it through the same verification process.

Instead of upgrading an entire framework or dependency tree, we regenerate one narrow implementation and prove that it still satisfies the contract. This does not make vulnerabilities disappear. Generated implementations will have defects and models will make mistakes. But it may reduce the blast radius of remediation.

Today we often replace a large amount of software to fix a small amount of vulnerable behavior. Theseus asks whether we can replace only the plank that failed.

Start With One Plank

I would not begin with Spring Boot. It makes a useful example when describing the cost of inherited frameworks, but replacing a mature application framework would be a terrible first experiment. The behavioral surface is enormous, much of it is dynamic and applications often rely on subtle framework behavior they do not fully understand.

A credible prototype would start with a dependency used through a narrow API, performing deterministic behavior, supported by strong specifications or test vectors, introducing meaningful transitive baggage and capable of running side by side with a replacement. It should not be security-critical cryptography.

The first goal would not be to prove that AI can rewrite the world. It would be to remove one dependency while producing a stronger body of evidence than we had when we installed it. Then do it again.

The Ship of Theseus was not rebuilt in one afternoon. The planks were replaced one at a time.

The Hardest Problem Is Knowing What We Don't Know

How do we know we have discovered all the behavior that matters? We probably do not.

Production systems encounter inputs no test suite anticipated. They rely on timing, ordering, failure modes and environmental conditions that may not appear during observation. Some behavior becomes visible only under load. Some runs once a year. Some exists specifically to handle the outage everyone hopes never happens.

Theseus has to be designed around uncertainty rather than hiding it. Contracts need confidence levels. Verification needs coverage measures. Replacements need staged deployment, shadow traffic and rapid rollback. Some dependencies should simply be marked unsuitable.

Unverified must be an acceptable result. Otherwise, the system will create false confidence, which would be more dangerous than the dependency problem it is trying to solve.

Replace the Planks. Preserve the Voyage.

Project Theseus is still a thought experiment. I do not know whether this architecture can work at meaningful scale, whether enough behavior can be extracted automatically or whether the economics will work beyond a narrow class of dependencies.

But the question has become technically plausible enough to explore. Open source gave us a way to share implementations when implementation was the expensive part of software. Agentic AI may allow us to extract the behavior we actually depend on, rebuild only what we need and preserve the evidence that tells us the application is still itself.

The package was a delivery mechanism for behavior. Project Theseus makes the behavior explicit.

Then it replaces the package, one plank at a time, while doing everything it can to prove the ship is still headed to the same place.

Next in the series

In Part III, I'll explore whether generated code really improves software supply-chain security — or simply replaces shared, visible risk with millions of unique and poorly understood implementations.