Claudeの50の機能が崩壊した。その理由とは。

開発者のShiv Bhosaleは、7か月にわたる野心的なプロジェクトに着手し、K10sというGPU-aware Kubernetes dashboardを完全にClaudeで構築しました。この集中的な「vibe coding」の取り組みにより、50の異なる機能が生まれ、それぞれが単一の開発セッション内でうまく機能しているように見えました。個々のコンポーネントの迅速な生成は、複雑なアプリケーションが前例のない速度で具現化される未来を示唆し、陶酔的な進歩感をもたらしました。

このアプローチは、開発者が驚くほど簡単に新しい機能をプロトタイプ化し、実装できるという10x velocityの魅力的な誘惑を育みました。Claudeの効率的でセッションベースの出力は、各機能が独立した成功であり、最小限の統合作業しか必要としないという認識を強化しました。それは、生成の純粋な速度によって根本的な問題を覆い隠し、アーキテクチャの健全性に対する誤った感覚を生み出しました。

しかし、Bhosaleが50の機能をまとまったアプリケーションに結合しようと最終的に試みたとき、その幻想は壊滅的に打ち砕かれました。システム全体が崩壊し、根本的なアーキテクチャの不整合が明らかになりました。ビューを切り替えると古いデータが表示され、かつてデータが入力されていたテーブルは説明不能に空になり、重要なキー機能はアクティブな画面に応じて3つの異なる予測不能なアクションを実行しました。AIからのアーキテクチャ的先見性の欠如によって引き起こされたこの完全な破綻により、Bhosaleは7か月の作業を放棄し、コードベース全体をアーカイブし、プロジェクトをゼロからやり直すことを余儀なくされました。

AIの根本的な欠陥はすぐに明らかになりました。それは、まとまりのあるアーキテクチャではなく、孤立した機能の生成に優れていることです。各promptはサイロ化された指示として機能し、Shiv BhosaleのK10sプロジェクト内で状態を共有する他の49の機能についてはまったく認識していません。Claudeは個々のコンポーネントを提供しましたが、それらの部品が統一されたシステムとしてどのように相互作用すべきかについての理解が決定的に欠けていました。

この断片化されたアプローチは、必然的に脆く、保守不能なコードベースにつながりました。Bhosaleがすべてを一緒に使おうとしたとき、構造全体が崩壊しました。ビューを切り替えると古いデータが表示され、かつてデータが入力されていたテーブルは空になり、1つのキーが画面に応じて3つの異なるアクションを実行しました。個々の機能は単独ではきれいに機能しましたが、単に連携しませんでした。

Bhosaleの解決策は明確でした。開発者はアーキテクトの役割を取り戻さなければなりません。彼はシステムアーキテクチャを手動で設計し、それを`Claude MD`ファイルに徹底的に文書化しました。その上で初めて、彼はClaudeを「退屈なタスク」—事前に定義された手書きの構造的設計図の範囲内で特定の機能を厳密に実装すること—に活用しました。この転換により、AIは自律的なビルダーから、強力でガイド付きの実装ツールへと変貌しました。

AIのデフォルトのアプローチは、機能する機能への最短経路を見つけるために、すべてのロジックを単一の巨大なデータ構造に詰め込むgod objectアンチパターンです。Shiv BhosaleのK10sコードベースはこれを如実に示しており、驚くべき1,690行に及ぶ単一のstructを特徴としていました。このモノリシックなオブジェクトには、500行の`Update()`メソッドと110のswitchケースが含まれており、その管理不能な範囲を明確に証明していました。

このようなモノリシックな設計はメンテナンスを不可能にし、異なる機能間での密結合を促進します。ある領域でのわずかな変更が、脆弱なシステム全体に連鎖的な障害を引き起こすリスクがあります。Bhosale氏が経験した古いデータ、空のテーブル、ビュー間での一貫性のない主要機能は、このアーキテクチャ上の欠陥に直接起因しており、アプリケーションを本質的に不安定にしていました。

これを是正するには、LLMへの明確な指示が必要です。開発者はClaudeに懸念事項を分離させ、ロジックを個別のビュー、コンポーネント、データ構造に分割するよう強制する必要があります。このアーキテクチャ上のガイダンスは、AIがデフォルトでモノリシックな構造になるのを積極的に防ぎ、よりモジュール化され、保守しやすいコードベースを育成します。Bhosale氏のプロジェクトとその進化に関するさらなる洞察については、K10s GitHubリポジトリをご覧ください：shvbsle (Shiv Bhosale) / k10s - GitHub。

AIが生成したコードの「自由さ」という認識は、危険なほど欺瞞的であり、直接的に蔓延するスコープクリープにつながります。Claudeが50の機能を50の独立したセッションで魔法のように生み出せるように見えるとき、継続的により多くの機能を追加したいという衝動は抑えがたくなります。この急速なベロシティは、最初は爽快ですが、増大する技術的負債を隠し、開発者を際限なく拡大するプロジェクトへと誘い込みます。

新しい機能は、その作成がいかに些細なものであっても、重大な隠れたコストを伴います。 - 長期的なサポート - 包括的なドキュメント - 予期せぬエッジケースの処理 - ユーザーの認知負荷の増加 Bhosale氏のK10sは、50の機能が崩壊した状態で、この落とし穴を如実に示しています。ベロシティのトリックは、アーキテクチャのない無秩序な拡大の真の負担を隠していました。

この陰湿な拡大に対抗するため、開発者は厳格な境界線を設定する必要があります。Shiv Bhosale氏は、自分が誰のために構築していないのかを明示的に定義し、負の制約を設定しました。その後、彼はこれらの明示的なスコープ制限を`Claude MD`コンテキストファイル内に直接コード化し、AIが既存の機能を再構築したり、プロジェクトの範囲を超えて拡張したりするのを防ぎました。この積極的な制約により、AIの速度が、管理不能な機能の無秩序な拡大を生み出すのではなく、正確に定義された目的に役立つことが保証されます。

AIを使った「バイブコーディング」とは何ですか？

プログラマーがClaudeのようなLLMを使用して、厳密に事前定義されたアーキテクチャ計画なしに、高レベルのプロンプトや「バイブ」に基づいて機能を生成する、迅速な開発スタイルです。

なぜAIは「ゴッドオブジェクト」を作成するのですか？

AIは機能的なソリューションへの最短経路を選びます。すべての状態とロジックを単一のオブジェクトに詰め込むことは、新しい機能のプロンプトを満たす最も簡単な方法であることが多く、長期的な保守性については無視されます。

開発者はAIコーディングの落とし穴をどのように回避できますか？

コアアーキテクチャを手動で定義し、明確なスコープ境界を設定し、AIを自律的なアーキテクトとしてではなく、明確に定義された小さなタスクを実装するためのツールとして使用することによってです。

Shiv Bhosaleとは誰ですか、そしてK10sとは何ですか？

Shiv Bhosale氏は、この経験を共有した開発者です。K10sは彼のプロジェクトで、GPU対応のKubernetesダッシュボードです。彼は、最初のAI生成バージョンがアーキテクチャ上の問題で失敗した後、これを成功裏に再構築しました。