私は仕様駆動型のワークフローを試してきましたが、思いがけず予期しなかったことを発見しました：エージェントが自分の作業を見直し、改善し始めたのです。
私が発見したことは、エージェント型AIの観点から見て新しいものではありません。これはエージェント型AIのポイントだが、私のテストでそれを偶然見つけた経緯はそれでも興味深いものでした。
基本的なアイデア
私はspec.prompt.mdというファイルを作成しました。このプロンプトはチケット番号と技術仕様の貼り付け内容を受け付けます。次に次のようなコマンドを実行します:
/spec <ticket-number> <pasted-contents>
もともと、私が毎回/specを実行すると、すべてを上書きして最初から始めていました。それは機能しましたが、パス間で反復したり変更を比較したりすることはできませんでした。
そこで2つのモードを追加しました：
-o = 上書き
-i = 反復
反復モデル
私が実行すると：
/spec -i 1234 <contents>
次のようなフォルダー構造を作成します：
/specs/1234/
p01/
spec.md
plan.md
implementation.md
files...
p02/
spec.md
plan.md
implementation.md
files...
p03/
...
元々の意図は、p01 と p02 の間で比較を提供し、仕様の変更が正しく実装されたかどうかを確認することでしたが、予期せぬことが起こりました。
-i の最初のテストでは、仕様を全く変更していませんでした。私は同じ仕様をもう一度実行しただけです：
/spec -i 1234 <original contents>
Pass 1 と Pass 2 を比較できるように、すべてを再生成することを期待していました。代わりに、Pass 2 はさらに賢く何かをしました。
Pass 2 を見直すと、元のビルドスクリプトを見つけられず、作業の大半が欠けていました。なぜ1つのファイルしか見つからなかったのか混乱しました。
そして、閃きました。以前のパスを見直して、私が提供した複製された仕様のギャップを特定し、ほとんど正しいと判断し、元のパスを洗練させたのです。
それが起こったとき、これは単なるプロンプトに留まらず、エージェントのように見え始めました。私はすべてを書き直すようには指示していません。間違っているところだけを直すようには指示していません。以前の実装を見直すようには指示していません。それは自らそうすることを選んだのです。
その自己改良プロセスは、私自身のプロセスを再考させました。
プロセス
現在、次のプロンプトを持っています：
spec.prompt.mdspec-implement.prompt.mdspec-testing.prompt.md- using
backend-engineerエージェントを使用
現在、前のステップが完了した後、私は手動で各ステップを実行しています。ただし、長期的な目標は、エージェントがワークフローを理解し、手順を自ら実行できるようにすることです。
パスワークフロー
パス1 — 仕様 → 計画 → 実装
/spec 1234 <contents from Jira>
エージェントは:
- チケットを読む
- 仕様を書き出す
- 計画を作成する
- コードを実装する
- すべてを
p01に保存する
パス2 — 自己改良
/spec -i 1234
エージェントは:
- 仕様を再読する
- パス1を再検討する
- ギャップを修正する
- 実装を改善する
- 不足しているテストを追加する
- 必要に応じてリファクタリングする
-
p02に保存する
これは自己改良ループとなります：
Implement → Review → Refine → Review → Refine
エージェントは実装が仕様と一致すると信じるまで反復を続けます。
パス3 — エンジニアによる仕様の更新
見直しの後、エンジニアは以下に気づくかもしれません:
- 何かが不明確だった
- 要件が変更された
- エッジケースが見落とされた
- 命名を改善すべき
- ロジックは別の方法で処理すべき
エンジニアは仕様を更新し、次のコマンドを実行します：
/spec -u 1234 <updated contents>
今度はエージェント:
- 元の仕様と更新後の仕様を比較する
- p01 と p02、p03 などを比較する
- 仕様で何が変わったか、そしてそれがコードにどのように影響するかを決定する
- 差分のみを実装し、すべてを実装するわけではない。
- 新しいパスを作成する
これは反復的な仕様駆動開発となります。
最終フェーズ — テスト手順
エンジニアが実装が検証の準備ができたと考えたとき：
/spec-testing 1234
エージェントはその後:
- 最新のパスを確認する
- 変更されたすべてのファイルを特定する
- 変更を検証するテストシナリオを提供する
その時点で、エンジニアはテストを行い、すべてを最初から書くわけではありません。
予期せぬ出来事を予見することと「ただ泳ぎ続ける」
この実験の興味深い点は、エージェントがコードを書いたことではありませんでした。パスごとに自分の作業を見直し、洗練させ、改善し始めたことでした—開発者が行うのと同じ方法で。
私はこのエージェントやこのワークフローを作成しようとしたわけではありません。より良いプロンプトを書くことを目指しました。そこから、もう少しさせたい、そしてさらにもう少しさせたいと思うようになりました。どこかの時点で、プロンプトはプロセスへと変わりました。
これは単なるプロンプトエンジニアリングだけではありません。
それはプロセスエンジニアリングです。
