Bun

Bun 1.3 を試す意味で Bun を使った。概ね快適に動くし開発できたが、ところどころまだこなれてないところはあった。例えば bun run build してもそのままでは通らないとか。

bun init --react=shadcn でプロジェクトを作った。最初はReact抜きで素の bun init でプロジェクトを作って後付でReactを入れようとしていたのだが、設定が難しく断念した。特に画像類などのアセットが本番で参照できない。

多分、 bun init --react だと build.ts というファイルが作られるが、このスクリプトでTSをバンドル化しているようで、ここでファイルをゴニョゴニョして dist ディレクトリに格納しているようだ。

また、 Cloudflare Workers にデプロイしたが、そちらは Bun 1.2 系のようでエントリーポイントが想定通りに動作しないっぽかった。そのため Claude が勝手に 1.2 系対応のエントリーポイントを作ってくれた。

Bun 1.3 の公式ブログ記事を見ると、SPAでもMPAでも簡単に作れそうな雰囲気に見えるが、割とそういうことはなくて、MPAだと雛形になるindex.htmlに当たるHTMLを複数ページ分作る必要がありだるかったので、やはりフロントエンドは基本SPAで作ってルーティングライブラリを別途インストールするのが良さそうだ。公式ブログ記事で複数のパスでフロントエンドをサーブしているのはあくまでユーザー向けフロントエンドと管理画面とで別々のSPAがある、みたいなケースっぽい。

テスト、Lintとか

今回はテストを全く追加しなかった。LinterもFormatterも設定しなかった。CIも設定してない。手動テストのみ。本当に Vibe Coding という感じだった。そして、やはりAIで開発するならこのスタイルの方が速いと思った。もちろん長期的にもこのやり方のほうが速いかと言われたらわからない。そのうち全体的な整合性が容易に壊れるのは確実と思う。しかし、人の手による開発のように、初期からCIのセットアップとかテストとかLinterとかFormatterを設定してしまうと、AIがコミットのたびにそれらの修正のために手を止めるようになり、人が開発しているのとたいして変わらない速度になってしまうと思う。プロトタイプをとにかく速く作って世に出して検証する、という目的のためには、思い切って品質管理の自動化をバッサリ切り捨てることが間違いなく有効だと感じた。アプリが「いける」とわかってから環境を整えても遅くない。売れるかわからないものの品質を担保するのは無駄な投資になる可能性が高い。知見が得られるという意味では完全に無駄ではないにせよ。

AIレビュー

普段は CodeRabbit を使っているが、今回は全く使わなかった。これが開発速度に最も「寄与」していると思った。CodeRabbitのレビューは最近はなかなか鋭く、レビューコメントを見ると「確かにここは修正しないとな」とか思って修正してしまうのだが、この作業のせいで人間が書いているのと変わらない速度にまで遅くなってしまう。しかも CodeRabbit 自体も精度のために速度を犠牲にしているフシがあり、一時期よりもかなりレビューに時間がかかるようになっている。コードベースが成熟してきたら CodeRabbit などのAIレビューはほぼ必須だと思うが、プロトタイピングの段階でAIレビューは必要ない。必要ないというよりも無い方がいい。オーバーキルというやつだ。

このあたりの「技術的負債」に対する考え方は、AI時代以前とあまり変わらないように見えて大きく違うような気がする。人間の時代においては「借り入れも時には必要」という考えはあったにせよ、テストが全く存在しないコードベースやレビューが全く無い作業フローなどは論外という雰囲気があったと思う。なぜなら、最低限の品質担保の仕組みがなければ後のフェーズにおけるテスト拡充やリファクタが非常に難しくなり、プロダクトの寿命に直結してしまうからだ。しかし、AI時代においては品質担保自動化を下手にセットアップすると、AIがそれを「やり過ぎ」てしまう。テストをあまりにも簡単に書かせることができるため、テストケースが最初からめちゃめちゃ網羅されてしまい、簡単な変更でもテストがFailするようになり、その都度AIが修正してくれる。一見良いことのように見えるが、AIを使った開発の最も大きな恩恵である開発速度が犠牲になるし、AIにとって死活的なリソースであるコンテキストを大量に消費してしまう。

AI時代の新規開発においては、いくら不安であってもAIを信頼し、任せて、速度の恩恵をうけることが最も重要な気がする。そこでコードを人間が詳しく見てしまうと、汚いコードや無意味なコードが大量に作られているのを目にすることになり、修正したい衝動に駆られてしまうと思うが、開発初期からそちらに気を取られるとユーザーに届けるべき機能がなかなか届けられなくなるということだ。きれいなコードやバグの無いアプリは、機能と価値を届けた後で整えたほうがいい。AI時代においては価値を届けることのコストは非常に小さく、きれいなコードとバグの無いアプリを届けることのコストが圧倒的に大きい。

Zed

今回から Zed を使ってみた。その前までは Cursor を使っていた。使い勝手は Cursor や VSCode とだいぶ違う感じがするので、なれるまでは1週間とかかかる気がする。VSCodeにあった拡張がZedにもあるとは限らないし、VSCodeで自動化できてたものが自動化できない可能性もある。

ただ、ファイル検索はやはり速いような気がする。コードベースが大きい場合は Zed の優位性が効いてくると思う。しかし現在の自分の開発ではそこまで恩恵を感じられない。

Claude Code が Zed 内で使えるのは良い機能だと思う。Zed のAIエージェントじゃなくて自分のサブスクしてる Claude Code が使えるようだ（多分）。Claude Code が修正したコードの差分を見ながら Cursor ライクに Reject するか Keep するか判断できるのはなかなか良い。ただ、先述の通り人間がコードを見すぎるのは良くなく、AI開発の最大のメリットを殺してしまうことになると今のところ考えている。