Updating a side project with AI in 275 commits

Ben Hoyt

AIでサイドプロジェクトを275コミットでアップデート

原文は Ben Hoyt により に公開されました。 このブログを購読する

最近、勤め先では半期休暇があり、ほぼ全員が同じ時期に2週間の休みを取ります。マネージャーとして、これまでAIツールは本格的なコーディングというより、コードレビューや技術的な探索に使ってきたのですが、そこを変えてみたいと思いました。

そこで休暇を使って、サイドプロジェクトのGifty Weddingsをいじることにしました。以前、2016年にGoバックエンドへ2019年にElmフロントエンドへ移行していました。今回は2つの目標がありました。

  1. 単なる結婚式のギフトリストから、結婚式のウェブサイトを構築できるサービスへアップグレードすること。
  2. AIツールを使って質の高いコードを書く方法を学ぶこと。

同僚の勧めで、コーディングの大部分にはClaude CodeとOpus 5を使いました。小さなタスクには、オープンウェイトのGLM 5.2モデルを使ったPiを使いました。そして自分の頭脳も使いました。

冗談ですが、自分の頭を使うことこそ、粗製乱造の駄作を量産することと、誇れるプロダクトを作ることを分ける大きな要素だと思っています。私たちは今もエンジニアなのです。

この記事では、AIに対する私の懐疑的な見方について触れつつ、このプロジェクトがうまくいった要因だと考えること、そしてなぜ楽しかったのかについて書こうと思います。

私の懐疑

私はしばらく前からAIに対してかなり懐疑的でした。最初はAIチャットボットがニューヨーク・タイムズの記者に恋をした初期の頃に、そして「コントリビューター」を名乗る人たちから大量のAIによる低品質な成果物を処理しなければならなくなってからは、さらに懐疑的になりました。

2024年にコーディングに使ってみたときも、あまり感心しませんでした。その時点では、自分でやった方が早いくらい、AIがやったことの後始末に時間がかかったのです。

もっと最近になって、妻のインテリアデザインのウェブサイトをほぼ一発で作るのに使ってみたり、GoAWKのさまざまなバグ修正に使ってみたりしました(その中にはOpus 4.6がかなり優柔不断だったケースも含まれます)。

どちらのケースでも感心させられました。ウェブサイトの件では、私がCSSを書くのがあまり好きではないからですし、バグ修正の件では、作業が大幅に速くなり、良いアイデアももらえたからです。

私のアプローチ

まず前提として、私は比較的経験豊富なウェブ開発者です。だからこそ、プロセスをうまく導き、エージェントの出力を効果的にレビューできます。余談ですが、AIについて私が最も懸念していることの一つは、経験の浅い開発者が、苦労して得られるはずの経験をショートカットしようとしてしまうことです。

また、既存の成果物の上に構築していたということもあります。古いサイトのCSSスタイルシート(それ自体がSkeletonをベースにしています)、SQLデータベーススキーマの大部分、そして作りたいものの計画から始めました。さらに、古いGiftyのコードベースを大いに参考にしながら、初期のGoサーバーやいくつかのパッケージは手書きしました。自分が望むようなコードの種をまいたのです。

そこからは、一発でやり遂げようとするのではなく、反復的な開発に切り替えました。すべての段階で技術面とクリエイティブ面のコントロールを自分で握っていたのです。コードの変更ごとに、通常は数文のプロンプトで機能を提案し、出力されたコードをレビューするとともに、ブラウザで実際に機能をテストしました。

ほどほどのコードレビューは行いました。自分のコードの職人芸の一部は諦めなければなりませんでした。AIのコードスタイルは完璧ではなく、少なくとも多くの場合で自分ならそうは書かないというものでした。もちろんバグは指摘し、構造的な問題には異議を唱えましたが、概ねAIが書いたコードにはかなり満足しています。

ただ、テストについてはそこまで徹底的にはレビューしませんでした。AIエージェントは大量のテストを書くようで、時には明らかに多すぎることもあり、元が取れないと感じたものは削除しました。最初は細部まで目を通していましたが、終わり頃にはかなり流し読みする程度になっていました。

その過程でいくつか学んだことがあります。

  • LLMはとても冗長なコメントを書きます。簡潔にするように、一行で要約するようにと何度も指示しなければなりませんでした。ある「コメントを簡潔化」するコミットでは、コメント行を約2500行から1500行に減らしました。
  • Claudeにヘッドレスブラウザをインストールさせ、自分でスクリーンショットを撮らせるようにしたら、HTMLやCSSを書く能力がかなり向上しました。それまでは自分でスクリーンショットを撮って手動でアップロードしなければなりませんでした。今では超能力を手に入れたかのようでした。サーバーを起動し、アプリの実際のフォームを使ってダミーデータを追加し、ChromiumでPNGのスクリーンショットを保存して、それを「見る」のです。
  • ただ、変更のたびにスクリーンショットを撮って処理させるとトークンを大量に消費しました。結局、フロントエンドに大きな変更を加えるときだけそうするように頼むことにしました。
  • コンテナ内でサンドボックス化していても(私はCanonicalのWorkshopを使っています)、Claudeは困ったことをします。何度かrm -rf $SOMEVAR/*.pngのようなコマンドを実行しましたが、SOMEVARが設定されていなかったため、使っていたテスト用の写真を削除してしまったのです。やめさせるためにメモリにルールを追加しましたが、とにかくLLMは常にコンテナやVMの中で実行すべきです。
  • すべての作業を一つのセッションでやらないことです。最初はそうしていましたが、コンテキストが非常に長くなり、すぐにClaude Proのさまざまな制限を超えてしまいました。そこでcompactionについて学び、定期的に新しいセッションを始めるようにしました。

では、私が作った機能を見てみましょう。

機能

Giftyでは、カップルが写真やテキスト、ギフトリストを含むシンプルな複数ページの結婚式ウェブサイトを作成できます。(旧Giftyはギフトリストの部分のみをサポートしていました。)

Giftyのサンプルウェブサイト

カップルはMarkdownでテキストを書いたり、写真をアップロードしたり(写真は縮小されてTigrisに保存されます)、ページを追加・並べ替えたりできます。そしてもちろん、少額の料金をいただいています。支払いはStripeで処理しています。

ゲストはカップルのウェブサイトを閲覧し、ギフトリストのギフトを購入済みとしてチェックを入れることができます。

ただ、私のお気に入りの機能は、旧Giftyから引き継いだものです。カップルがワンクリックで試せることです。

技術スタック

私はシンプルに保つのが好きなので、次のような技術を使いました。

  • できるだけ非標準ライブラリへの依存を少なくしたGoバックエンド。アップロード用のAWS SDK、Stripe SDK、画像リサイズ用ライブラリ、Markdownレンダラー、modernc.org/sqliteモジュール、そして「ほぼ標準ライブラリ」と言えるgolang.org/x/cryptoモジュールです。
  • 素晴らしいSQLiteデータベース。
  • より動的な部分、つまりギフトリストやページ編集機能にはHtmx
  • そして、必要に応じて数行のバニラJavaScript。

ホスティングはFly.ioで行っています。この種の用途には強くお勧めできるサービスです。fly deployでとても簡単にデプロイでき、費用も安価です。

感謝でいっぱいです

新しいウェブサイトの完成には丸10日ほどかかりました。AIツール、特に今回のClaudeにはとても感謝しています。妻には、AIがなければ3倍は時間がかかっただろうと話しました。

最も感心したことの一つは、Claudeが古いギフトリストシステム――GoのJSON APIとElmフロントエンドでできていたもの――を新しいバージョン、すなわちGoのHTMLエンドポイントとまったく異なるhtmxフロントエンドへ移植したことです。これをほぼ一発で完璧にやってのけたのには驚かされ、大幅な時間短縮になりました。

もう一つ、ほぼ一発で(いくつかのバグ修正はありましたが)やってのけたのが、旧Giftyのデータベースを新バージョンへ移行するツールでした。データベースは似ているので難しいことではありませんが、構造上の違いがいくつかあり、もっと手間がかかると思っていました。

しかし、全体としてAIに懐疑的な私が、なぜこれほど楽しめたのでしょうか。理由は二つあると思います。

一つ目は、ものを作るのが好きだからです。約10日で、実用的で見栄えの良いウェブサイトを完成させることができました。

二つ目は、プログラミングという職人仕事が好きで、それが今も味わえたからです。次の機能を考え、AIにコーディングさせ、コードをレビューし、バグを修正してコミットする。その繰り返しを275回。小さな機能なら10〜15分、大きな機能でも1〜2時間で、目標に向かって着実に進んでいく感覚がとても心地よかったのです。

今でも懸念はたくさんありますし、天に届く塔を建てて神にへし折られるようなことにならないことを願っています。でも、新しいツールには感謝しています。

最後に一つ。もし近々結婚する予定がある方や、そういう方をご存知でしたら、ぜひ新しいGiftyWeddings.comを教えてあげてください。結婚したいけれど相手がまだいないという方には――申し訳ありませんが、それはまた別のウェブサイトでお願いします!

この記事は「muse-spark-1.2-contributor」を使用して翻訳されました。

コメント