出来事の日付：2026年5月11日。 GPUを搭載したKubernetesクラスターを監視するターミナルダッシュボード「k10s」の開発者が、AIを大幅に活用して7カ月間開発してきた同プロジェクトのGo実装をアーカイブし、ゼロからの書き直しを始めた。振り返りでは、コード生成ツールによって個々の機能は迅速に実現できたものの、人間が明示的に方向性を示さなければ、持続可能なアーキテクチャは構築できなかったと論じている。

K10sは、k9sのGPU対応版として構想され、NVIDIA搭載ノード全体の割り当て、使用率、温度、消費電力、メモリーを表示する機能を備えていた。開発者によると、初期のプロジェクトはClaudeとのセッションを通じて急速に進展した。リソース表、名前空間フィルター、ログストリーミング、キーボードナビゲーション、コマンドパレットが数回の週末で組み上げられ、その後、GPUフリート専用ビューが追加された。

問題が表面化したのは、そのフリート画面から別の画面に切り替えたときだった。他のリソースビューには空または古いデータが表示され、ライブ更新は停止し、フィルター設定が画面間で漏れ出した。実装全体を読み返すと、より深刻な問題が明らかになった。単一のモデル構造体が、ユーザーインターフェースのウィジェット、Kubernetesクライアント、ナビゲーション、キャッシュ、入力処理、ビュー固有の状態をすべて抱えていたのだ。中心となる更新メソッドは約110の分岐を含むおよそ500行にまで膨らみ、それを収めるファイルは1,690行に達していた。

著者は、この結果を、目先の機能に焦点を当てた一連のプロンプトに起因するとしている。生成された変更はいずれも既存の状態を通る最短経路を取り、汎用的なリソース読み込み処理やキー処理の経路に特殊ケースを追加していった。後始末はフィールドの手動リセットに依存しており、ビュー数が増えるにつれてリセット漏れが起きやすくなった。同じキーにも、ビューごとに分離された制御ではなく平面的に並んだ条件群を通じて、異なる意味が割り当てられるようになった。

この投稿は、AIコーディングが役に立たないと結論づけているわけではない。アーカイブされたリポジトリーには、およそ30回の週末にわたって作成された234件のコミットがあり、著者は、この経験から貴重な教訓を得たと述べている。改訂後の方針では、モデルに機能の実装を依頼する前に、インターフェース、メッセージ型、所有権のルール、ビューの境界を定義する。さらに、すべてのコーディングセッションを同じアーキテクチャ上の期待から始められるよう、そうした制約を永続的なプロジェクト指針に盛り込む。

もう一つの教訓は、見かけ上の速さに関するものだ。初期の機能追加が低コストだったため、プロジェクトの範囲が拡大した。そのスピードのせいで、変更が設計全体をどう変えるかではなく、コンパイルできるか、正常系のテストに合格するかだけで判断しやすくなった。複数の機能が相互作用するようになるまで、問題は徐々に蓄積していった。

これは一人の開発者による事後検証であり、手書きのソフトウェアとAI生成ソフトウェアを比較した対照実験ではない。その実践的な意義は、監督がどこで欠けていたかを具体的に記録した点にある。開発者の結論は、モデルが個別には大規模な機能を実装できる場合でも、システムの境界、レビュー、長期的な一貫性については、なお人間が責任を負う必要があるというものだ。