Open Source Solved Yesterday’s Problem

Agentic AI is changing the economics of how we build software.

I don't think open source is broken. I don't think it was a mistake, and I certainly don't think AI is about to make it disappear.

Open source may be the greatest collaborative engineering achievement our profession has ever produced. Entire companies — and, in some cases, entire industries — exist because thousands of people chose to solve common problems together instead of repeatedly solving them alone.

It solved exactly the problem we had.

The question I've been turning over in my head is whether we are beginning to have a different problem.

This isn't a prediction so much as a thought experiment. It came from two things that, at first, didn't seem directly related: the growing security risk in the software supply chain and the rapid improvement of agentic AI.

The more I thought about them together, the more I began to wonder if they might fundamentally change what software we share, what software we inherit, and what part of an application is actually worth preserving.

The Cost of Inheriting Software

If you work on enterprise software, you already know the routine.

A critical CVE is published and the scanners light up. Someone asks whether your application is affected. Someone else begins working backward through the dependency tree to figure out whether the vulnerable package is actually reachable or just happens to be buried six levels deep in the graph.

An emergency patch gets scheduled. Regression testing begins. The patch requires a framework upgrade, which breaks something unrelated, which pulls in another dependency, which creates another finding.

Then everyone does it again the next week.

This is just part of building software now.

Modern applications don't depend on a handful of carefully chosen libraries. They depend on hundreds of packages and, through those packages, potentially thousands of transitive dependencies. We produce SBOMs, run software composition analysis, monitor vulnerability feeds and spend an incredible amount of engineering time trying to understand software that our teams never actually wrote.

That isn't an indictment of open source. It's the cost of consuming implementations built by other people.

For most of my career, that cost was more than justified. Writing software was expensive. If ten thousand development teams needed an HTTP client, it made no sense for ten thousand teams to build one. A shared, well-maintained implementation was obviously the better answer.

But the bargain was never free.

When you add a dependency because you need one utility function — a Base64 encoder, a JSON parser, a date calculation — you don't inherit only the behavior you wanted. You inherit the entire implementation. You inherit its design decisions, release cycle, maintainers, transitive dependencies, licensing obligations and every vulnerability that will eventually be discovered in it.

You also inherit code paths your application may never execute.

Until recently, we accepted that because creating and maintaining an alternative would have cost far more. But that calculation may be changing.

Security Models Changed the Conversation

We are getting dramatically better at finding weaknesses in software.

Frontier security models, including systems like Mythos, can reason across codebases and dependency graphs at a scale that would have been nearly impossible a few years ago. They can help determine whether a vulnerability is actually exploitable, trace dangerous execution paths and, increasingly, suggest or even generate remediations.

That is an enormous advantage for defenders.

It also exposes the full weight of what we have inherited.

The more effectively we inspect our software supply chains, the more unnecessary software we discover inside them. We find vulnerable components included for features we don't use, transitive packages no one intentionally selected and entire frameworks pulled into applications that rely on only a fraction of their capabilities.

AI is making us better at seeing the risk.

At the same time, it is making implementation cheaper.

That intersection is what interests me.

Implementation Is Becoming Less Scarce

For most of my career, implementation was the scarce resource. The code was expensive to write, expensive to understand and expensive to replace. Sharing implementations was not merely convenient; it was one of the only practical ways to build sophisticated software.

Agentic AI is beginning to change those economics.

It is making code cheaper to generate. It is making unfamiliar code cheaper to understand. It is reducing the cost of writing tests, tracing behavior, refactoring systems and replacing code that would previously have been too risky or too tedious to touch.

None of that means software engineers are going away, and it certainly doesn't mean AI-generated code can be blindly trusted. If anything, inexpensive code makes engineering judgment, verification and clear specifications more important.

But implementation is no longer as scarce as it was when our current model of software reuse took shape.

At precisely the same moment, the cost of carrying unnecessary software is becoming more visible. New models can find vulnerabilities faster, but offensive models can also discover and exploit them faster. A vulnerability buried in a forgotten transitive dependency is no longer just something that might eventually appear in a quarterly scan. It may become exploitable almost as quickly as it becomes knowable.

One trend raises the cost of inheriting software.

The other lowers the cost of replacing it.

Put those together and you arrive at a question that would have sounded ridiculous not long ago:

What if it becomes cheaper to generate the small amount of software we actually need than to safely inherit the much larger implementation somebody else created?

Modernization Usually Moves the Problem

For most of my career, modernizing an application has meant replacing one implementation with another.

We upgrade Spring Boot 2 to Spring Boot 3. We move from one logging framework to another. We migrate to a newer HTTP client or adopt the current preferred JSON library.

These projects have real value. I have worked on plenty of them. They give us security fixes, supported platforms, better performance and access to newer capabilities.

But they don't eliminate dependency risk. They move it around.

Upgrading from Spring Boot 2 to Spring Boot 3 reduces the known risk associated with the older version. That is good and necessary engineering. It also gives the application a new implementation, a new dependency graph, a new set of transitive packages and a new collection of vulnerabilities that simply haven't been discovered yet.

We solve yesterday's CVEs by accepting tomorrow's.

That isn't a criticism of Spring Boot. The same is true of virtually every framework and library we use. Replacing one framework with another doesn't solve the underlying problem. It rearranges it.

We are still inheriting someone else's implementation. We have just chosen a newer one.

Eventually, that changed the question I was asking. Instead of wondering which framework I wanted to depend on, I started wondering whether I needed to inherit the framework's implementation at all.

The Ship of Theseus, but With Dependencies

Around the same time, I found myself thinking about the Ship of Theseus.

The Athenians preserved the ship of the hero Theseus. As its wooden planks decayed, they replaced them. Over time, they replaced the mast, sails, rudder and eventually every original piece of the ship.

Philosophers then asked: If none of the original material remained, was it still the same ship?

Software has been wrestling with its own version of that question for years.

Imagine an application your team has maintained for a decade. Now replace every third-party dependency, one at a time. Replace the logging framework, HTTP client, JSON parser and every other inherited implementation until none of the original dependency tree remains.

The application still compiles. Every unit test passes. Every integration test passes. Every API returns the same result. Every customer has exactly the same experience they had before.

Is it still the same application?

My instinct is yes.

The application's identity was never located in Spring, Jackson, Log4j or whichever HTTP client happened to be popular when the first developer created the project. Those were implementation choices. They helped produce the application's behavior, but they were not the behavior itself.

If every implementation can change and the application remains the same, then the implementation may not be the real artifact.

The Real Artifact May Be Behavior

We have spent decades treating source code as the thing we are building and preserving. I'm beginning to wonder if that has always been a convenient proxy for something else.

When I use a JSON library, I don't care about its internal class structure. I care that it parses and produces valid JSON in the way my application expects.

When I use an HTTP client, I don't care which design patterns its maintainers chose. I care that it faithfully implements the part of HTTP my application actually uses.

When I call a Base64 encoder, I don't need to inherit somebody's entire ecosystem. I need bytes transformed according to a known standard.

What I actually consume is behavior.

Historically, behavior and implementation were difficult to separate because implementations were expensive to produce. The most practical way to share behavior was to share the source code that implemented it.

Agentic AI may allow us to separate the two.

That doesn't mean asking a model to "write me an HTTP client" and trusting whatever appears. The interesting part is not generation. The interesting part is proof.

A Different Kind of Software Supply Chain

Imagine a system that analyzes an application and determines exactly which behaviors it consumes from each dependency.

Not merely which packages are installed or which classes are imported. It would observe the methods called, data passed, edge cases expected and outputs relied upon. It would combine static analysis, runtime traces, unit tests, integration tests, protocol specifications and conformance suites to build a behavioral contract.

Then it would generate the smallest implementation that satisfies that contract.

The replacement would not need to reproduce the original library. In fact, reproducing the original library would defeat the point. It would implement only the capabilities the application needs, using a minimal dependency surface and an architecture designed for that specific context.

The system would then test the replacement against the original. It could run differential tests, compare outputs, replay production traffic, exercise edge cases and verify compliance with external standards.

If the new implementation behaves identically everywhere that matters, does the original implementation still matter?

Perhaps not.

The valuable thing may be the contract, the conformance suite and the evidence that the replacement preserves the required behavior.

This would invert the software supply chain we know today. Instead of downloading a general-purpose implementation and inheriting everything inside it, an application would consume a verified behavioral specification and produce only the implementation it needs.

The shared asset would no longer have to be the code.

Project Theseus

I've started calling this idea Project Theseus.

I don't have a finished architecture, and I'm not pretending the hard problems have already been solved. Extracting behavior from an existing application is difficult. Tests are incomplete. Runtime behavior can be unpredictable. Licensing questions remain. Cryptography, database drivers, protocol stacks and heavily optimized libraries may be terrible candidates for replacement.

There are also uncomfortable security questions. If an AI system generates a unique implementation for every application, how do we review it? How do we certify it? Does implementation diversity make attacks harder, or does it create millions of new places for subtle errors to hide?

Those questions are real. They are also why I think this idea is worth exploring instead of dismissing.

Project Theseus does not have to replace every dependency to be useful. It could begin with small, well-understood utilities. It could identify libraries that are used for only one or two behaviors. It could eliminate dead portions of a dependency graph or isolate vulnerable functionality behind newly generated adapters.

Even partial success could reduce attack surface, simplify SBOMs and give teams more control over the software they are ultimately responsible for operating.

The larger idea is this: perhaps implementations should become disposable.

For the last several decades, open source gave us a shared repository of implementations because implementations were expensive and scarce. That was the right answer to the problem we had.

The next software commons may look different. It may be a shared collection of behavioral contracts, open specifications, protocols, conformance suites, reference outputs and machine-verifiable proofs.

Those artifacts tell us what software must do without requiring every application to inherit the same code that does it.

Open source solved yesterday's problem by helping us share implementations.

Agentic AI may help us solve tomorrow's problem by making it possible to preserve behavior without preserving the implementation.

And if we can replace every plank while keeping the ship intact, then perhaps the code was never the ship in the first place.

In Part II, I'll lay out a possible architecture for Project Theseus: a team of specialized agents that maps an application's dependency graph, discovers the behavior it actually consumes, generates minimal replacements and builds the evidence needed to prove the application remains the same.