きっかけ 見出しへのリンク
長年使っていたDropboxを解約して、Google Driveに移行することにした。ファイル数はそれなりに多く、手動での移行は現実的ではない。そこで、この移行ツールをバイブコーディングで作ってみることにした。
最初はCoworkで試した 見出しへのリンク
まず試したのはAnthropicのCoworkだった。しかし、思った以上に時間がかかり、しかも思い通りに動かなかった。エージェントが自律的に動きすぎて、自分のコントロールが及びにくいと感じた。
Piエージェントで作り直した 見出しへのリンク
気を取り直して、Piエージェントで作り直すことにした。DropboxとGoogle DriveのAPIを使ったファイル転送ツールで、最初の80〜90%はスムーズに進んだ。コードはどんどん生成され、基本的な機能はあっという間にできあがった。しかし、残りの10〜20%が思った以上に大変だった。
Human in the loopの3つのパターン 見出しへのリンク
バイブコーディングを通じて、人間が介入すべき場面が3つのパターンで現れることに気づいた。
1. AIが解決できない問題は自分で実装する
/foo/bar/foo1/foo2 というパスが /foo2 として移行される問題が発生した。ディレクトリ構造が潰れてしまうバグだ。AIに何度修正を依頼しても、うまくいかない。最終的には自分でコードを読んで、問題の原因を特定し、自分で修正した。AIに任せ続けても解決しないと判断できたのは、自分がコードを理解していたからだと思う。
2. AIのコードの問題を発見し、AIに再実装させる
深い階層のディレクトリをtraversalする際、AIが毎回APIを呼び出すコードを書いていた。明らかに非効率で、レート制限にも引っかかりかねない。自分でコードを読んでこの問題に気づき、ファイルツリーをメモリに乗せるよう再実装を依頼した。問題の発見は自分、実装はAIという役割分担だ。
3. 問題の原因が自分の要件定義にある
ログの出力形式が思っていたものと違った。最初はAIのコードが悪いと思ったが、よく考えると自分がログの仕様をきちんと伝えていなかっただけだった。AIはJSONで出力していたが、JSONLの方が都合がよかった。これは要件定義の問題であって、AIの問題ではなかった。
Zedのブログと一致した 見出しへのリンク
この体験を振り返っていたところ、Zedのブログ記事「On Programming with Agents」に出会った。そこには3つのルールが書かれていた。
1. Only use agents for tasks you already know how to do — 自分が知っているタスクにだけエージェントを使え
2. Stay involved in the agent loop — エージェントのループに関与し続けろ
3. Review, review, review — レビュー、レビュー、レビュー
まさに自分の体験そのものだった。pathの問題を自分で解決できたのも、コードが読めたから。API呼び出しの非効率に気づけたのも、関与し続けていたから。ログの問題も、レビューして初めて気づいた。
Zedの記事にはこんな一文がある。「LLMs automate typing, not thinking.（LLMはタイピングを自動化するのであって、思考を自動化するのではない）」。バイブコーディングの本質を突いた言葉だと思う。
Agent in the loop 見出しへのリンク
「Human in the loop」とは逆の視点も考えてみたい。それが「Agent in the loop」という概念だ。
これまでの仕事は人間同士のやり取りで完結していた。会議、メール、レビュー、ブレインストーミング。しかしその中には、誰もが答えを持っていない瞬間がある。行き詰まったとき、アイデアが出ないとき、そんな場面にエージェントが第三者として入り込み、新しい視点やアイデアを提供してくれる。
このブログ記事の執筆もそうだった。普段は一人で書いていた作業の中にAIが入り込んで、構成を整理し、文章にまとめる手助けをしてくれた。まさに「Agent in the loop」の体験だ。
人間とエージェントの関与度はスペクトラムとして捉えることができる。片方の端は人間だけで完結している仕事、もう片方の端はエージェントが自律的に動く世界だ。現時点では、多くの仕事はまだスペクトラムの人間側にある。
重要なのは、そのスペクトラムのどこにエージェントを配置するかを意識的に設計することだ。どの部分にエージェントを入れるか、どこは人間が担うかを考えることが、これからの仕事のあり方を決めていく。そしてその設計ができるのは、仕事を深く理解している人間だけだ。スペクトラムの設計自体が、まさにHuman in the loopの仕事なのかもしれない。
まとめ 見出しへのリンク
バイブコーディングは確かに強力だ。80〜90%までは驚くほど速く進む。しかし残りの10〜20%、そしてコードの品質を担保するためには、人間の判断・気づき・要件定義が不可欠だ。
Human in the loopとは、AIに丸投げするのではなく、人間がしっかりとループに関与し続けることだ。ツールは変わっても、ソフトウェアを作るクラフトマンシップは変わらない。
ちなみに、この記事自体もバイブブログで書いた。構成を考え、エピソードを話し、文章にまとめる作業をAIと一緒に行った。ここでもやはり、Human in the loopは欠かせなかった。