[わ]

Vibe Codingしてみた

おはようございます。waturaです。この前iOSアプリ開発もCursorとかつかいたいよねーという記事を書きました。

今回はその時に契約したWindSurfを使ってVibe Codingしてみました。

Vibe Codingとは

There’s a new kind of coding I call “vibe coding”, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It’s possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper…

— Andrej Karpathy (@karpathy) February 2, 2025

  1. 自然言語で作りたいものを説明し、作ってもらう

  2. 作ってもらったものを動かしたりして、エラーをフィードバックする

  3. コードなにそれおいしいの？ってする

という感じで、プログラムを作ってもらう。AIに丸投げで開発することをVibe Codingと呼んでいるかんじですかね。

なので、Vibe Codingしてみたは雑にAIに投げて開発してみた！ってことです。ClineみたいなやつもVibesだし、Cursor ComposeとかWindsurf CascadeとかもVibes！って感じですねぇ。

やったこと（やってもらったこと）

前回の記事はお仕事開発を効率化しましたが、今回は完全に趣味プログラミングの方です。なので、生成されたものが動いてそうなら、基本🙆としてマージしまくりました。

個人ブログの改修

Hugoを使って管理しているブログがあります。

[わ] [わ] watura の ブログ wtr.app

今はnoteをメインに書いていますが、心の中のメインはいつも.appの方です。

という感じで、ちょこちょこやりたいなと思っていたことをやってみました。
CSSとかなんもわからんな３つ目以外は、時間もあるしじゃあやるか！ってなって重い腰を上げたらできるような内容ではありました。

note記事のインポートはGithub Actionsをつかって継続的に行なうようにしています。なので、私のnote記事は常に.appの方にもあるという状態になっています。
なお、中身の更新はチェックしていないので、差分が発生するんですが、それはいつかまたやりましょうというと思っています。

アプリの開発

よくあるUIでAPI仕様も決まっており、まあやるだけだよね！みたいなアプリをちくちくつくってみました。
iOSアプリなので完全Vibes!!とはいかないですけど、ほとんどコードを見ないでアプリの動作確認、Xcodeの出すエラーのフィードバックだけに近いレベルでだいたい作れました。

やってみて

小さすぎると微妙

ブログの方は、ほぼ単発スクリプトレベルでした。単発スクリプトレベルだと、別のプロンプトで作ったスクリプトが全く別物という感じで作られるという問題がありました。
同じコードベースなのだから、同じように書いてくれよと思うのですが、ものとしては別物なので一緒に渡すものでもなさそうだし？という感じでちょっと統一感がないよなぁと感じました。

再現性があまりない

同じプロンプトを投げても全く同じコードを作ってくれませんでした。日本語的には大体同じでもちょっと違うと全然違うコードになったりしました。
このあたりの再現性というのは本格運用だとちょい微妙かな？と思いました。

ビルドとテストできないと無限に試行錯誤する

今作っているのはSwift Packageを使ったプロジェクトなのですが、iOS向けなので、macでは動作しません。Package.swiftにもiOSしか指定していません。

なのに、swiftコマンドでビルドしようとしたり、swift testでテストを実行しようとしたりしてきます。

なんてことをちょくちょくやってきたりします。一応、windsurfのルールファイルにも正しいビルド方法とかを書いたりしたのですが、スルーされる場合がすごく多かったです。
なので、

みたいなことをルールの冒頭に書きておきました。わりとそのあとからは平和になりました。

ゴミコード

コードなんて気にせず動いてるんだからいいでしょ？というノリで進めていました。動作的な不具合が発生したので、それをフィードバックしたのですが、不具合がどんどんひどくなって、もともとあった機能すら無くなって、ぐだぐだになっていくみたいなことがありました。Revertしてその機能追加を無かったことにする他ないみたいな状況になりました。

Revertしてからコードを見てみると、**マジかよ。なんだこれ。**みたいなやばいグダグダコードになっていました。不具合が発生したのはグダグダしたコードをまともに変更できなかったからだと理解できました。
というわけで、コードレビューちゃんとしないと破滅に突き進んでいってしまうかもです。

言語化が大切

そのゴミコードをどうするか。というのを文章として説明してあげる必要がありました。が、言語化する能力が足りなくて、結局自分でやりました。

とかを徹底して説明する必要がありました。これの手を抜くと、グダグダになったり、ちょっと違うことをやり始めたりします。

そこまでするなら、俺がやったほうが早いってなる時もいっぱいありました。どうやってのところを説明しきれないこともありました。

まとめ

各ステップを別作業しながらやっていました。晩御飯作りながら、プロンプトを考えたり、通りすがりに入力したり、といった感じです。放置できるというところがAI丸投げコーディングのいいところかと思いました。

ちゃんとやったら、もっとちゃんとできるのに出来ないのは、私の説明不足のせいです。実装できる実力があるのに、実力が発揮されないのは私のせいです。

しかし、近い将来、拙い説明でも品質としてまあまあなアプリが出力がなされてくるようになるのではないかと思います。プログラマーとしては、まあまあからその先を作り出したり、最初からその先を出力できるようにしたりというところを目指していくのかなと思います。
たんに何も考えずにAIを使っていたり、もしくは、ゼロAIをしていると一瞬で置いて行かれてしまう気がしました。
言語化する力が今後一番必要なんだろうなと思います。

「顧客が本当に必要だったもの」で、プログラマー側にいるのが常だったので、顧客側の気持ちがよくわかった気がします。

とりあえず、次はここを目指して趣味プログラミングしてみたい。

#note