Everyone is asking an old question
Anyone building an AI product will eventually run into the same question: what is your moat? Investors ask it. Founders ask it. Competitors ask it. Often, you ask it yourself. It sounds like basic business discipline, but hidden inside the question is an assumption from an older era: that advantage is a piece of territory. If the boundary is clear enough and the defense is strong enough, it can be held for a long time.
The moat is, after all, a medieval metaphor. It assumes a castle, a ring of water, and a relatively stable boundary between inside and outside. If someone wants to get in, they have to cross the water first. That metaphor worked in many industries because technology changed slowly, distribution channels were stable, switching costs were high, and certain resources really could be controlled for a long time.
AI makes all of those conditions unreliable at once. A feature can be swallowed by a stronger model. An interface can be copied quickly. A prompt structure can be unpacked. A workflow can be recombined. What looks today like a defended piece of ground may, tomorrow, turn out to be a landscape that has already changed shape.
That is why “AI products have no moat” became common sense so quickly. It describes a real condition: when model capabilities rise quickly and engineering costs keep falling, a single product form rarely becomes a durable barrier by itself. But if the thought stops there, it is only another expression of anxiety. The important question is not whether moats still exist. It is what should replace the moat when the moat is no longer dependable.
My answer is: build your sense of security on growth. A moat is a static defense. The day it is finished is the day it is most complete; after that, it can only age, silt up, or be bypassed. In the AI era, what is more worth accumulating is a dynamic capability: not one specific product, but a system that can continuously absorb judgment, encode experience, transfer capability, and accelerate iteration. I call this compounding capability. Its carrier is integrated capability.
A product is a snapshot
A product looks like a finished thing. It has features, an interface, pricing, user paths. It can be sold, demoed, screenshotted, and compared. More precisely, though, a product is a snapshot: it freezes the technical conditions, user understanding, market judgment, and engineering tradeoffs of a particular moment into a visible shape. That shape has value. The problem is that, in the AI era, snapshots depreciate quickly.
With each step up in model capability, some of the choices embedded in older products stop making sense. The engineering you wrote to work around a model weakness may become unnecessary in the next generation. A complicated interaction you designed to reduce user confusion may become friction once a new interaction pattern emerges. A carefully packaged feature difference may suddenly become one default model call.
This does not mean products do not matter. It means they are better understood as stage outputs than as permanent assets.
That is why “does my product have a moat?” is an easy question to get wrong. It puts attention on the snapshot and tries to prove that the photograph can stay fresh forever. But when the underlying capability layer keeps changing, the better question is not how long the snapshot can last. It is whether the capability that produces snapshots is getting stronger.
Products depreciate. Capabilities can compound.
In other words, what truly accumulates is not the product itself, but your ability to turn judgment into a working system. The product is only the output of that capability at a particular moment. If one product is caught, replaced, or rebuilt, your core asset has not necessarily disappeared. The real problem begins only when you can no longer produce the next generation of output faster than before.
What accumulates is not features, but capability
Integrated capability does not mean “knowing how to use AI.” It also does not mean plugging a few models into an existing process. The important word is integration: AI stops being an external tool and becomes woven into the working system. Your judgment, context, standards, exceptions, and preferences no longer live only in people’s heads or meeting notes. They are encoded into structures that can run, be inspected, and be revised. What accumulates in such a system is not only efficiency, but four kinds of assets.
Stock: turning tacit judgment into an asset
Experienced people carry a great deal of tacit judgment. A screenwriter knows when a character motivation does not hold. A creative director knows when an expression is polished but empty. A product lead knows whether a user is describing a real need or only a symptom. In the past, these judgments lived mostly inside individuals and moved slowly through meetings, comments, and spoken feedback. They were valuable, but their radius was small.
Leverage: giving judgment a larger radius
Once judgment enters a system, the first thing that happens is leverage. One person’s judgment no longer applies only to one draft, one meeting, or one project. The system can first cover the repetitive, obvious, and structured problems. A producer is still judging scripts, but their position changes: instead of executing judgment draft by draft, they increasingly maintain the standards by which judgment is executed. The system makes the first pass; the person handles the more complex parts the system cannot.
This is not simply an efficiency gain. Efficiency is only the surface result. The deeper change is that the person’s level in the workflow moves upward. They go from referee to rule-maker, from someone who repeatedly performs judgment to someone who designs how judgment should be performed. At a certain point, the original capability gains a wider radius and may even change the person’s role inside the workflow.
Transfer: moving old experience into new terrain
The second derivative capability is transfer. AI does not only help people do what they already know how to do faster. It also allows old experience to land in fields it could not previously enter. A person’s experience may have been trapped inside one professional terrain because it lacked the right medium of expression and execution. AI provides that medium.
I do not write code, at least not in the sense of being a traditional software engineer. But I understand creative judgment, and I understand how to break judgment into standards, boundaries, and exceptions. Through AI collaboration, those experiences can move into system-building. This is not AI magically giving me a new skill from nowhere. It is giving old experience a new place to land. Leverage grows upward; transfer reaches into other terrain. Both share the same engine: existing capability is the source material, and AI is the amplifier and carrier.
Rate: what really compounds is the speed of encoding judgment
The most overlooked asset is rate. The first time you turn someone’s judgment into a system, it is usually slow, because you discover that much of what people call experience is intuition that has never been unpacked. You have to ask: why is this wrong? Under what conditions does this judgment hold? Are there exceptions? Should it become a hard constraint, or only a warning? Is it a standard, or a preference?
The second and third times, you get faster. You begin to know where to enter, which questions to ask first, which judgments can become checks, which must remain human discretion, and which rules need to be rebuttable from the start. What you accumulate is not only one system, but the meta-capability of turning judgment into systems. Stock, leverage, and transfer are the forms that grow out of the plant. Rate determines how much it can grow next year.
Barriers fail. Growth continues.
Taken together, these four assets are not the same kind of asset as a moat. A moat cares about boundaries; it asks whether other people can get in. Compounding capability cares about change; it asks whether you can keep getting larger, deeper, and faster. The basic posture of a moat is defense: it assumes the current form is worth preserving for a long time. The basic posture of compounding capability is evolution: it does not require the current form to remain permanently valid.
This distinction matters in the AI era because “others cannot do this” is becoming a less reliable promise. Many things are not impossible to copy; the cost of copying them is falling. The more you build your security on non-replicability, the more exposed you become to model improvements, tool diffusion, and distribution shifts. Compounding capability offers a different source of security. It does not promise that others cannot act. It requires your own absolute level to keep rising.
Competition, then, is no longer only a contest of static position. Your product today may be caught. But if your speed of encoding judgment, transferring capability, and iterating systems is improving, then what you lost was one output, not the ability to produce outputs. Moat thinking makes you obsess over proving that you are different. Compounding-capability thinking brings you back to a more inspectable question: can I do this year what I could not do last year? Can my next project turn judgment into a system faster than my last one?
How to test compounding capability
A concept that cannot be inspected quickly becomes a nice phrase. Compounding capability can be measured, at minimum, through two numbers: stock and rate.
Stock is the depth of judgment you have already encoded into systems. It determines what you can do now: the standards libraries, workflows, checks, specifications, and constraints that have been tested in real projects. Rate is how long it takes you to turn a new judgment into a working system. It determines what you will be able to do next.
Most people look at stock because stock is easier to show. Systems, demos, cases, and rule libraries can all be presented. But the longer-term gap is often created by rate. Stock ages. Rules become obsolete. Experience stops applying. Some judgments will be absorbed directly by newer models. Rate is different. If you keep doing integration, it can improve. What makes an organization formidable is not how much it already knows today, but how quickly it can turn what it learns next into a system.
Extract judgment from real work
In practice, the actions are not complicated. What matters is sequence and boundaries.
Start where judgment density is highest.
Do not start with the loudest pain point. Pain is loud, but it is not always the best place to systematize. The best starting point is the work you repeat, the corrections you make again and again, the hidden standards you keep applying across projects. If something appears repeatedly across different contexts and depends each time on a great deal of unwritten judgment, it is the first candidate. The higher the judgment density, the more valuable it is to encode.
Encode constraints, not prompts.
Prompts are useful for starting a conversation. They are not a reliable container for stable judgment. If judgment lives only inside a prompt, it can be diluted by context or turn into a sentence that sounds right but executes vaguely. Better containers are checks, rejection conditions, tests, standards libraries, and versioned rules. A system that can say “this does not work because the character has not been given a reason to make this choice” is more valuable than a system that merely continues generating scenes, because the former preserves judgment.
Make the system rebuttable.
Encoding judgment into a system does not make the judgment sacred. People are wrong. Industries change. Models improve. Standards expire. The system needs versions, revision history, and a specification that governs it. I usually put a system under a SPEC: important changes update the SPEC before they update the implementation. The point is not ceremony. The point is to keep the system from becoming a black box. A good system should allow the original judge to argue with it. Otherwise it is not preserving capability; it is preserving rigidity.
Run it inside real work.
Real capability does not grow inside demos. Demos are too clean, too cooperative, too rehearsed. The useful signals appear only inside real workflows: which rule keeps creating false positives, which boundary remains blurry, which judgments conflict with each other, which user behaviors violate the plan completely. These signals cannot be fully imagined before launch. They are byproducts of running the system. And they are exactly what gives the system its ability to grow.
Ask the question differently
When someone asks, “What is your moat?” the best answer may not be a new defensive story. Often, the more honest answer is: if by moat you mean a position other people cannot enter for a long time, I do not have one, and I should not build my strategy on that assumption.
This is not giving up on defense. It is not believing that speed solves everything. It is changing the question. The old question asks: why can’t others catch you? The new question asks: after others catch one product form, can you generate the next one faster? The old question looks for non-replicability. The new question looks for sustainable regeneration.
These two questions lead companies toward different actions. The first makes people spend their energy proving that a feature, workflow, or interface is difficult to copy. The second forces them to accumulate more fundamental assets: how judgment is extracted, how standards are encoded, how systems reveal problems inside real workflows, and how methodology is reused faster in the next project.
AI-era products will be hard to keep from depreciating. They will be rewritten by model upgrades, replaced by new interaction patterns, and compressed by cheaper implementation. But if every product depreciation helps you understand faster how to turn judgment into systems, then depreciation is not only loss. It becomes raw material for capability.
Compounding capability is not a prettier phrase for moat. It is a different source of security. You no longer tie yourself to a fixed form, and you no longer need to keep proving that others will never be able to do what you do. What you really have to prove is that you can still grow new capabilities from each round of change.
That is also an important competitive advantage in the AI era: not the ability to defend a particular form, but the ability to keep generating the next one.
About the author
Qinqin (Stella) Yang is a creative AI builder and experiential creative director. She builds workflows, systems, and creative direction that operate under real constraints, and designs speculative frameworks that expand what teams can imagine before they start making. Over the past decade she has built brand experiences, product design, and speculative projects for Tencent, IKEA SPACE10, Burberry, and the Palace Museum. She is the founder of Actual Fiction, where she develops AI-native tools that turn imagination into a working method.
This newsletter is where she thinks out loud about creativity, AI, and what it means to build toward a future that doesn’t exist yet.
More at qinqinyang.com · Practice at Actual Fiction