はじめに
コーディングエージェントの性能向上に伴って、ハーネスを整備し、開発プロセスをAI駆動にしていくのが流行っている。
Xを見ていても、「AIを6時間連続で動かした」とか、「自分はN並列で回している」とか、そんな話がよく流れてくる。ときには、どれだけプロダクトを前に進めたかより、どれだけ長く、多くAIを回したかの見栄の張り合いに見えることすらある。
最近は、エージェント向けの指示書やスキル、スクリプトの整備に時間を使うことも増えた。コードもテストもAIがやる。人間はAIの育成に時間を使う。
この流れ自体は自然だ。AIに安定して働いてもらうには、足場が要る。
ただ、ここで一つ違和感がある。
私たちはプロダクトを作っているのか。
それとも、AIをうまく働かせるための環境を作っているのか。
ハーネス整備は必要だ
まず前提として、ハーネス整備そのものを否定したいわけではない。
AIは放っておけば、コードベースの作法を外す。関係のないファイルを触る。テストをサボる。似たコードを量産する。だから、指示書を整え、チェックを足し、ガードレールを置く必要がある。
ここに投資する価値はある。最低限の足場がないと、AIは安定しない。
ただし、主戦場ではない
では、ハーネスをどこまでも作り込めばよいのか。
話はそこまで単純ではない。
ここで重要なのは、ハーネス整備の多くは、プロダクトを直接良くする仕事ではないということだ。
もちろん、間接的には効く。
ただし、それ自体が価値の中心ではない。
AIのアラを探して、失敗パターンを一つずつ潰していく。まだ苦手なところを補うために、スクリプトやルールを追加していく。
その作業をやりすぎると、人間の時間はAIの監督に吸われる。
気づけば、プロダクトのための開発ではなく、AIをうまく働かせるための開発が主戦場になってしまう。
三ヶ月後には消える苦労もある
さらにやっかいなのは、いま苦労して埋めている穴の一部は、三ヶ月後にはモデルの改善で自然に埋まっている可能性があることだ。
プロンプトをねじる。補助スクリプトを足す。ワークフローを複雑にする。
その努力が無意味だと言いたいわけではない。
ただ、変化の速い対象に対して、局所最適の仕組みを自前で作り込みすぎるのは危うい。
エンジニアは昔から、3時間の作業を5分に短縮するスクリプトを書くために4時間かける生き物だ。
それ自体は悪くない。むしろ文化としては好きだ。
しかし、相手が数ヶ月単位で急激に賢くなるAIなら、同じ感覚で最適化しすぎないほうがよい。
先人が築いたベストプラクティスを、三ヶ月遅れくらいで摘んでいく。
そのくらいの距離感が、ちょうどよい場面も多い。
人間に残るのは、プロダクトを見る仕事だ
AIがコードを書く。
AIがテストを回す。
AIが修正案を出す。
では、その間に人間は何をするべきか。
差分を眺めてApproveボタンを押すだけ、ではないはずだ。
人間が向き合うべきなのは、むしろプロダクトそのものだと思う。
- アーキテクチャを見て、どこに無理が出始めているかを考える
- ログやメトリクスを見て、異常の芽やユーザーのつまずきを探す
- 画面を触って、UXの違和感や不要な複雑さを見つける
- 仕様の曖昧さを潰し、何を良しとするかを決める
これらは、差分だけ見ても判断しにくい。
時間軸と文脈が必要だからだ。
AIは局所的な正しさには強い。
ただし、どこを壊してよいか、何を捨てて作り直すべきか、何をプロダクトとして優先するかは、人間が判断するしかない。
価値はAIの育成から判断へ移る
AIが強くなるほど、人間の役割は「全部手を動かす人」から変わる。
ただし、役割が消えるわけではない。
重心が移るのだと思う。
コードを書くことそのものよりも、
- どの問題を解くべきか
- どの設計を採るべきか
- どのリスクを許容し、どこで止めるか
こうした判断の価値が上がる。
AIをうまく働かせることは大事だ。
しかし、それは目的ではない。プロダクトを良くするための手段だ。
ハーネスを磨くこと自体が目的になった瞬間、順番が逆になる。
まとめ
この記事では、コーディングエージェント時代にハーネス整備へ時間が偏りすぎることへの違和感と、人間が向き合うべき仕事について書いた。
- ハーネス整備は必要だが、主戦場ではない
- 三ヶ月後にモデル改善で消える苦労へ、最適化しすぎるべきではない
- AIが手を動かしている間、人間はプロダクトを観察し、判断する側に寄るべきだ
AIにコードを書かせることは、もう難しくない。
難しいのは、その時間で人間がどこを見るべきかを見失わないことだ。