1年半とは景色が違うけどな！
AI駆動開発の現在地
ループエンジニアリングとか言われてますね
これを実現するためには /develop https://〜(タスクのURL) のような形で実装完了まで持っていけるのが前提条件となる
「でもタスクに詳細が記載されている必要があるんでしょう？」
3割正解
もはや目的と背景があれば良いですね
さすがに「何かいい感じのものを作って」でいい感じのものが出来ることはなかったけれど、これまでAI駆動開発としっかり向き合ってきた人が整備してきたハーネスがあると詳細な指示がなくてもやりたいことが実現できる土壌ができたんですよね
「これってvibe codingじゃね？」
vibe coding から現在地まで
ここで1年半くらい前のvibe codingに立ち返ってみると、エージェントが直接ファイルの読み書きが出来るようになり、チャットでやりたいことを指示して勝手に実装をすすめてもらうというものでした
しかし、残念ながら一発で完成度の高い実装をするのが難しかった
そしてリテイクを繰り返していくうちに破綻しはじめる
この反省を元に仕様書駆動開発が脚光を浴びるようになりました
ちなみに昨今では「仕様駆動開発」という単語の方が使われているように思うが、その本質はドキュメントベースにあるので「仕様書駆動開発」であるべきだと思う
ここで仕様書駆動開発がドキュメントベースであることに気付いていた人は、おそらく自前で仕様書駆動開発のコマンドを整備できていたのではないでしょうか
この間、仕様書駆動開発のフレームワークとしてSpecKitなどが猛威をふるいましたが、おそらくここでサードパーティーツールの整備を頑張っちゃった人は今のループエンジニアリングとかについていけなくなっちゃってるんじゃないかな……
さて、サードパーティーのフレームワークの登場もある中でエージェントツールも「いきなり実装するな、planを作れ」というメッセージを出します
(直接そう言ったかどうかではなく、planモードが出来たということです)
さすがにAIエージェントを開発してるところは仕様書駆動開発が正しいのではなく、ドキュメントベースが正しいということを理解していますね
こうして仕様書駆動開発を起点としながらコンテキストの整備を行っていたのがいわゆるコンテキストエンジニアリングと呼ばれていた時代
並行して受け入れ条件を定義することの重要性も認識されていった
ここも、結局のところドキュメントに記載しておき、機械的に突合するというところに落ち着いていきました
ハーネスエンジニアリングはそれらの整備に対して名前がついただけで、目新しい概念ではなかったですよね
Claude Codeに/goalコマンドもやってきて、受け入れ条件の定義も広く認識されるようになっていった
結局のところ、サードパーティーツールに躍らされず、しっかりAIと向き合って環境を整備していたらClaude Codeの公式コマンドすら不要なんですよね
ハーネスを上手く作れていて、単一コマンドによって、途中で止めずに実装を走り切れる状態が出来ていることがループエンジニアリングの前提となっているようなところがあるので、ここが出来てない方はまず「単一コマンドで実装を走り切る」ことを目指してほしいですね
今の時代、目指すところが見えているのでわざわざコンテキストの整備を試行錯誤したりする必要はなく、目指すべき操作を作ってから足りない部分を埋めていくのが良いと思います
正直なところ、今日からClaude Codeを始めたとしても、まだ2〜3ヶ月でこの辺りまでは到達できそうだと感じています
それでは良いAI駆動開発を