コンセプト

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をドキュメントに忍び込ませないことである。

→ クイックスタートガイド

English 한국어 中文