In Two theories of a programmer I argued that when a fleet does the typing, the scarce thing moves upstream — to judgment. This post is the same argument applied to companies. If one person with agents can build your product in a year, what exactly is your product worth?
The demonstration
Over roughly a year, I built Sirv AI Studio: a digital asset manager, a PIM layer, a supplier portal, a workflow engine, and a 47-tool MCP server. A fleet did the typing; I did the deciding. This is not a boast — it’s the problem statement. Because if I could do that, so can a competitor with the same tools. Whatever I shipped last quarter, someone else can ship next quarter.
That collapses forty years of instinct about defensibility. The instinct says features are assets: every tool, every integration, every screen is a brick in the wall. The instinct was calibrated for a world where bricks were expensive. They aren’t anymore. So I wrote a filter into Studio’s strategy docs and it has survived every argument since:
Anything an agent fleet can rebuild in a quarter is not a moat.
The corollary matters more than the rule. Agents compress construction time. They do not compress calendar time, other people’s adoption decisions, or the accumulation of history. Whatever needs one of those three to exist is still scarce — and in a fleet economy, it’s the only thing that is.
The non-moats
State them plainly, so nobody mistakes them for strategy. Everything in the left column of my own product is on the clock:
Decays in quarters
- AI tool count — every tool wraps a model rented from the same vendors. fal.ai does not care who calls it.
- Workflow step types — 39 today, copyable in a sprint.
- UI polish — necessary for conversion, worthless for defense.
- MCP support itself — a protocol implementation, weeks of work for anyone.
- Model access and prompt quality — rented and leaky, respectively.
Compounds in years
- Operational history — every approval, publish, rollback, and supplier submission is a row that exists nowhere else.
- The product graph — but only while it's more truthful than the platform's own data.
- The supplier network — the only entry with true network effects.
- The safety record — compounds slowly, destroyed in one afternoon.
- Owned distribution — rankings and relationships that survive feature parity.
None of this argues against building the left column. You can’t convert customers without tools, polish, and protocol support. It argues against believing the left column protects anything. A feature is a cost of entry that recently learned to impersonate an asset.
What actually compounds
The right column deserves more than bullet points, because each entry has a condition attached — a way it stops being a moat if you handle it carelessly.
Operational history is the strongest switching cost available to a product like mine, and it accrues automatically — but only from real usage. After a year, a workspace’s history answers questions no rival can: what was live during the December sale, who approved the hero image, which supplier’s uploads fail validation most often, what the listing looked like before the AI pass. Ten merchants running the loop weekly build more moat than ten new features. That sentence is the entire growth strategy, and it is humbling to type.
The product graph — assets linked to products, variants, channels, approval states — is a moat only while it is more truthful than Shopify’s own data. The moment the graph drifts from the store, it flips from asset to liability. Which reframes a whole category of unglamorous engineering: drift detection and sync integrity aren’t plumbing. They’re moat maintenance.
The supplier network is the only asset on the list with real network effects: a supplier who serves multiple merchants is a carrier. And the loop only spins on supplier-side experience — speed, clarity, “this saved me a re-shoot.” Portal branding serves vanity. The loop doesn’t care about vanity.
The safety record has the cruelest asymmetry. “Publish safely, roll back instantly” is a claim any competitor can print on a landing page tomorrow. Years of touching live stores without a destructive incident cannot be printed. It also cannot be repaired quickly: one viral story of a tool overwriting a merchant’s catalog undoes the accumulation. This is why I keep a rule that outranks every deadline: no publish-touching feature ships without idempotency, drift checks, per-product status, and rollback. Reliability engineering isn’t a cost center. It’s an insurance premium on the brand, and it’s worth paying forever.
Owned distribution — search rankings, app-store position, an existing customer base — takes quarters to earn and survives feature parity. It’s the moat that buys you time to build the other four.
Notice what all five have in common: time, other people, or accumulated events. Exactly the three things a fleet cannot compress.
The rules that fall out
A doctrine is only useful if it changes decisions. Four rules from mine that do:
Schema decisions are moat decisions. Lineage, approval attribution, publish history, supplier provenance — first-class in the data model even when no UI shows them yet. History you don’t record in 2026 cannot be sold as a moat in 2028. The fleet can rebuild your screens; nobody can rebuild the rows you never wrote.
Easy export, sticky value. Let customers export everything, loudly. Willingness to deposit history into your system depends on believing it isn’t hostage. The confidence behind that rule: exported history is dead data, while in-place history powers readiness checks, rollback, and agents. Lock-in by value, never by lock.
Feed the network before the feature list. A new marketplace integration adds a row to a comparison table. A supplier who recommends the product to a second merchant adds revenue. When the two compete for the same quarter, the supplier wins.
Count moat, not features. The quarterly dashboard that replaces the changelog as a scoreboard:
That last rule is the uncomfortable one, because a fleet makes shipping feel like winning. Five thousand commits a month is a genuinely new kind of productivity, and it is also a genuinely new kind of temptation: construction as a vanity metric. The dashboard exists to ask the only question that matters at the end of a quarter — did anything accumulate that a competitor’s fleet can’t rebuild?
Every moat has an attacker
A defensibility claim you haven’t red-teamed is a wish. Run the column on the right through the same skepticism as everything else:
Operational history gets attacked by import tools — “bring your Shopify history into CompetitorX.” The defense is depth the platform API cannot express: approvals, supplier provenance, AI derivation lineage. The history worth having must only be recordable inside your system. The product graph gets attacked by the platform itself exposing richer metadata; the defense is staying multi-source, covering what the platform cannot see. The supplier network gets attacked by a supplier-first competitor inverting the model — the one attack worth genuinely watching for. Distribution gets attacked by algorithm changes and ad budgets; the defense is never letting one channel be load-bearing.
And the safety record gets attacked by exactly one adversary: your own mistakes. No competitor required.
What this is really about
Two theories, again. The old theory of a programmer valued typing; the fleet made typing free, and value moved to judgment. The old theory of a software company valued construction — and the fleet just made construction free too. Value is moving to the things construction can’t produce: recorded history, earned trust, other people’s habits, time.
The pattern generalizes past my product, past commerce, probably past software. Whatever your industry’s version of “34 AI tools” is — that’s typing. Whatever your version of “four years of incident-free publishes” is — that’s the job now.
Fleets compress construction. They do not compress trust. Plan accordingly.
Sequel to Two theories of a programmer. The product whose strategy docs this post is lifted from is Sirv AI Studio.