バイブコーディングは意図を失います。
Cursor や Claude Code での良いセッションは動くコードを生むが、六週間後にはその判断の理由を誰も覚えていません。
Intent-Driven Development · オープンソース
AI 時代は、詳細な仕様ではなく意図を伝えて AI と協働する ── Intent-Driven Development (意図駆動開発)。
AI コーディングエージェントを本番運用するスタートアップのために。プロンプトではなく意図そのものを真実の源として扱う、語彙と運用システム。
01意図を保持02herdr が連携03レビューで閉じる
オーケストレーションを見る レイヤIDD — SDD の上流
真実の源Intent ツリー、プロンプトではありません
ステータスv0.22.0 リリース済み · herdr-only は推奨されるプレビュー外の経路
コンセプト01 02 03
現在の AI コーディングが抱える問題
仕様書は陳腐化します。
実装前に書かれた仕様書は最初の PR がマージされた瞬間から乖離します。二週間後、その仕様書はもう存在しないシステムを語っています。
共有された意図がなければ、エージェントの判断はぶれていきます。
自律エージェントを一時間動かせば目の前の問題を解きます。一週間動かせば別の問題を解いています。
コンセプト
Intent-Driven Development とは何か ── ひとことで
IDD は真実の源をコードの一層上に移す。「なぜ」と「何を達成したいか」は人間がキュレーションする永続的なアーティファクトとして生き、「どう実装するか」は下流で人間 / エージェント / AI のいずれかが扱います。
AI 支援の開発において、最もレバレッジが効くスキルは「良い Issue を書くこと」です。構造化された意図ツリーがあるからこそ、それが現実になります。各 Issue は関連する意図（アーキテクチャ・契約・UI パターン）を自動的に受け継ぐので、実装は迷いなく進み、レビューは個人の好みではなく意図そのものとの差分で行えます。
そして、ひと回しで完成品ができることを前提にしません。作られたものは、保存された意図と照らして ── 設計スレッドと、実際に動かす人間の両方が ── チェックし、ズレは修正パケットとして戻ってきます。プロダクトオーナー・デザイナー・エンジニアが最初に抱いていた意図が意図として残っているので、「思った通りに作れたか」は、いつでも答えられる問いであり続けます。
重なり方
intent(なぜ・何を)↓
spec(どう作るか)↓
code(ラストマイル)IDD と SDD は競合しません。積み重なります。
プロダクト · INTENT-SYSTEM
私たちは、意図を中心に据えます。
Intent-System は、Tree-Structured Operational IDD の具体的な実装です。spec-as-source の立場が仕様を中心に据えるのに対して、私たちは意図を中心に据えます。これを Intent-as-source と呼んでいます。
01
意図はリストではなくツリーで。
Purpose / User Context / Means.
02
プロダクト体験と技術の意図を一箇所に。
UX とアーキテクチャが同じツリーを共有するので、同じ変更が両側から同時に制約される。
03
人間が決め、エージェントが実装。
スライスごとに割り当て、あなたがレビュー。
04
エージェントを 1 つの監督下のチームとして動かす。
リリース済み intent-cli v0.22.0 では、コーディングエージェントまたは運用担当者が出力されたコマンドを使って herdr-only チームをセットアップし、検証できます。承認したコマンドを実行した後も設計は人間との対話側に残せ、ワーカーの役割は herdr で見える状態になります。
実例
誰のためのものか
01
スタートアップの技術リード
AI コーディングを本番運用していて漂流の問題を感じています。
02
個人開発者
Cursor / Claude Code を毎日使い、意図に構造が必要だと感じています。
03
リサーチャー・執筆者
IDD/SDD の全体像を公平に整理したいと考えています。
04
エンタープライズの技術戦略担当
IDD がガバナンスに適合するか評価したいと考えています。
使い捨てスクリプトや個人プロトタイプを書いているなら、Intent-System はオーバーキル。すべてのページでそう書いています。