For most of the history of the software industry, code was scarce.

A large, mature application represented thousands or millions of hours of accumulated engineering work. Adobe Photoshop, Microsoft Excel, AutoCAD, Oracle Database, and countless less famous enterprise applications were valuable partly because reproducing them was extraordinarily expensive.

The source code was intellectual property because the source code represented an enormous amount of labor.

Open-source software operated under the opposite model. Its great advantage was that anyone could see the code, improve it, fix bugs, and submit those improvements upstream. Developer labor was scarce, so additional competent contributors were valuable.

Artificial intelligence is beginning to invert both assumptions.

We are approaching a world in which code is abundant.

And when code becomes abundant, some surprisingly fundamental things about the software industry change.

Code Is Becoming Documentation

Programmers have long joked that “the code is the documentation.” Usually, that was a complaint.

Documentation becomes obsolete. Design documents drift away from implementations. Comments lie. Eventually the only authoritative description of what a system actually does is the source code itself.

The problem was that humans could not realistically treat a ten-million-line codebase as documentation. Understanding it might require months or years of institutional knowledge.

AI changes that.

An agent can search enormous repositories, trace call graphs, inspect implementations, infer interfaces, reconstruct architectural relationships, identify invariants, and generate descriptions of behavior.

The code increasingly becomes machine-readable documentation.

Research on specification-driven development is already moving in the complementary direction. Instead of treating manually written code as the primary artifact, specifications can become the authoritative artifact from which agents generate and verify implementations.

Put the two directions together:

Code → specification
Specification → code

That is a profound change. And source code may not be the boundary.

The Binary Is Becoming Documentation Too

A compiled executable contains less information than its original source. Compilation strips away names, comments, abstractions, types, and much of the structure that made the program comprehensible to humans.

But it cannot strip away everything. Ultimately, the computer still has to execute the program.

Traditional reverse engineering has therefore always been possible. It has simply been expensive. Skilled engineers armed with tools such as IDA, Ghidra, debuggers, profilers, and decompilers can reconstruct surprisingly sophisticated understanding from binaries.

AI attacks the expensive part: human attention.

This is no longer theoretical research. Columbia's SRE-Bench was explicitly created to measure whether AI agents can understand software when they receive compiled binaries but no source code. Its programs were created privately to avoid the possibility that models had simply encountered their source during training.

Other researchers are combining traditional decompilers with multiple AI agents and automated behavioral validation. Open-source tools are appearing that combine Ghidra, LLMs, independent checking agents, build-and-test gates, and behavioral parity analysis to reconstruct functions from binaries.

None of this means arbitrary commercial applications can be perfectly regenerated from their binaries today. Real applications are vastly larger, legal restrictions matter, anti-analysis techniques exist, and semantic equivalence is difficult to establish.

But the direction is hard to miss.

Executable → decompilation → behavioral analysis → recovered specification → independent implementation → differential testing

Every stage is becoming increasingly automatable.

Once that pipeline becomes sufficiently reliable, a proprietary executable becomes something software vendors have rarely had to think of it as: a machine-readable description of their product.

That Changes the Economics of Proprietary Software

Imagine a specialized enterprise application developed over twenty years.

Perhaps it has 500 customers paying $100,000 per year. That produces a $50 million annual business.

The application may not contain a revolutionary algorithm. Its moat may simply be accumulated functionality: thousands of screens, workflows, business rules, import formats, integrations, reports, edge cases, and fixes.

Historically, reproducing it might have required 100 engineers and several years. That historical implementation cost protected the vendor.

Now imagine that eventually an AI system can analyze the application, recover its observable requirements, construct an enormous structured specification, generate an independent implementation, and continuously test the new implementation against the original.

Suppose that turns a $50 million, five-year reimplementation project into a $1 million, six-month project.

The incumbent's economics have changed radically.

This doesn't mean copyright disappears. Copyright, patents, trademarks, trade secrets, contractual restrictions, and laws governing reverse engineering remain important. Nor does functional similarity automatically make a competing implementation lawful.

The important point is economic rather than legal: the historical cost of implementing software may cease to provide much protection.

A company that spent thirty years discovering what customers needed has encoded much of that accumulated knowledge into its product. An AI competitor may increasingly be able to observe the result without paying the same discovery and implementation costs.

That makes distributing the implementation itself increasingly uncomfortable.

The Retreat to the Cloud

Software companies already have powerful reasons to prefer SaaS: recurring revenue, centralized deployment, telemetry, piracy prevention, rapid updates, and tighter customer relationships.

AI-assisted reverse engineering adds another: don't give customers the implementation.

If the valuable algorithms execute on the vendor's servers, competitors can observe inputs and outputs but cannot directly inspect instruction streams, constants, internal data structures, libraries, control flow, and implementation details.

The natural architecture becomes:

Thin client → network API → proprietary implementation

rather than:

Customer → proprietary executable

For applications requiring local GPUs, low latency, offline operation, industrial control, or large local datasets, the division may be more complicated. Commodity functionality can execute locally while differentiating functionality remains server-side.

But the incentive is clear.

Ironically, that creates an opportunity for AI-native competitors. Customers frequently dislike subscriptions, mandatory accounts, cloud dependencies, and sending their data to vendors.

If AI makes recreating mature functionality dramatically cheaper, a challenger can offer precisely what the incumbent is retreating from: runs locally, own your files, no subscription, no cloud dependency.

The incumbent moves toward the cloud to protect its implementation. The challenger uses cheap AI-generated implementation as a competitive weapon.

Then Open Source Encounters the Opposite Problem

Open source traditionally assumes that outside code contributions are valuable. That assumption makes sense when competent programming labor is scarce.

But what happens when producing a plausible pull request costs essentially nothing?

We are beginning to find out.

GitHub is already discussing how maintainers should deal with contribution queues containing substantial amounts of agent-generated work. Google has changed its Open Source Software Vulnerability Reward Program after a massive increase in AI-generated reports, including hallucinated vulnerabilities and reports with negligible real security impact.

This exposes the new economics.

Generating the report is cheap. Determining whether the report is correct is expensive.

Generating the patch is cheap. Determining whether the patch belongs in a production system is expensive.

An anonymous contributor can spend five dollars of inference generating a 20,000-line change. A maintainer may have to spend two days determining whether it is safe.

The contributor has externalized the expensive part of the transaction.

At sufficient scale, this becomes a denial-of-service attack on maintainership.

Open Source May Become Operationally Closed

That doesn't mean open source disappears. It means we need to distinguish two concepts that historically traveled together: the right to inspect and modify source and the ability to contribute code upstream.

The first can remain completely open. The second may become heavily gated.

Large projects may increasingly require contributor reputation, automated pre-review, reproducible tests, provenance, maintainer sponsorship, or demonstrated evidence before a change ever consumes scarce human attention.

And eventually there is an even more interesting model.

Instead of saying “Send us a patch,” the project says “Send us a problem.”

Submit a failing test. Submit a reproducible bug. Submit a benchmark regression. Submit a security exploit. Submit an interoperability case. Submit a proposed behavioral specification. Submit evidence that something should change.

Then the project's own trusted agents generate the implementation.

The community contributes knowledge and evidence. The project controls code synthesis.

Open source remains open legally while becoming increasingly controlled operationally.

The Proprietary/Open-Source Paradox

This creates a strange symmetry.

For proprietary software, AI makes code too valuable to expose.

For open-source software, AI makes code too cheap to accept indiscriminately.

Those sound contradictory, but they're consequences of the same underlying phenomenon.

The economic value is migrating away from the act of writing code.

For proprietary vendors, the valuable thing becomes the knowledge embodied in the implementation, the proprietary data behind it, the service infrastructure, distribution, integrations, customer relationships, and continuing innovation.

For open-source projects, the valuable thing becomes maintainer judgment, architectural coherence, trusted governance, acceptance criteria, and control over the canonical artifact.

Both are responses to code becoming abundant.

The End of “AI Slop”

Today we hear constantly about AI-generated “slop.” Much of the criticism is justified.

An inexperienced developer can ask an agent to create an application, repeatedly prompt it until the application appears to work, and deploy something whose architecture, security, failure behavior, and maintainability nobody understands.

But that may be a transitional phenomenon.

Compilers once eliminated large categories of assembly-language mistakes. Garbage collection eliminated many memory-management failures. Strong type systems eliminated other categories of defects.

AI development systems can potentially raise the floor much further because they can inspect semantic and architectural behavior.

The important threshold isn't when AI becomes incapable of producing bad code. Humans have never crossed that threshold either.

The threshold comes when the normal AI development system doesn't merely generate a change. It generates the change, compiles it, tests it, fuzzes it, checks its dependencies, examines security properties, measures performance, verifies architectural constraints, exercises boundary conditions, and rejects its own work when those checks fail.

The unit of production stops being code.

It becomes a validated change.

At that point, attitudes toward AI-generated software may reverse surprisingly quickly.

Today the question is: “Was this code written by AI?”

Eventually the suspicious question may be: “You wrote this manually? What verified it?”

Hand-written, unverified code may someday look the way hand-written assembly does today: occasionally necessary, sometimes brilliant, but an unusual decision requiring justification.

Code Was Never the Real Product

This brings software engineering back to something we have always known but frequently ignored.

Customers don't actually want code. They want behavior.

The purpose of a payroll system isn't its Java classes. The purpose of Photoshop isn't its C++. The purpose of a trading system isn't its Python.

The code is an implementation of an intended behavior.

When implementation was expensive, we naturally organized the industry around producing and protecting implementation.

When implementation becomes cheap, attention moves elsewhere.

What should the system do? Under what conditions? What must never happen? What evidence demonstrates correctness? Which behaviors matter? Which tradeoffs are acceptable? Who decides when the artifact is good enough?

These are specification and validation questions.

The old software lifecycle looked approximately like this:

Requirements → humans → code → tests → product

The emerging lifecycle looks more like:

Intent → specification → agents → implementation → automated validation → evidence → human judgment

The implementation is still necessary. It just isn't necessarily the scarce part.

What Becomes Valuable?

If this transition continues, the durable assets of a software organization increasingly become:

Those things are much harder to generate than another implementation of a known specification.

This may also explain why specification-driven development is attracting renewed attention just as coding agents become powerful. The discipline isn't appearing despite increasingly capable models. It is appearing because of them. As implementation gets cheaper, ambiguity upstream becomes increasingly visible as the bottleneck.

Software After Code Scarcity

We aren't there yet.

Binary reverse engineering remains imperfect. Coding agents still make serious mistakes. Specifications remain incomplete. Formal verification is difficult. AI-generated contributions really can be slop. Human engineering judgment remains essential.

But those are statements about the current position on a capability curve, not necessarily fundamental barriers.

The important question is therefore not whether today's agent can perfectly reconstruct Photoshop, maintain Linux, or autonomously build a million-line enterprise system.

The important question is what happens if the cost of these activities continues falling.

The software industry was constructed around a basic economic fact: producing good code is expensive.

Licensing models, engineering organizations, open-source contribution models, intellectual-property strategies, career ladders, development methodologies, and software-company valuations all grew in an environment where that statement was true.

We are entering an environment where it may increasingly be false.

And when a previously scarce resource becomes abundant, industries don't merely become more productive.

They reorganize around whatever is scarce next.

For software, that increasingly looks like specification, evidence, validation, proprietary knowledge, and judgment.

The code doesn't disappear. It becomes infrastructure.

And perhaps the strangest outcome of the AI coding revolution will be that, after spending seventy years building an industry around writing code, writing the code becomes one of the least interesting parts of building software.

Todd Espy · October 2026