When Copying Software Costs Almost as Much as Describing It

There is an effect of agentic coding that still does not get much attention: it is not only lowering the cost of building software.

It is also lowering the cost of rebuilding it.

That difference matters.

Until recently, even if you had an existing product right in front of you, reproducing its behavior still required a substantial amount of work.

You had to study the interface, understand the flows, reconstruct the logic, choose an architecture, implement the frontend and backend, handle edge cases, test everything, and fix whatever did not work.

The fact that the original product already existed solved the ideation problem.

It did not solve the execution problem.

That second problem is now shrinking very quickly.

From observable software to generatable software

With current tools, you can start from screenshots, screen recordings, documentation, public APIs, and the observable behavior of an application, and turn all of that into a specification detailed enough for one or more agents to execute.

That is the interesting shift.

Observable software is increasingly becoming describable software, and describable software is increasingly becoming generatable software.

Take a reasonably complex desktop application.

One agent can analyze screenshots and infer an initial component structure.

Another can implement the layout.

Another can work on the main flows.

Another can generate tests, compare the result with the original, and fix the differences.

If the application relies on common patterns, a large part of the complexity does not even need to be rediscovered.

Authentication, synchronization, command palettes, drag and drop, sidebars, editors, state management, caching, payments, persistence: these are all familiar building blocks.

The model does not need to invent a new system.

It needs to recognize what kind of system is likely behind the product and build something equivalent.

Reverse engineering is changing

This changes what reverse engineering means.

Traditionally, software reverse engineering required a deep technical understanding of the system being analyzed.

Today, more of that work can move from reverse engineering the implementation to reverse engineering the behavior.

You do not necessarily need to know how the original product was built.

You need to understand what it does.

If I know the inputs, outputs, main flows, and observable constraints, I can build a completely different system internally that is still equivalent enough from the user’s perspective.

For many products, that is what matters.

There are obvious limits.

An interface is much easier to reproduce than a proprietary algorithm.

A workflow is easier to imitate than a dataset built over ten years.

A CRUD SaaS application is easier to rebuild than a graphics engine, a distributed database, or a system whose value depends heavily on infrastructure.

But a very large share of commercial software does not belong to the category of technically irreproducible problems.

It belongs to the category of problems that have already been solved, packaged well, and distributed even better.

And this is where agentic coding becomes particularly interesting.

Code has always been a barrier, even when it was not unique

For years, code acted as a competitive barrier even when there was nothing especially innovative about it.

Not because it was impossible to reproduce.

Because reproducing it was expensive.

You needed a team.

You needed weeks or months.

You needed someone for the frontend, someone for the backend, someone for infrastructure, someone for testing.

That cost protected the product indirectly.

Today, a single developer can delegate parts of that work to multiple agents and coordinate the result.

Productivity does not increase only because code is written faster.

It also increases because many tasks that used to be sequential, or required different people, can now run in parallel.

At that point, a different question becomes important:

What happens when the cost of replicating a feature falls below the economic value of that feature?

Imagine a company launches something genuinely useful.

Until recently, a competitor might have needed six months to reproduce it.

Today, maybe one month.

Tomorrow, perhaps a week.

The time advantage still exists.

It just lasts much less.

Implementation differences may have a shorter lifespan

This does not mean that all software will become indistinguishable.

It means that differences based purely on implementation may have a much shorter lifespan.

The idea of a technical moat therefore needs to be treated more carefully.

A complex codebase does not automatically mean a strong competitive barrier.

Ten years of code do not automatically translate into ten years of advantage.

Sometimes they simply represent ten years of accumulated technical decisions, many of which can be avoided by someone starting today.

A new competitor does not need to reproduce your architecture.

They need to reproduce the value perceived by the user.

And they can do that with a completely different stack.

That is one of the most interesting consequences of AI-assisted development:

AI does not only accelerate the company that builds first. It also accelerates the company that arrives second.

The second mover may become more dangerous

In some cases, the second mover may even have structural advantages.

They already have a validated product in front of them.

They can see which features users care about.

They can observe which design decisions worked.

They can avoid years of failed experiments.

And now they can dramatically reduce the cost of implementing what they have learned.

The first mover still has advantages.

But one particular advantage is getting weaker: the advantage that came simply from having written the software before everyone else.

That pushes value somewhere else.

What becomes harder to copy

If implementation becomes cheaper, the more durable advantages are likely to be the ones that cannot be reconstructed from screenshots and documentation.

Distribution.

Proprietary data.

Network effects.

Community.

Reputation.

Commercial agreements.

Integrations that are difficult to obtain.

Domain expertise.

The ability to iterate faster than everyone else.

That last one matters a lot.

If everyone can copy a feature, the advantage is no longer simply owning that feature.

The advantage may be being on the next feature by the time everyone else finishes copying the previous one.

Speed does not disappear as a competitive advantage.

It changes form.

Before, speed could mean:

We can build something others cannot build.

Increasingly, it may mean:

We can figure out before everyone else what is worth building next.

That is a very different kind of advantage.

Writing code and deciding what to write are different skills

Writing code and deciding what code should exist have always been separate skills.

AI is reducing the cost of the first much faster than the cost of the second.

That is probably why product clones that would once have required entire teams can now appear in surprisingly short periods of time.

This is not only a democratization of software development.

It is also a democratization of software replication.

The same technology that allows one person to build something that used to require ten developers also allows that same person to rebuild something that used to require ten developers.

The two effects are inseparable.

And it is difficult to imagine that this will not change the economics of software.

The expensive part may move outside the codebase

We may be moving toward a world where producing a working application becomes relatively cheap, while everything around it becomes increasingly expensive.

Finding users.

Earning trust.

Obtaining data.

Building a community.

Understanding a market.

Making good product decisions repeatedly.

Code will continue to matter.

It simply may no longer be the hardest part to copy.