メインコンテンツへスキップ
  1. 記事/

30 Days of Vibe Coding - まとめ

Nuno Coração
著者
Nuno Coração
Principal Product Manager @ Docker
目次
30 Days of Vibe Coding - この記事は連載の一部です
パート 31: この記事

終わった。30プロジェクト。30日間。

プラットフォーマー。Nokia 3310のSnakeクローン。アイソメトリックグラフィックスのRPG。プロシージャル音楽付きテトリス。ブレイクアウト。Goで作ったポモドーロタイマー。gitダッシュボード。MCPサーバー付きメモアプリ。AIが管理できるカンバンボード。Miroクローン。Trelloクローン。Wordle。ポートフォリオジェネレーター。ASCIIアートの天気ダッシュボード。オートバトラー。負けるたびに学習するAIとの三目並べ。AI封じ込めからの脱出をテーマにしたハッキングゲーム。リアルタイム投票アプリ。イベント用リアクションウォール。コラボレーションムードボード。匿名チャットルーム。ライブQ&Aツール。ブラウザ上のWindows 95。ブログのリデザイン。音声ファイルゼロのアンビエントサウンドミキサー。コラボレーションピクセルアート。Rustで作ったターミナルエミュレーター。Goで作ったコードエディター。Notionクローン。そして上記すべてを内包するオペレーティングシステム。

これが可能だったのはコーディングエージェントのおかげだ。主にClaude、時々Codex、そしてWatchfireを使って複雑な作業をオーケストレーションし、ラフなアイデアを詳細なスペックに変換してエージェントに実行させた。

数字で見る成果
#

  • 30プロジェクトをシップしてデプロイ
  • 全プロジェクト合計約326,000行のコード
  • 合計約1,200コミット
  • 約450のWatchfireタスク(三目並べの4タスクからコードエディターの43タスクまで)
  • 8つの技術スタック: TypeScript/React、Go/Bubble Tea、Python/Textual、Rust/Tauri、Go/Wails、バニラJS、Astro、Next.js
  • 6つのFirebaseプロジェクト(リアルタイム同期付き)
  • ゲーム5本、 TUIアプリ5本、ネイティブデスクトップアプリ3本、Webアプリ17本
  • ネイティブアプリは3プラットフォーム(macOS、Linux、Windows)対応
  • ブログ記事ごとに7言語(英語、ポルトガル語、スペイン語、ドイツ語、フランス語、イタリア語、日本語、中国語)

簡単だったこと
#

ほぼ毎回、最小限のイテレーションでうまくいったもの。

ゲームと自己完結型アプリ。 明確なルールと決まったスコープがあるもの。テトリス、Wordle、ブレイクアウト、Snake。AIはこれらのゲームがどうあるべきかを知っている。よく文書化されたパターンだからだ。ゲームを説明すれば、AIがゲームを作る。ほぼ毎回、最初のビルドでプレイ可能だった。

フロントエンドUI。 Reactコンポーネント、Tailwindスタイリング、レイアウト、アニメーション。AIはクリーンなUIコードを高速に生成する。カードレイアウト、モーダル、サイドバー、ダッシュボード、フォームフロー。見た目を説明できれば、最初のパスで近いものが得られる。

システムとロジック。 戦闘エンジン、Q学習、カンバンの状態管理、アンドゥ/リドゥ、ファイルウォッチャー、MCPサーバー。AIはアルゴリズム的な作業やステートマシンを上手く扱う。ポモドーロタイマーのステートマシン、MyBruteの戦闘システム、三目並べのQ学習実装。これらすべて、コアロジックをデバッグする必要なく完成した。

既存ツールのラッピング。 Day 7で証明されたのは、構造化された出力を持つ任意のCLIをAIに指定すれば、それをラップするUIが構築できるということだ。gitにシェルアウトし、テキストをパースし、ダッシュボードを構築する。同じパターンはDocker、kubectl、テキストインターフェースを持つ何にでも使える。

Firebase統合。 匿名認証、Firestoreリスナー、リアルタイム同期。AIはFirebaseのパターンを完璧に知っていた。6つのプロジェクトがFirebaseを使い、リアルタイムコラボレーションは毎回初回デプロイで動作した。セキュリティルール、データモデリング、接続管理。すべて対応済みだった。

まだ難しいこと
#

一貫して人間の介入、イテレーション、忍耐を必要としたもの。

ビジュアルスタイルとアートディレクション。 これはゲームに限らない。フロントエンドアプリで特定のビジュアルアイデンティティを求めるたびに、AIは苦戦する。Day 15(MyBrute)では、うまくいくものにたどり着くまでに4つの完全に異なるキャラクタースタイルを経た。しかし同じ問題はWebアプリにも現れる。ランディングページの美学、しっくりくるカラーパレット、タイポグラフィの組み合わせ、生成されたのではなく意図的に見えるスペーシング。AIはアウトプットを生成する。人間がそれが良いかどうかを判断する。

デプロイとインフラ。 コードはローカルで動く。デプロイすると全部壊れる。Day 29(n0ti0n)では、本番環境でのFirestoreのデバッグだけで何十ものコミットがあった。ロングポーリング設定、キャッシュ設定、環境変数のトリミング、接続タイムアウト。デプロイ後にしか表面化しないもの。Day 28(ideA)では、GitHub ActionsでWailsを3プラットフォーム向けにビルドするために、何コミットもの戦いがあった。AIは修正を素早く提案できるが、デプロイ→テスト→イテレーションのサイクルは何を使っても遅い。

ネイティブアプリのCI/CD。 クロスプラットフォームビルドは苦痛だ。LinuxのWebKit依存関係、プラットフォームごとのビルドタグ、Wailsバインディング生成、コードサイニング、OSとアーキテクチャを検出するインストールスクリプト。Day 27と28は、実際のアプリケーションよりもCIに多くの時間を費やした。Watchfireはここで大いに役立った。デバッグ、テスト、実行、失敗、そしてパイプラインがついに動くまで繰り返すという無限ループを回し続けてくれた。あの粘り強さがなければ、クロスプラットフォームリリースは諦めていたと思う。

ポリッシュとエッジケース。 Day 30のウィンドウスナップは、修正したと思うたびに新しいバグが出た。最大化されたウィンドウをスナップするとどうなる?ドラッグ中にワークスペースを切り替えたら?スナップされたウィンドウをリサイズしたら?AIはハッピーパスを上手く構築する。エッジケースには人間がテストしてレポートする必要がある。

予想外だったこと
#

このチャレンジを始めたときに予想していなかったこと。

AIがプロダクトの意思決定をする。 Day 21(ChatRooms)では、私が指定していないのに匿名認証が使われた。AIが判断したのだ。カジュアルなチャットアプリでアカウント作成を強制するのはコンバージョンキラーだと。これはコード生成ではない。プロダクトの勘だ。これは繰り返し起きた。頼んでいない機能が、AIがそこにあるべきだと推論したから現れた。これはスペック駆動開発と関連があるかもしれない。Watchfireでは、プロジェクトのプロダクト方向性を指定する。エージェントはそのビジョンに向かって作業し、コードがスペックに一致するまでイテレーションを続ける。スペックがプロダクトの感触について明確であれば、AIはより良い判断を下す。

馴染みのない技術スタックでも問題ない。 私はGoが書けない。Bubble Tea、Lip Gloss、Tauri、Wailsに触れたこともない。Rustも知らない。しかしDay 6-9では洗練されたGo TUIアプリを、Day 27ではRustバックエンドのターミナルエミュレーターを、Day 28ではGo/Wailsのコードエディターをシップした。新しい技術スタックを試すハードルが崩壊した。Context7 MCPを使ってエージェントに最新のドキュメントを渡すことがここで大いに役立つ。AIはオンデマンドで最新のドキュメントを取得できるとき、トレーニングデータに頼る必要がない。

ボトルネックが移動した。 ビルドに時間を使うのをやめ、レビュー、テスト、バグレポートの作成に時間を使うようになった。制約は「AIにこのコードが書けるか」ではなかった。「十分にテストしたか」と「これは本当にしっくりくるか」だった。

プロシージャルオーディオは実用的だ。 Day 4(テトリス)、Day 12(Wordle)、Day 25(SoundScape)ではWeb Audio APIを使ってすべての効果音と音楽を合成した。音声ファイルゼロ。雨、風、暖炉のパチパチ、ローファイビート、ゲーム効果音。すべてオシレーターとノイズバッファで生成。これが本番環境で実用的だとは思っていなかった。

ナラティブがコードより重要だった。 最も反響があったプロジェクトは、技術的に印象的なものではなかった。Day 17(Genesis)はミニゲームではなくストーリーで響いた。Day 23(RetroOS)はウィンドウマネージャーではなくノスタルジアで響いた。Day 15(MyBrute)は元のゲームへの個人的なつながりがあったから響いた。コードは簡単な部分だった。切り口が難しい部分だった。

今後の予測
#

プロトタイプを作るコストが激減した。優れたソフトウェアを作るコストではない。それにはまだ時間とセンスとイテレーションが必要だ。しかしアイデアをテストするコスト?使ったことのない技術スタックを探索するコスト?ほぼゼロだ。

既存ソフトウェアへの機能追加も劇的に安くなった。 適切なアーキテクチャでプロジェクトがセットアップされれば、新機能の追加はゼロから作るより簡単だ。AIは既存のコードベースを理解し、パターンは確立されており、新しい機能はすでにあるものの上に構築される。次の機能の限界コストはゼロに近づく。

ボトルネックはコードを書くことから何をシップするか決めることに移った。 どうマーケティングする?どう売る?いつローンチする?エンジニアリングはもはや制約ではない。プロダクト戦略、Go-to-Market、ディストリビューションこそが制約だ。

これはすでにチームの働き方を変えている。 スプリントではなく数時間で機能を構築できるなら、ロードマップにまだ意味はあるのか?シップできるものすべてをどうテストする?適切なビジネスメトリクスに適切なインパクトを与えているかどうやって分かる?デプロイと同じ速さでどうやって撤退する?実験ツールがソフトウェアを構築する企業にとって極めて重要になると予測する。A/Bテスト、フィーチャーフラグ、段階的ロールアウト。素早くデプロイできる能力は、同じ速さで計測し元に戻せなければ無意味だ。

AIは開発者を置き換えない。強化するのだ。 本当の課題は組織的なものだ。企業全体が計画、ロードマップ、スプリントサイクル、見積もりを中心にゼロから構築されている。ビルドが速くなった今、残りの機能はどう追いつく?プロダクト、デザイン、QA、マーケティング、セールス。エンジニアリングのボトルネックが消えても、仕事が消えるわけではない。ボトルネックが上流と下流に移動するのだ。このシフトに適応した企業は、他のすべてを圧倒するだろう。

ツールは開発者を置き換えるのではない。試さない理由をなくしているのだ。

Watchfire
#

このチャレンジのすべてのプロジェクトはWatchfireで構築された。これは本当に誇りに思う。私のプロジェクトだ。このチャレンジの一部は、コンテンツを作りながら本番環境でストレステストすることだった。もうお分かりだろう。

ラフなアイデアを渡すと、それを詳細なスペックに変換し、作業をタスクに分割し、各タスクをコーディングエージェントを通じて実行した。4タスクの日もあれば、43タスクの日もあった。アウトプットをレビューし、テストし、壊れたらバグレポートを出し、シップするまでイテレーションした。

このチャレンジをしながらWatchfireの開発を始めた。最初のPlatformerプロジェクトはv0で作った。Day 30でminiOsをシップした頃にはv5になっていた。各プロジェクトがツールをストレステストし、バグを見つけ、フィードバックを集め、改善をシップする機会になった。チャレンジとツールは一緒に進化した。

30日間でWatchfireに起きた変化:

  • v1.0 Ember(Day 8)- JONLトランスクリプトログが文字化けしたターミナル出力をクリーンな会話ログに置き換えた。レート制限での無限ループを引き起こしていたエージェント再起動ループを修正。macOSの保護ディレクトリでプロジェクトをブロックしていたサンドボックス問題を修正。
  • v2.0 Spark(Day 11)- プラガブルなエージェントバックエンドインターフェース。OpenAI Codex、opencode、Gemini CLIがClaude Codeと並んでファーストクラスバックエンドとしてシップ。タスクごとのエージェントオーバーライドで、単一プロジェクト内でエージェントをミックス&マッチ可能に。初期化ウィザード、TUI設定、GUI設定にエージェントピッカー。
  • v3.0 Blaze(Day 15)- 5番目のバックエンドとしてGitHub Copilot CLI。Linuxでのクロスファイルシステム更新の失敗を修正。多くのタスクを持つプロジェクトでのタスクリストローテーションバグを修正。起動のたびに発生していたGUI更新プロンプトを修正。
  • v4.0 Beacon(Day 28)- 大型アップデート。集約ステータス、フィルターチップ、経過時間バッジ、ライブターミナルプレビュー、失敗タスクの要注意表示を備えたダッシュボード。タスク失敗と実行完了のOS通知。インラインdiffビューアー。タスクごとのメトリクスキャプチャ(時間、トークン、コスト)。KPIストリップとチャート付きのプロジェクトおよびクロスプロジェクトインサイトビュー。CSVとMarkdownへのレポートエクスポート。週次ダイジェスト通知。Slack、Discord、webhookとのアウトバウンド統合。GitHub自動PR作成。GitHub、Slack、Discordハンドラー付きのインバウンドHTTPサーバー。
  • v5.0 Flare(Day 30)- Beaconのインバウンドループを閉じた。SlackとDiscordのOAuthボットトークン。GitHub Enterprise、GitLab、Bitbucketサポート。IPごとのレート制限。リトライ/キャンセルボタン付きSlackインタラクティブコンポーネント。Discordスラッシュコマンドの自動登録。検索付きmacOSスタイルの設定UI。run-allがマージ失敗時にサイレントに停止する問題を修正。

そして最大の変化:チャレンジ期間中に、WatchfireはmacOS専用から、macOS、Linux、Windows完全対応のクロスプラットフォームサポートになった。それだけで使えるユーザーの幅が変わった。

30日間で5つのメジャーバージョン。macOS専用のタスクランナーから、マルチエージェントサポート、ダッシュボード、通知、統合、インサイト、デリバリーパイプラインを備えたクロスプラットフォームオーケストレーションプラットフォームへ。

Watchfireは複数のコーディングエージェント(Claude Code、Codex、Gemini、opencode、Copilot)をサポートし、クロスプラットフォームで動作し、GUI、CLI、TUIとして使用できる。現在v6に取り組んでおり、Cursorサポートの追加と並行性バグの修正をしている。より正確に言えば、今やWatchfireがWatchfireを構築している。ツールが自身の開発をオーケストレーションしている。このチャレンジを始めたとき、この文を書くことになるとは思っていなかった。

まだまだこれからだ。この30日間から回復したら、Watchfireの詳細な解説を書くつもりだ。

ありがとう
#

フォローしてくれた人、プロジェクトを試してくれた人、投稿をシェアしてくれた人、いくつか記事を読んでくれただけの人も、ありがとう。これは大変な作業であり、とても楽しかった。パブリックにビルドするのは不思議なものだ。荒削りな作品を誰もが見られるようにシップしているのだから。でもそれがポイントだった。ポリッシュではなく。完璧でもなく。ただ一貫したアウトプットと学びだ。

次に私がやることをフォローしたければ、ブログを購読するか(リンクは下)、ソーシャルでフォローしてほしい。そしてもしこれが響いたなら、役に立ちそうな人にシェアしてほしい。この種の活動をサポートする最善の方法だ。

30プロジェクト。30日間。完了。

全30プロジェクト
#

Dayプロジェクトタイプ試す
1Platformerゲームプレイ
2Snakeゲームプレイ
3Realm of Shadowsゲームプレイ
4Tetrisゲームプレイ
5Breakoutゲームプレイ
6PomodoroTUIリリース
7GitDashTUIリリース
8NotesTUITUIリリース
9TaskTUITUIリリース
10Miro CloneWebアプリ試す
11TreeloWebアプリ試す
12Wordleゲームプレイ
13GitFolioWebアプリ試す
14WeatherTUITUIリポジトリ
15MyBrute Arenaゲームプレイ
16Tic-Tac-Toe: Evolvedゲームプレイ
17Project GENESISゲームプレイ
18PollBoxWebアプリ試す
19ReactionWallWebアプリ試す
20MoodBoardWebアプリ試す
21ChatRoomsWebアプリ試す
22LiveQ&AWebアプリ試す
23RetroOSWebアプリ試す
24ReblogWebアプリ試す
25SoundScapeWebアプリ試す
26PixelForgeWebアプリ試す
27Terminalネイティブリリース
28ideAネイティブリリース
29n0ti0nWebアプリ試す
30miniOsWebアプリ試す

これは30 Days of Vibe Codingシリーズの最終投稿です。全30プロジェクトはGitHubでオープンソースとして公開されています。

30 Days of Vibe Coding - この記事は連載の一部です
パート 31: この記事

関連記事