AI 開発“vibe-coding”を1 か月試したら、怖くて手が止まった話

毎月投稿5月号(少し遅れた)。
この1ヶ月，vibe codingと言われる，AI伴走開発を試していた．この体験を経て感じたことをポエムとしてつらつら呟きたい．

結論：AI使うの怖い

僕が危惧していることは複数あって，

• これからのエンジニアの評価が適切にされない点
• 作ったプロダクトがブラックボックスになる点
• ジュニアエンジニアが生まれにくい時代になる点
  あたりがある．

まず，なぜこのような危機感を持ったかというと，件のvibe codingが発端である．僕は試しに二つのパターンで新規開発に取り組んでみた．全く知らない言語・フレームワークを使った開発と，そこそこ慣れ親しんだ言語・フレームワークを使った開発である．
動機は巷で話題のAgent(cursur agentやOpenaiのcodex，claude codeなど)を使うと開発スピードが上がり，より効率的にプロダクト開発ができるのではないかとおもたためだ．初めて使う言語・フレームワークでもプロダクト開発の大枠を知っていれば言語・フレームワークの細かい仕様はAgentが補ってくれる，慣れ親しんだ言語・フレームワークだと的確な指示を出して望むコードを瞬時に出してくれる，そのようなことを期待して臨んだ．

bolt.newとかv0を使わなかったのは，バニラなAIの限界を試してみたかったからである．開発に特化したAIでの開発もこの後実践してみる．

僕が行ったvibe codingの流れはこうだ．

1. Chat GPTに次の仕様書を書いてもらい，mark downで吐き出してもらった
   1. 要件定義書
   2. 技術仕様書
   3. DB設計書
   4. 開発方針
2. ディレクトリに仕様書を格納し，agentを起動
3. 開発方針に則ってタスク分割・issueを起票
4. issueを一つずつ消化するように指示出し・見守った

リポジトリ
https://github.com/toshikifu/libra
https://github.com/toshikifu/versus-log

雑に動くものは実装することはできたが，途中から訳がわからなくなって開発は中断してしまった．

一つずつ見ていこう．
仕様策定は，期待以上にサクサク進んだ．未知技術スタックのプロダクトでも，習得技術スタックのプロダクトでも必要そうな情報を盛り込んだ仕様書を出力してくれた．時間としては20分かからない程度で完成した．ただ，開発方針の仕様書においては一工夫必要だと感じている．Agentはこの方針を遵守するように行動するため，暗黙知がしっかり含まれていないと，想定しない行動をとる．
例えば，issueで管理しているチケットをPull Requestと紐付けて，PRがマージされたら自動closeするようにすることも言語化しないとしてくれない．issueでチケット管理する・PRでissueを解消する，と方針を立ててもPRでissueを自動closeするようにAgentは考えない．
また，よく考えていない仕様書を書いてしまうとAgentの意図しない行動に繋がる．Chat GPTはmustではなく，nice to haveの提案までしてくれる．それを全て受け入れてしまうと肥大化していき，収集がつかなくなってしまう．

チケット起票は自動でissueに積み上がっていく様子を見てるとすごいワクワクした．起票能力は非常に高いと感じた．チケットに記載することを開発方針仕様書に書いておくとそれに従って書いてくれる．しかし，起票の粒度を指示し忘れると，一つのチケットに多くの要件を詰め込んでしまう．Agentは局所的なコーディングは得意だが，全体像を意識した開発は下手なように感じる．デグレが高頻度で発生してしまう．
チケットの粒度は細かくなるよう指示することはなかなか必須のように感じた．

チケット消化の部分に関しては，まず「GitHub issueから取得しろ」と指示を出し忘れたため，毎回「ghコマンドでissueを取得して...」とつける必要があったのでこれも方針に加えるべきであった．起票をissueにすると指示しているからといって，issueを読んで実装に移ることまではしてくれなかった．ディレクトリを読んでタスクを考案する行動をとっていた．
実装自体はチケットの内容がよかったらサクサク進む．Enterを連打しているとそれっぽいコードが出来上がる．
エラーはある程度勝手に解消してくれるが，エディタで確認できないエラー(ブラウザに表示できないなど)はこちらから指摘しないと修正しない．
実装にあたって注意しておきたいポイントとしてはこまめなコミットを打つことである．Agentが実装した内容は再現性が低く，「あの時は動いたのに！」となっては手遅れになってしまうことが多々あった．そういったことを防ぐためにもこまめなコミットは心がけたいところである．
後，想定していた仕様と異なる挙動を実装中に修正した時に，仕様書の方も合わせて修正することを忘れると後々悲惨なことになる．

大きな問題として，実装を進めていくにつれて中身がブラックボックスになり，Enterを押す手に自信がなくなることである．これは特に未知の技術スタックを使った開発で顕著だった．AI利用全般に言えることだが，それらしい実装をされて，実際想定通りの動作をしていても「なぜ」動くのかを説明できない．これは致命的でプロダクトを提供する側としてあるまじき行為であると思う．
だんだんと実装内容に自信が持てなくなり，僕は開発の手が止まってしまった．
対策として，ある程度アプリの基盤を整えてからvibe codingに乗り出すべきかなーと思った．アプリのセットアップからしてもらうとなかなか苦労した印象がある

上記の体験を経て，冒頭の危惧していることに戻る．

• これからのエンジニアの評価が適切にされない点
  これはAIをバリバリ使い，すごいものを作り上げるが技術のことを理解しないエンジニアがあたかもすごいエンジニアとして評価されるということである．僕はエンジニアは作ったものに対しては説明責任を負うべきだと考えている．僕はAIをフルに使ったプロダクトエンジニアが作ったものを説明できるとは到底思えない．実際僕自身この練習で作ったものの説明ができない．
  技術に精通していて，明確な理由を持って開発したプロダクトと，AIで作ったプロダクトが同列に評価されることに僕は待ったをかけたい．

• 作ったプロダクトがブラックボックスになる点
  これは僕だけでなくさまざまな方が言っていることだが，プロダクトの中身を説明できなくなってきていると思う．
  「Chat GPTがこう出してきました」と言ってPRを作成するエンジニア増えることに危機感を覚える．

• ジュニアエンジニアが生まれにくい時代になる点
  おそらくこれからITエンジニアになる世代の方々は，AIが当たり前の中で成長していく．簡単にwebアプリケーションが作れることに感動を覚えて志すジュニアが増えると考えられるが，現場ではAIがないと動けないエンジニアは求められていない．そこに認識の不一致がおき，ジュニアには厳しい時代が訪れると感じている．

じゃあAIとどう付き合えばいいの？僕はこのように考える．
一つ，これからのエンジニアが常に意識すべきマインドとして「再現性」が重要である．
ここにおける再現性とは，同じ結果を再び得られることを指す．科学領域でいう再現性は「同じ条件や手順のもとで」，という前提がつくが，ここにおいては同じ条件・手順である必要はない．ただしAIを利用しないことが条件とする．
こうすることで，プロダクトのブラックボックスを低減することができる．フルAIで実装した機能でも，もう一度実装できるのであれば良いと思う．
合わせて，エンジニアの評価にも取り入れることで，平等にエンジニアを評価することができる．

一つ，AIに勝てる領域を一つは持つことが重要である．
いくらAIが色々提案しようが絶対自分の方が正しい，と自信を持てる領域を持っているかどうかがこれからのエンジニアの分かれ目だ．
これはエンジニアの優位性を確立するのと，AIにNOを言えるマインドセットを確立するために必要である．
AIに対してYESマンであるのは非常に危険で，判断力が低下する．AIなしでは生きられないエンジニアになってしまう．再現性とも通ずるが，AIなしでも同じ能力を発揮できる状態を維持することはこれから必須である．AIは，明らかなことを効率的に実装するためのみに用いるべきである．

vibe codingで出来上がったプロダクトとはどう向き合えばいいの？僕はこのように考える
bolt.newやdevinの威力が目立ったきた現在，AIが作ったプロダクトも世の中に溢れてきたり，PDCAを高速で回すためにvibe codingでサクッと作る風潮はこれからメジャーになると思う．僕は近い将来，インスタントアプリと個人で読んでいるが，即席のアプリケーションが大量に作られるようになると思っている．今年の夏休みの旅行用のアプリ，一家に一台家計簿アプリ，のように個人のニーズにフィットした，パーソナライズされたアプリが一般的になる．
向き合い方として考え方は様々だが，一つは品質を許容すると言う考え方があると思う．一時しか使わない，バリデーションがそこまで多くないなどの理由からも言えるし，壊れたら0から作り直せばいいとも言えるからだ．しかしそれは利用者目線の話であって，エンジニア視点では，壊れる前提のプロダクトを作ることはすべきではない．カップ麺を提供するレストランみたいになってしまう．
お客様に提供するものは堅牢なソフトウェアとし，提供するまでの過程でそのようなインスタントアプリを利用するのはどうだろう．あるいはインスタントアプリをそのまま提供するにしろ，経験豊富なエンジニアのレビューを通したものを流通させるべきだろう．