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.
Intent-Driven Development · open source
In the AI era, you ship by sharing intent with AI — not by writing more detailed specs. Intent-Driven Development.
Our open-source CLI, intent-cli, puts this into practice with the coding agents you already use — Claude Code, Codex, Cursor, Copilot, OpenCode. Your intent stays in git, the workflow sends every change to a reviewer that didn't write it, and you keep the decisions.
01Intent stays visible02herdr coordinates03Review closes the loop
Explore the orchestration Works withClaude Code · Codex · Cursor · Copilot · OpenCode
Start with1 thread + subagents · desktop app, CLI, or Orca
Open sourceintent-cli v0.32.0 · Apache-2.0 · no server
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.
Product
What intent-cli does about it
intent-cli doesn't replace your coding agent. Your agent asks it what to do next; it answers with concrete steps and records what happened in git and GitHub.
The why outlives the chat.
Intent is kept as small files in git, and each GitHub issue is published from it. A new session — or a new teammate — starts from the recorded intent, not from someone's chat history.
A reviewer that didn't write the code.
Working alone, every review goes to a fresh subagent. In a team, the review seat checks the PR against intent. You can also require a second runtime — say, Codex reviewing what Claude wrote — before approval.
No new commands to memorize.
Tell your agent to ask intent-cli. It never launches an agent; it answers with the next step, validates the result, and makes only bounded, explicit changes to GitHub and its own metadata.
One thread runs the whole loop.
Run one conversation — in the Claude desktop app, Claude Code, or an Orca Run — and it starts its own reviewer subagents. Add seats only when you need several units in flight at once.
We build intent-cli with intent-cli: as of 2026-09-22, 643 of the 891 merged pull requests in its repository are units it cut and tracked, and each PR keeps its review records in public. See an example →
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 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
One thread, fresh reviewers.
One conversation runs every step and starts a new subagent for each review. When you need several units in flight, give each role its own seat and watch the team in herdr.
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 Claude Code, Codex, or Cursor daily on a real codebase — start with one thread and an independent review subagent.
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 throwaway prototypes, Intent-System is overkill. If the code has to live on, even a single developer gets something from it.