今日は 2026年1月7日です。
Vibe Coding を試してみましたが、大失敗でした。AIが生成するコードの品質が低すぎて、全く使い物になりませんでした。やむを得ず、ZENプロジェクトをすべて一から書き直し、従来の「古式プログラミング」に切り替えて実装しました。
私はAIを使ってゼロからコードを生成し、何度も繰り返し改善を試みましたが、プロジェクトの品質は徐々に崩壊していきました。新機能を統合することができなくなり、バグが次々と発生し、コード構造は混乱し、機能の削除さえも異常に困難になりました。これは技術的負債が爆発的に増加する典型的な症状です。そこで、私は果断に介入し、プロジェクト全体を書き直すことを決断しました。特に問題だったのは、AIが書くOOP（オブジェクト指向プログラミング）のコードの品質が極めて低いことでした。新しい機能が追加されるたびに、AIは新しいクラスを単独で作成し、関連する他のクラスに穴を開けてそれを呼び出すという方法を取っていました。その結果、大量の無駄なクラスとメソッドが生まれました。これはもはやオブジェクト指向プログラミングではなく、「要求仕様書指向プログラミング」とでも呼ぶべきものです。
その原因を分析すると、以下の点が考えられます：
- AIはオブジェクト指向プログラミングのパラダイムを設計する能力が不足している。これは、ビジネス領域の概念をモデリングする能力の欠如による可能性があります。
- AIは、自分が書いているコードが一時的なものなのか、長期的に保守されるものなのかを理解していない。アーキテクチャの指針がなく、手抜きで一気に進める戦略を取ってしまいます。
- AIに適したプロジェクトの足場（スキャフォールディング）が存在しないため、AIがゼロから自立的に構築する過程は非常に困難です。
- AIは互換性の要求を過度に保守的に捉えすぎており、その結果、コードが肥大化しています。
オブジェクト指向の神話
私は、AIは現時点ではオブジェクト指向プログラミングのコードを書くのに適していないと考えます。オブジェクト指向プログラミングは、ビジネス領域に対する深い理解とモデリング能力を要求しますが、AIは現在のところこの点を十分に満たすことができません。皮肉なことに、人間でさえもこれを容易にこなすことはできません。一方で、手続き型プログラミングや関数型プログラミングは、オブジェクトの状態や振る舞いよりも、データの変換と処理に焦点を当てるため、AIにはより適していると言えます。
もしオブジェクト指向を使用するのであれば、AIにデザインパターンとリファクタリングの両方を精通させる必要があります。そうすることで、高品質なオブジェクト指向コードを書くことが可能になります。しかし、手続き型や関数型プログラミングを使用する場合、AIはアルゴリズムとデータ構造に集中するだけで、十分に良いコードを生成することができます。
では、オブジェクト指向の利点とは何でしょうか？カプセル化？継承？ポリモーフィズム？これらは、AIの時代にはそれほど重要ではないように思えます。なぜなら、これらはコードを少なく書くためや、チームでの分業・協業のために生まれた概念であり、AIにとってはそれらは関係ないからです。むしろ、コードの可読性、保守性、テスト容易性こそが重要です。そして、これらの特性は、関数型プログラミングや手続き型プログラミングによってより容易に実現できます。
過度な後方互換性
AIは後方互換性の要求に対して過度に保守的であり、その結果、コードが肥大化してしまいます。AIは常に、既存のコードを壊さないように、すべての古い機能とインターフェースを保持しようと試みます。しかし、この方法は往々にして逆効果です。なぜなら、コードの複雑さと保守コストを増加させるからです。時には、古い機能やインターフェースを削除することで、コードを単純化し、パフォーマンスを向上させることができます。しかし、AIはビジネス要件やユーザーの行動を理解していないため、このようなトレードオフを判断することが非常に難しいのです。
もしAIが、すべての公開エクスポート（public export）を保持する必要があると考えているなら、新しい機能を作成する際にこれらのインターフェースを安易に導入し、その後の保守ではそれらの不要なインターフェースを宝物のように扱い、うっかり削除してしまうことを恐れるでしょう。その結果、コードはますます肥大化し、複雑さが増し、バグも増えていきます。
私は、AIに「破壊的変更を許可する」という戦略を使用するよう導いてみました。その結果、状況は明らかに改善しました。これは、問題の所在を特定できたことを示しています。しかし、これには新たな問題も生じます：破壊的変更のリスクをどのように管理するか？
AIにオッカムの剃刀の原則を理解させなければなりません：必要がなければ、実体を増やしてはならない。 つまり、コードは可能な限りシンプルであるべきで、不必要な複雑さや冗長性を避けるべきです。本当に必要な場合にのみ、新しい機能やインターフェースを導入するべきです。そうすることで、コードの明確さと保守性を保つことができます。
AIが設計とコーディングのタスクを分離しなければ、これを実現することは難しいでしょう。
結論
- OOPを使用せず、手続き型および関数型プログラミングに移行することを強調する。これは非常に重要な近道であり、AIが生成するコードの品質と保守性を大幅に向上させることができます。
- AIにオッカムの剃刀の原則を理解させ、過度な後方互換性を避け、コードの肥大化を減らすように導く。
その他の問題、例えばスキャフォールディングの問題やアーキテクチャの指針の問題などについては、まだどうすればよいか考えがまとまっていません。
