Vibe Codingとエンジニアリング：私が引く境界線

Andrej Karpathyは2025年2月に「vibe coding」という言葉を生み出しました。プログラマーが「完全にバイブスに身を任せ、指数関数的な成長を受け入れ、コードの存在すら忘れる」開発スタイルを表現したものです。¹

これを読んで思いました。それは私のワークフローの半分だと。もう半分はその正反対です。

TL;DR

私は毎日Claude Codeで開発しています。その作業の一部は純粋なvibe codingです。欲しいものを説明し、出力を受け入れ、次に進みます。残りの作業は、86のフック、gitセーフティガーディアン、再帰ガード、そしてAI臭い表現やパッシブボイスを含むコミットをブロックする品質ゲートシステムを通過します。この2つの境界線は恣意的なものではありません。プロトタイプにはバイブスを。プロダクションにはエンジニアリングを。難しいのは、プロトタイプがその境界線を越える瞬間を見極めることです。

私の実際のワークフロー

バイブス側

アイデアを探索しているとき、私は迷いなくvibe codingをします。Ace CitizenshipのiOSアプリは、週末の実験として始まりました。「USCIS公民テストの間隔反復クイズを作って」とClaude Codeに伝え、最初のSwiftUIビュー、問題バンク、スケジューリングアルゴリズムを生成させました。すべての行を読んだわけではありません。実行し、手動でテストし、違和感のある部分を言葉で説明してイテレーションしました。

このブログのインタラクティブコンポーネント（RAGディシジョンツリー、複利計算機）も同じように始まりました。「RAG vs ファインチューニングをアニメーション付きで案内するディシジョンツリーを作って」。受け入れ、テスト、調整。ブログウィジェットのバグの影響範囲は1ページに限定されます。

エンジニアリング側

私のClaude Codeフックアーキテクチャは、vibe codingの対極にあります。すべてのフックは、何かがうまくいかなかった経験から生まれました。

git-safety-guardian.shは、初期のセッションでClaudeがmainブランチにforce pushしたことがきっかけで作られました。このフックは、すべてのgitコマンドをインターセプトし、重大度テーブル（CRITICAL: mainへのforce push、HIGH: .envファイルの追加、MEDIUM: –no-verify）に対してパターンマッチングを行い、実行前に警告を挿入します。

recursion-guard.shは、サブエージェントが無限に子プロセスを生成したことがきっかけで作られました。このフックは、JSONファイルでエージェントの系譜を追跡し、深度制限を適用し、正当な並列処理を許可しながら暴走するエージェントチェーンを防ぐスポーンバジェットモデルを管理します。

blog-quality-gate.shは、AI生成の文章がAI生成の文章に聞こえるという問題から作られました。このフックは、content/blog/へのコミットにemダッシュ、パッシブボイス、または「delve」「crucial」「landscape」などの単語を検出した場合にブロックします。

これらのフックはどれもvibe codingで作られていません。それぞれが1行ずつ書かれ、実際の障害シナリオに対してテストされ、デプロイ前にレビューされました。86のフックは、バイブスとエンジニアリングの境界線そのものです。

境界線が実際に引かれる場所

バイブス：使い捨てのプロトタイプ

捨てる可能性のあるものはすべてvibe codingで作ります。一度だけ実行するデータ変換スクリプト。個人利用のCLIツール。APIがドキュメント通りに動作するか確認する概念実証。使い捨てコードのバグのコストは自分の時間だけであり、スピードの向上がデバッグリスクを上回ります。

バイブス：クリエイティブな探索

デザインの方向性を探索しているとき、vibe codingを使えばFigmaよりも速くインタラクションパターンをテストできます。「キーボードナビゲーション、結果ハイライト、Cmd+Kアクティベーション付きの検索モーダルを作って」と指示すれば、数分で動くプロトタイプが完成します。評価するのはコードではなく、使い心地です。²

エンジニアリング：ユーザーに届くもの

コードが自分以外の誰かに届く瞬間、それは境界線を越えます。私のブログは、引用、見出し階層、読みやすさのグレード、画像altテキスト、内部リンク密度、コンテンツの深度をチェックする12モジュールのリンターを通過します。リンターには77のテストがあります。ブログには29の記事があります。リンターのテスト数がブログのコンテンツ数を上回っています。

エンジニアリング：永続するもの

データベーススキーマ、APIコントラクト、フック設定、デプロイマニフェストには、完全なエンジニアリングを適用します。これらの決定は複利的に影響を及ぼします。バイブスセッションで設計されたスキーマは、3年分のデータが蓄積された後にマイグレーションの悪夢となります。³

エンジニアリング：セキュリティに関わるもの

AI生成コードは、トレーニングデータのセキュリティ水準を反映します。そのトレーニングデータには、簡潔さのために認証、入力バリデーション、エラーハンドリングを日常的に省略しているチュートリアルやStack Overflowの回答が含まれています。⁴ 私のフックはその一部を検出します（gitセーフティガーディアンが.envの追加、認証情報ファイル、force pushをフラグします）が、セキュリティクリティカルなコードは必ず手動レビューを行います。

理解のギャップ問題

Vibe codingで最も危険なパターンは、悪いコードではありません。壊れるまで正常に動くコードです。

私はi18n翻訳システムのキャッシュレイヤーを生成しました。英語コンテンツでは完璧に動作しました。韓国語と繁体字中国語を追加したとき、キャッシュキーの生成が特定のUnicodeコードポイントで無言のまま衝突を起こしました。デバッグに4時間かかりました。キャッシュキー関数を一度も読んでいなかったからです。コードはASCIIに対しては正しいものでした。トレーニングデータが重視していたのもASCIIだったのです。⁵

教訓は明確です。vibe codingで作られたシステムは、トレーニングデータが十分にカバーしていないエッジケースで壊れます。ユーザーがそのエッジケースで操作する場合（非ラテン文字、高並行性、特殊なネットワーク条件）、vibe codingによる実装には隠れたリスクがあります。

レビューゲート

私のシステムでプロダクション向けのコードはすべて、私が書いたものもClaude Codeが書いたものも、レビューゲートを通過します：

1. すべての行を読む。 生成されたコードは、信頼されていないコントリビューターからのプルリクエストです。それに応じてレビューしてください。
2. エラーハンドリングを検証する。 エラーパスが汎用的なtry-catchパターンではなく、ドメイン要件を反映しているか確認してください。
3. 依存関係を監査する。 AIは各プロンプトを独立して処理し、目前のリクエストを解決するライブラリを何でもインポートします。50プロンプト後には、3つの日付ライブラリと2つのHTTPクライアントが含まれているかもしれません。
4. テストを追加する。 生成されたコードが、あなたのドメイン固有のエッジケースをカバーすることはほとんどありません。
5. セキュリティを確認する。 静的解析を実行し、認証、認可、入力バリデーションを検証してください。⁶

レビューゲートはオプションではありません。AIを力の増幅器として使うか、松葉杖として使うかの違いがそこにあります。

業界の分岐

ソフトウェアエンジニアリングは2つの層に分かれつつあります。第1の層はAIを力の増幅器として使います。ボイラープレートの生成、ソリューション空間の探索、十分に理解されたパターンの実装を加速しながら、理解と品質基準を維持します。第2の層は、出力を理解せずにアプリケーション全体を生成し、短期的な速度と引き換えに長期的な脆弱性を生み出します。⁷

この分岐は、初期のWeb開発を反映しています。SquarespaceのようなテンプレートビルダーはWeb公開を民主化し、何百万もの機能的なウェブサイトを生み出しました。プロフェッショナルなWeb開発が存続しているのは、プロダクションシステムにはテンプレートでは提供できない品質、セキュリティ、保守性が必要だからです。

私は意図的に両方の層で活動しています。フックシステムと品質ゲートは、第2層の作業が第1層の基準に昇格すべき瞬間を検出するために存在します。86のフックは官僚主義ではありません。vibe codingを自由に行いながら、vibe codingされた成果物がレビューなしにプロダクションに到達することを防ぐ免疫システムなのです。

重要なポイント

AIを日常的に使うエンジニアへ： - 探索とプロダクションの間に明確な線を引いてください。使い捨ての作業は自由にvibe codingし、ユーザーに届くものや永続するものにはレビューゲートを適用してください - 規律だけに頼るのではなく、自動化されたガードレール（フック、リンター、品質ゲート）を構築してください。深夜2時に規律は崩れますが、フックは崩れません

エンジニアリングマネージャーへ： - プロトタイプ品質とプロダクション品質のコードの間に明確な境界を設けてください。プロダクションに紛れ込んだvibe codingされたプロトタイプは、新しいカテゴリーの技術的負債を生み出します - ベロシティメトリクスではなく、成果（リリースされた機能、機能あたりのバグ数、ユーザー満足度）で生産性を評価してください。Vibe codingはコード行数を膨らませますが、成果を比例して向上させるとは限りません

参考文献