Vibe coding loses intent.
A great session in Cursor or Claude Code produces working code, but six weeks later, nobody remembers why a particular trade-off was made.
A concept site · v0.1
In the AI era, you ship by sharing intent with AI — not by writing more detailed specs. Intent-Driven Development.
For startup teams running AI coding agents in production: a vocabulary and an operational system that turns intent — not prompts — into the source of truth.
LayerIDD — upstream of SDD
Source of truthIntent tree, not prompts
StatusOpen source on GitHub · Apache-2.0
Concept01 02 03
The problem with AI coding today
Spec-driven docs go stale.
A spec written before implementation drifts the moment the first PR lands. Two weeks later, the spec describes a system that no longer exists.
Without shared intent, agents drift.
Run an autonomous agent for an hour and it solves the problem in front of it. Run it for a week and it solves a different problem.
Concept
Intent-Driven Development, in one paragraph
IDD moves the source of truth one layer above code. The why and what to achieve live as durable artifacts that humans curate; the how is handled downstream by humans, agents, or AI as fits the slice.
In modern AI-assisted coding, writing a great issue is the single highest-leverage skill — and that is exactly what a structured intent tree makes possible. Each issue inherits the relevant slice of intent (architecture, contracts, UI patterns) so implementation is straightforward and review compares the PR to intent, not to taste.
It also doesn't assume a finished product in one pass. What gets built is checked against the preserved intent — by the design thread and by a human actually running it — and anything off comes back as a fix packet. Because the original intent of the product owner, designer, and engineer is kept as intent, "did we build what we meant?" stays an answerable question.
How it stacks
intent(why & what)↓
spec(how to build)↓
code(the last mile)IDD and SDD are not competing — they stack.
Proposal
Our two proposals to the IDD conversation
01 · Terminology
From "Harness" to "Compass"
Last year, the right metaphor for AI coding was the harness — restrain output. With Opus 4.5-class models, the right metaphor is the Intent Compass: give direction, don't restrict movement.
Read →02 · BranchingGit-AI-Flow
Git-Flow optimized for human-paced releases. GitHub-Flow for continuous human review. Git-AI-Flow introduces a buffer between AI velocity and human oversight.
Read →Product · INTENT-SYSTEM
We put intent at the center.
Intent-System is our concrete implementation of Tree-Structured Operational IDD. Where the spec-as-source camp puts spec at the center, we put intent there. We call it Intent-as-source.
01
Intents in a tree, not a list.
Purpose / User Context / Means.
02
Product-experience and tech intent in one place.
UX and architecture share the same tree, so the same change is constrained from both sides at once.
03
Humans decide, agents implement.
Per-slice assignment, you review.
04
It already runs.
Claude on /loop 5m drives implementation and review in separate cwds — ~10 packets per 3 hours on an active domain. Codex runs cloud automation alongside.
Proof
Who this is for
01
Startup tech leads (CTOs, VPoEs)
Running AI coding agents in production and feeling the drift problem.
02
Individual developers
Using Cursor / Claude Code daily who want a structure for their intent.
03
Researchers and writers
Wanting a fair survey of the IDD/SDD landscape.
04
Enterprise tech strategists
Evaluating whether IDD fits their governance model.
If you're writing one-off scripts or solo prototypes, Intent-System is overkill. We say so on every page.