コンセプト
Intent Engineeringがなぜ存在するのか、何を拒否するのか、そしてIntentが希少な資源になったとき何が変わるのか。
ボトルネックは移動した
ソフトウェアエンジニアリングは数十年間、一つの制約に最適化されてきた:人間が書くコードは高くつく。パターン、コードレビュー、CI/CD、マイクロサービス、アジャイル:すべて希少なコードを管理するシステムである。
その制約は崩壊した。AIエージェントは今やマシンスピードでコードを生成し、レビューし、テストし、デプロイできる。
新しいボトルネックはIntentである。コードが安価になったとき、希少な資源は何を作るか、なぜそれが重要か、何を排除すべきかを決めることになった。それなしでは、AIは洗練された無駄を生産する。
Intent Engineeringはこのシフトを受け入れる:Intent以外のすべては選択である。スタック、アーキテクチャ、スケジュール。人間の仕事はWhy、What、Not、そしてLearningsである。残りはAIが担う。
Intent Engineeringでないもの
それはプロンプトエンジニアリングではない:プロンプトエンジニアリングは一つの会話を調整するが、Intent Engineeringはすべての会話が継承する永続的なドキュメントを定義する。
それは設計ドキュメントではない:設計ドキュメントはHowを規定するが、Intent Documentはそれを拒否する。スタック、アーキテクチャ、スケジュールは実装の選択だからである。
それはPRDではない:PRDは包括的で静的であろうとするが、Intent Documentは最小限で、探索を通じて進化し、killedにすることもできる。
それはフレームワークやツールではない:マークダウンファイルと規律である。
3つのレイヤー
Intent Documentはちょうど3つのレイヤーを持つ。人間がここで所有するものはWhy、What、Notの3つだけだからである。それ以外はすべて実装の選択である。
Why — これが存在する理由
Whyは価値についての主張である:誰の痛みが重要か、どの結果が成功と見なされるか、何が考えを変えさせるか。seedとexploringでは賭けであり、clarifiedでは確約である。
What — 作るもの
Whatは約束の表面積である:機能、ユーザーフロー、エッジケース。AIが作業を導出できるほど具体的でなければならないが、Howについては沈黙する。「ユーザーはレポートをPDFとしてエクスポートできる」はここに属するが、「puppeteerを使え」は属さない。
Not — 越えてはならない境界
Notは真剣さが現れる場所である:セキュリティ制約、スコープの制限、品質基準、禁止パターン。Notがなければ、AIはあなたが書かなかった前提に対して最適化する。
Learnings — 進化のエンジン
明確さは通常遅れてやってくる。アイデアはseedとして始まる:曖昧で、脆く、興味深い形で間違っている。前に進む道は探索である。
Learningsは試したこと、現実が語ったこと、何が変わったかのタイムスタンプ付き記録である。
人間にとって: 修正主義的歴史を消滅させる。プロジェクトがピボットしたとき、理由は記憶の中ではなくLearningsの中にある。
AIにとって: コードでは決して運べないコンテキストを運ぶ。エージェントは現在の形だけでなく、それを生み出した道筋を見る。
ライフサイクル
Intentは4つの状態を遷移する:
| 状態 | 説明 | すべきこと |
|---|---|---|
| seed | アイデアのみ。Whyは推測、WhatとNotは空または曖昧。 | 仮説を書く。最初のテストを実行する。 |
| exploring | プロトタイプ、リサーチ、インタビューを通じて仮説に圧力をかけている。 | 実験を実行する。Learningsを記録する。必要に応じてWhy/What/Notを書き直す。 |
| clarified | Why、What、Notが明示的である。不確実性マーカーがない。 | AIに引き渡す。構築させる。 |
| killed | 証拠が構築すべきでないと示している、または既存のソリューションが勝っている。 | 理由を記録する。止める。これは良い結果である。 |
最も難しい遷移はどの状態からでも → killedである。プロジェクトを始めることは安い。悪いプロジェクトを止めることは判断力である。
既存の概念との関係
| 概念 | スコープ | Intent Engineeringとの関係 |
|---|---|---|
| Context Engineering | タスク単位、一時的 | Intent Documentはすべてのタスクの上位にある永続的コンテキストである。 |
| Harness Engineering | ツールと環境のセットアップ | Notレイヤーはハーネスルールにコンパイルされるべきである:CLAUDE.md、リンター、CI。 |
| Spec-driven Development | 機能仕様 | 仕様はWhatから導出される。人間が手書きするのをやめる。 |
| Vibe Coding | コード生成 | バイブコーディングはIntentが鋭いときにのみ効果を発揮する。 |
自動化パイプライン
成熟したパイプラインでは、人間が触れるのは2点だけ:最上流のIntentと最下流の判断である。
[Intent Document] ← Human writes and maintains
↓
[Spec Generation] ← AI derives task list from Why/What/Not
↓
[Implementation] ← AI agents write code in parallel
↓
[Verification] ← AI cross-reviews, tests, lints
↓
[Deployment] ← CI/CD automates release
↓
[Feedback] ← User data flows back
↓
[Learn & Decide] ← Human evaluates, updates intent or kills
Intentとフィードバックの間のすべては今や自動化可能である。技術スタック、アーキテクチャ、タスク分解、検証フロー、デプロイ頻度:すべて選択である。還元不可能な人間の仕事はWhy、What、Not、そしてLearningsである。
なぜ機能するのか
制約が明確さを生む。 Why/What/Notは人々が隠れる場所を排除する:ロードマップ劇場、アーキテクチャのコスプレ、偽りの精密さ。Intentを明確に述べられないなら、構築する準備ができていない。
AIはあなたよりHowが得意である。 AIはどの個人のエンジニアよりも広い実装の記憶を持っている。Howを過剰に指定することは、ソリューションをあなたの局所最適に制限する。
終了は生産的である。 文書化されたkilledは無駄ではない。それは不確実性の返済である。死んだプロジェクトのLearningsは、出荷されたプロジェクトのコードより長く生き残ることが多い。
Intentの精度はスケールする。 Whyの一つの鋭い文がタスク生成、レビュー、テスト、デプロイに伝播する。曖昧なIntentは曖昧さを増幅させ、鋭いIntentは一貫性を増幅させる。
はじめ方
プロジェクトのルートに INTENT.md を作成し、Why、What、Not、Learningsだけを書く。証拠がそれを取り除くまで、不確実性を (?) でマークする。
メカニクスはクイックスタートガイドにある。規律はHowをドキュメントに忍び込ませないことである。