Product-experience intent and technical intent in one tree

The split most teams have today

• Designer docs / Figma comments / PRDs (product-experience side)
• ADRs / RFCs / runbooks (backend side)
• Why these drift apart: different audiences, different review cadences, different tools.

Intent is not just behavior-only programming

Intent-driven development can look, from the outside, like vibe coding, where the human never reads the code and only says what the program should do. That is one possible mode, especially when the person giving direction has no technical opinion. But it is not the model we mean here.

For a development company, intent also includes higher-level technical judgement: which technology should be adopted, what kind of interface should exist between parts, what structure should make that interface natural to use, and what problem-solving policy the implementation should follow. You do not have to micromanage every class or line of code, but you can still record the engineering direction that must constrain the work.

The design loop closes the gap between intent and what was built

Intent-System does not ship a finished product in one pass. What it ships is a continuous stream of merged increments. The design loop is what keeps those increments aimed in the right direction — because between merges, the design thread does not take the next pass by reading code. It takes it by looking at what the implementation actually produced, on screen, and asking whether it lands.

The design thread drives the live app itself to verify the result. In practice this is Computer Use for native flows, or the Playwright CLI invoked from inside the design thread for web flows. The same thread that wrote the packet then opens the running app, compares what it sees against the packet it dispatched, the intent slice it served, and the rest of the tree, and forms its own first-hand judgment. The author of the intent confirms whether the intent was honored.

When the result drifts — a subtle UX miss, a screen interpreted differently from how the intent was written, a regression in an adjacent flow, or an integration glitch that only shows up in the running app — the design thread does not file a chat message and wait. It emits a new packet on the spot: an adjustment packet or a bug-fix packet, with the screen-level observation packed in. The implementation thread picks it up on the next /loop tick, and the system keeps moving instead of waiting for someone to translate "this feels off" into actionable work.

Two cases fall out of that check, and the preserved intent makes them easy to tell apart. If the implementation plainly contradicts the intent, it's a bug-fix packet and the implementation thread corrects it. If instead the implementation reasonably guessed at something the intent left unsaid, that isn't a bug — it's a signal to state the intent in more detail, and the adjustment packet sharpens the tree at the same time. And it isn't only the design thread that runs this check: a human periodically drives the product too, and feeds what they find back the same way. No product is assumed finished in one pass — it is meant to be exercised and fed back, on a cadence.

This is what keeps the system steerable. The unified intent tree is the static structure; the design loop — see, judge, emit a feedback packet — is what makes sure that structure tracks reality as the product grows. "Make it more like this" lands in the tree, not in someone's memory.

Intent Storming — how the unified tree gets seeded

A unified intent tree doesn't appear out of nowhere. The way we seed it is a process we call Intent Storming — the work of structuring technology and intent as the product owner. It has the same posture as Brainstorming or Event Storming, but the artifact you walk away with is an intent tree.

It runs in two shapes. As a workshop, product owners and engineers sit together (designers too, if the surface matters) and answer the questions the tree expects: why does this exist, who is it for, what does the MVP have to do, what trade-offs are we already willing to make? Or it runs solo: one person acts as the product owner while the AI — guided by intent-cli — interviews them, laying out background, options, pros and cons, and a recommendation for each open decision. Either way the output is captured directly as Purpose / User Context / Means nodes, not as a meeting note that someone has to translate into intent later.

This matters most in the earliest phase of a product, where the mission, the vision, and the MVP shape are still moving. Capturing them as canonical intent at that moment means later implementation slices inherit them automatically — drift between "what we said we wanted" and "what we built" is much harder to introduce.

After (or during) the session, the LLM does an intent review and surfaces clarification questions back to the team — "what about the empty state?", "what is the single most important success metric?", "is the Japanese audience the same as the global one?". You answer only the questions you have a strong opinion on, and accept the recommended answer for the rest. That is how the tree is fixed at exactly the granularity that matters: from a single screen element up to the broadest concept. You can start development from a small set of key points, and add stricter intent later in the spots that absolutely have to be honored.