バイブコーディングしてみた
※バイブコーディングってソースコード見ていいの？とか、面倒になって自分で書いちゃった部分とかもあるので厳密にバイブコーディングかどうかはよくわかりませんが、とりあえずここではバイブコーディングと呼びます。
バイブコーディングで、極力自分はコードを書かないという縛りで何か作ってみたいと思い、gemを作ってみました。
ruby-openaiみたいなのgeminiでも欲しいなーと思っていたのと、既存のgemがメンテナンスされてない感じだったのでgeminiのAPI叩くgemを題材にしました。
できたものがこちら。
rira100000000/ruby-gemini-api
この記事では実際にどんな感じで進めたかの紹介と、やってみた感想を書いていきます。(gemの説明はREADME読んでください)
バイブコーディングの手法としては割と回りくどい気がするので、そんなやり方もあるんだなくらいの感覚で読んでいただければと思います。
進め方
私はAnthropicのProプランに加入していたのでClaude 3.7 Sonnetを使用しています。
なので基本的にはClaudeのプロジェクトを使いました。
プロジェクトにはプロジェクトナレッジというものがあり、GitHubやGoogle Driveのファイルやその場で書いたテキストをコンテキストに含めることができます。
機能を追加する際の進め方としては、
- 追加する機能に関連するファイルをGitHubから読み込む
- GeminiのAPIリファレンスをまるまるコピペしてプロジェクトナレッジにテキストとして追加
- 実現したいことや考慮する点などをあげてプロンプトとして渡し、新しいチャットを開始
- 出力されたファイルをチェックして、問題なければVSCodeにコピペする。気になる点があれば再度指示する
という感じです。
色々試しながら進めたのですが、一番しっくり来たのがこのやりかた。
というかお金がかからなくてレート制限に引っかかりにくいやり方という話なので、リソースがあるならClineじゃぶじゃぶ使いたいです。
Claude Desktopと Claude CodeをMCPで繋ぐ手法も試してみましたが、レート制限に引っかかりまくるので微妙でした。
最初の指示を出していきなりがんがんコードを書かれると結構自分のイメージと離れたものができたりするので、プロンプトに「まずはコードを書かずに設計を行ってください。許可するまでコードを書かないでください」という文言を加えておくと無駄な時間が発生しづらい。
多分設計の方針とかフォーマットみたいなものが確立している人はそういうことを伝えられればさらにうまくいくと思います。
設計に注文を付けたりつけなかったりして、方針が定まったら、実際にコードを書いてもらいます。
この時も「実装したファイルを省略せず、完全な形でアーティファクトとして出力してください」という文言を加えると、画面の右側にアーティファクトというファイルっぽいものが出てくるので便利。
「省略せず、完全な形で」がないとファイルのあちこちを修正する指示書みたいなものが出力されたりして、「主人たる私がこれをあちこちにコピペするんですか？」という状況になってだるい。
全体を出力するのでトークン消費量は増えるだろうけど、ファイル全体をバーンと置き換えれば作業が終わるので時間をトークンで買う感覚で頼んでしまいます。
ある程度形になったら一度GitHubにPushして再同期し、新しいチャットで次のタスクに取り掛かるという感じで回してました。
感想
やってみた感想としては、「自分で書くより10倍~20倍くらい速そう」という感じ。
APIリファレンス読む時間、実装方法調べる時間、タイピングする時間などは人間と比較になりません。
一発で完全に動作するコードが出てくるわけじゃないので、「だったら自分で書いた方が早くない？」という意見もあるかもしれませんが、「細い裏道も通れるから俺は走るよ」と言って自動車と勝負するようなもので、長距離走では敵わないんじゃないかなと思います。
自分が詳しく知ってるプロダクトのコードで、修正箇所もぱっと思いつく。とかなら人間が書いた方が早いと思います。
仕様を知らないAPIを叩くためのgemを作るという今回の状況では有効な手法だと感じました。
「ここは思ってる実装の方針と違うんだよなぁ」と感じることもそれなりにありましたが、「ある程度目的地の近くまで車で移動して残りは徒歩」みたいな戦略も取れるので、AIは一切使わないとか全部AIにやらせる、ではなくその時々で最良の選択肢を取れるのがベストなんだと思います。
READMEもデモ用スクリプトもサクッと作ってくれるし、使い方を理解しておけば確実にメリットはあると思います。
ただ今回の私のようなやり方は巨大なRailsアプリみたいなものを相手にすると、どのファイルをプロジェクトナレッジに加えるべきかの判断が難しいので使えなそうです。
ファイルごとの繋がりを読み解きながら進められるClineやCursorを使うべきなんだろうなぁという感じですが、あっちはあっちでファイル探しで迷子になるという問題もあるらしいので、やはり人間が介入する必要はあるんでしょう。
それにしてもこのケチケチした使い方で十分速いのだからAIエージェント使ったらさぞ便利だろうと思いました。
今後どうなるんでしょうね
Geminiが100万トークン、Llamaが1000万トークン(性能微妙らしいけど)扱えるということは、それなりの規模のコードであればまるまるコンテキストに含められるわけです。
加えてモデル自体が日々賢くなり、扱いやすくなり、こちらの言いたいことを汲み取ってくれるようになっていきます。
いずれはポン出しのコードで問題なく動くようになったり、非エンジニアの漠然としたプロンプトでタスクが完了できるようになるでしょう。
その時必要なエンジニアやIT企業ってどんな存在なのか、考えていかないとなぁと感じました。
「今後どうなるんでしょうね」って書いたけど、もうだいたいどうなるのか予想はついてるのだからきっちり方針立てて進めてかないといけない、と思う次第です。
