AIの罠：なぜコードを読み続けなければならないのか

最近、Abigail Haddadの「コードを読まないこと」についての記事を読み、強く同意した。ただし、コードを読む必要は依然としてある（ほとんどの場合）。

確かに、探索段階でクイックプロトタイプ、データ可視化、インタラクティブワイヤーフレームを構築してアイデアを検証する場合、「雰囲気コーディング」のアプローチは非常に強力だ。Abigailの記事が指摘するように、注意力は最も貴重なリソースの一つであり、「どのように」ではなく「何を」に集中できるなら、その方が効率的だろう。

しかし、コードを読まないことが、いつコードの制御を失うことにつながるのか？

ブラックボックス構築の隠れたコスト

構文の専門家とコードの動作をまったく知らない状態の間には危険な領域がある。コードを読むのをやめると、より良い方法を見つける機会を逃し始める。例えば、Claudeが書いているスクリプトをちらりと見て、「ちょっとここを調整すれば、このローカルツールをブラウザで動くスタンドアロンのウェブアプリに変換でき、簡略化できる。しかもWASMはクールだから過度な複雑性にはならない！」と気づく瞬間がある。

入力と出力だけを見ていると、実装を一目見れば明らかになる構造的機会を逃してしまう。動作するツールは得られるが、より良いツールを構築する方法を見る機会を失う。残念ながら、業界では動作するコード以上にエレガンスを重視することはほとんどない。幸いなことにコンピュータは高速なので、粗雑なツールでもかなり使える。

スーパーファンド遺産コードベース

しかし、より大きなリスクは設計改善やクリーンコードの記述を逃すことではない。問題はシステムの長期的なアーキテクチャと、タールピットへの高速道路を突き進むことにある。

レガシーコードベースを経験したことがあるだろう。それらは成長し、複雑になり、最終的には元の開発者でさえ触るのを恐れるほど絡み合う。単純な変更が高コストでリスクの高い作業になる。

AIを使えば、技術的負債を蓄積する新しい、はるかに速い方法が得られる。記録的な速度で「スーパーファンド遺産コードベース」を作成できる。

コードを読まなければ、設計判断を下しておらず、AIに委ねていることになる。コードを読まなければ、本質的にAIに理解できないシステムを設計させている。システムは複雑性を蓄積する傾向があり、生成AIは生成は得意だが削除は苦手だ。

やがて成長するシステムは複雑性の限界に達する。AIがすべてを壊さずに変更を確実に行えなくなるポイントだ。人間とそのコードにも同じ限界があるが、熟練した人材がいればより多くの複雑性を維持できる。AIは速いが、いつかはそうではなくなる。

タールピットを避ける

監督なしの雰囲気コーディングは技術的タールピットへの一方通行チケットだ。コードを読まなければシステムの理解が減る。AIを使って加速すればするほど、最高のLLMでも解きほぐせない複雑性のレベルに加速しているかもしれない。

Abigailの言う通り、すべての文脈で実装の詳細に注意を払うべきではない。しかし、監査にかなりの予算を費やす必要があるなら、それほど節約にはならない。

構築している基盤を理解しなければ、最終的には非常に印象的で機能的だが、結局は変更不可能な混乱の真ん中に立つことになるかもしれない。スーパーファンドサイトの浄化には数十億ドルの費用がかかり、多くの人々を傷つける。だから、コードを読むことでどれだけの時間と費用を節約できるか考えてほしい。特に重要なコンテキストでは。

何もうまくいかなかったが、それはとても美しかった。