What is the moat when an agent can rebuild your product?

The problem

Patents were the solution for not having a moat. If the thing you invented was obvious once someone had seen it, the deal was simple: you disclose how it works, and in exchange the state gives you a time-boxed right to stop anyone else using it. The disclosure was the price, and the exclusion was the moat you couldn’t otherwise build.

For most software the practical version of that moat was never a patent. It was the time and cost of building the thing. A competitor could see your product, and could even guess how it worked, but they still had to spend a year and a team getting to parity (by which point you’d moved).

Agentic coding takes that away. A competitor doesn’t need to see your code, or even reverse-engineer it. They describe your product to an agent, point it at your public docs and your API, and get a working approximation back in days. The copy happens without the disclosure that patents were built around, so it isn’t clear what the equivalent deal even is.

What prompted this was ArtCraftArtCraft, an open-source alternative to Adobe's creative suite (Futurism, 2026-10-08)ArtCraft is a free, open-source creative suite with apps standing in for Photoshop (PhotoCraft) and Lightroom (LightCraft), built by a small vibe-coding team in Atlanta. Still in active development, some tools in early alpha.futurism.com ↗: a free, open-source suite with stand-ins for Photoshop and Lightroom (no account, no cloud, no subscription), built by a four-person team vibe coding out of Atlanta. It’s early alpha, and nobody is claiming parity. But it’s aimed at a business doing close to $18 billion a year, from a team you could fit in one car, and the code was the part that used to make that ridiculous.

So what is the moat now? I don’t have a good answer.

Why it’s hard (the tension)

The things that look most like the moat are exactly the things you hand to the agent. The spec, the data model, the interface you agonised over (ZFN-66Field Note · currentZFN-66 — Agonize over the interface, not the choice behind itRe-implementing a decision now costs hours. Changing an interface costs everyone standing on it. Spend deliberation at the boundary; hold the choice behind it loosely — on one condition: you know a decision was made, and where it lives. Unnoticed ones are the expensive kind.Open ZFN-66 →), the taste that decides what to build next… all of it becomes the prompt. A clearer spec builds a better product faster, and is also a better input to whoever wants to copy it. The moat and the leak are the same artifact.

Although that assumes implementation was ever really the moat for software. I’m not sure it was. Software patents were thin long before agents existed - AliceAlice Corp. v. CLS Bank International (2014)US Supreme Court decision holding that implementing an abstract idea on a generic computer is not patentable. It sharply narrowed which software inventions can be patented, and many existing software patents were invalidated under it.en.wikipedia.org ↗ gutted most of them in 2014 - and the businesses that lasted mostly lasted on things that had nothing to do with the code: users, data, distribution, the cost of switching away. If that’s right, agentic coding hasn’t removed a moat so much as removed the illusion that the engineering was one, and that’s a much less comfortable thing for an engineer to write down.

The other half of the tension is that the same tools are available to everyone. Whatever speed-up I get, the copier gets too, so “just move faster” is a relative advantage that rounds to zero.

What I’ve considered (none of these is the answer)

The test I keep applying to each candidate is a simple one: can it be regenerated from a description of the product, its public behaviour, and its docs? If it can, it isn’t a moat any more.

The code

Regenerable, by definition. It was only ever a moat because writing it was slow, and that’s the part that went away. Owning your components (ZFN-31Field Note · currentZFN-31 — Own your components — when you deeply understand the domainOwning your own components rather than generic off-the-shelf services is often the better path as you grow: own what's core, lean on small vetted libraries for the hard parts. LLMs make it attainable at smaller scale — but only when you truly understand the domain, or it hurts.Open ZFN-31 →) is still the right call for other reasons, but not this one.

The spec and the taste

Mostly regenerable. This is the essential difficultyNo Silver Bullet: Essence and Accident in Software Engineering (Fred Brooks, 1986)Argues that the hard part of software is its essential complexity (deciding what the system is), not the accidental complexity of expressing it, so no tool can deliver an order-of-magnitude improvement on its own.en.wikipedia.org ↗ Brooks described, and ZFN-71Signal · currentZFN-71 — Product-led teams were vibe coding before the LLMs wereThe worries about LLM-written code — decisions nobody made on purpose, a data model that fell out, architecture by accident — describe how product-led teams have treated engineering for a decade. LLMs hide those decisions further, and the cure is the rigor we sidelined.Open ZFN-71 → argues it’s now most of the job. But a product’s behaviour is a lossy encoding of its spec, and an agent watching that behaviour recovers a lot of it. Taste survives longer (you can copy what someone chose, not the next thing they’ll choose), although taste is a property of people, and people leave.

Data

Not regenerable, which is why it’s the obvious answer. But it only protects products whose value is the data, and a lot of software is valuable because of what it does, not what it has accumulated.

Distribution, network effects and switching costs

Not regenerable, and in Helmer’s7 Powers: The Foundations of Business Strategy (Hamilton Helmer)Names seven sources of durable advantage: scale economies, network economies, counter-positioning, switching costs, branding, cornered resource, and process power. Each requires both a benefit and a barrier that stops competitors arbitraging it away.7powers.com ↗ terms these were always the real powers. The honest problem is that they’re not engineering moats, and they say nothing to someone who doesn’t have them yet. Patents existed precisely to protect the window where you had an invention and nothing else.

Operational history

The record of what broke and why: incidents, edge cases found in production, the evals, the decision records (ZFN-1Field Note · currentZFN-1 — Keep engineering decision recordsRecord significant engineering decisions as short, versioned markdown files — context, decision, consequences. Write one for cross-team contracts, directional principles, hard-to-reverse choices, and conventions others must follow. Cite them instead of re-arguing.Open ZFN-1 →) explaining why it’s shaped the way it is. A copy built from a description starts with none of it, which makes this the strongest candidate on the regeneration test. But it only compounds if it’s written down, and once it’s written down it’s a document, and documents leak or get handed to agents. The undocumented version lives in people’s heads, which is the moat that walks out the door.

Speed

Iterate faster than anyone can copy. This was always part of the answer, but with the copier using the same agents it collapses into “be better at using the tools”, which is real but not durable.

Patents, again

Patent the inventions that agents help you make. Slow, expensive, mostly unenforceable for software after Alice, and an agent can design around a claim about as cheaply as it can implement one!

Where I’m stuck

Every candidate that survives the regeneration test is either not an engineering advantage (distribution, data, users) or only an advantage while it stays undocumented (operational history, taste). The second group is uncomfortable, because it cuts directly against ZFN-1Field Note · currentZFN-1 — Keep engineering decision recordsRecord significant engineering decisions as short, versioned markdown files — context, decision, consequences. Write one for cross-team contracts, directional principles, hard-to-reverse choices, and conventions others must follow. Cite them instead of re-arguing.Open ZFN-1 →, which argues for writing the reasoning down so it outlives the people who held it. A moat that depends on that not happening is a moat built on the same fragility decision records exist to remove.

So either the engineering moat is gone and the honest answer is “build distribution”, or there is a form of accumulated operational knowledge that compounds faster than it leaks, and I can’t yet say what shape it has.

What a good answer looks like

• It survives a competitor who can rebuild the product from its description in a week.
• It compounds with use, so being earlier is worth more over time, not less.
• A small team can actually build it, rather than it being something you only have once you’ve already won.
• It doesn’t depend on keeping knowledge undocumented or out of the team’s hands.

References

• Joe Wilkins, ArtCraft coverage, Futurism (2026-10-08)
• Alice Corp. v. CLS Bank International (2014)
• Hamilton Helmer, 7 Powers
• Fred Brooks, No Silver Bullet (1986)

Changelog

• 2026-10-09: Opened as an open problem.
• 2026-10-09: Added the ArtCraft example that prompted it.