AIにコードを書かせると、なぜコードベースは崩れていくのか

AIをコードや開発に使うことを工学的観点から見るのは、フラストレーションの溜まる行為になるだろう。私は20年以上のソフトウェアエンジニアで、コードにAIを100%使うように転向した。今の時代にビジネスを回し、時代についていくには、これがほぼ唯一の方法だと感じている。人生で初めて正しくありたくないので、反対意見がある人は歓迎だ。

とはいえ、私の経験から言うと、企業やビジネスのコーディングは、安定した堅牢なコードベースであることはほとんどなかった。私たちエンジニアと、ごく一部の有能なエンジニアリングマネージャー、そしてごく少数の取締役が、コードの品質を優先させるためにビジネス上の利害と戦ってきたが、常に uphill の戦いで、品質や設計に時間をかけすぎたとして叱られることもしばしばだった。

リリースの時間的なケイデンスは、品質の高いコードとは相容れない。なぜなら、タイムボックスにできないからだ。

だから、AIはその延長にすぎない。自分のエージェントが私が良いと考える設計のコードを書くようにしているか？もちろん、絶対にそうだ！しかし、それを完全に外注しており、エージェントは自分の間違いを自分で修正する能力も完全に備えている。AIの助けを借りて、個人でもチームでもこれまでできなかったことをはるかに超えているので、自分の経験とスキルを実際のコード行ではなく、マネジメントとアーキテクチャに注ぎ込むしかないと考えている。

どうなるかは時間だけが教えてくれる。

Wallaahu aʿlam。

コード品質は問題ではない……問題になるまでは。物事が動いているように見え、速く進んでいる間は誰もが幸せだ。既存の機能を壊さずに変更できない、あるいは複雑なコードベースを読むために消費するトークンが増えるといった症状が出始めて初めて、コード品質を気にするようになる（今なら人々はAIに自分の作った混乱を修正させようとするだろう）。

これらのルールはあまりに真実なので、当たり前に聞こえる。リーダーシップに押し返して、彼らにこれらのルールを認識させる時だ。

「AIが生成する…」という記事が長持ちするかはわからない。

私がすぐに思うのは、著者が保守性の側面（DRYの欠如、循環的複雑度、不明瞭な命名、設計の悪いフローなど）を捉えるために、どのような敵対的レビューや決定論的ゲートを書いたのかということだ。

誤解しないでほしい。私が1日200件のPRを飛ばしていた頃（個人プロジェクトで、他人に押し付けることはしなかったが）、すぐに大きな泥の塊をでっち上げたものだ。しかし、今自分の資産を再生成するにあたって、(a)モデルは少し良くなっているし、(b)検証（正確性、パフォーマンス、セキュリティ、運用コスト、保守性）の周りにより多くの厳格さを加えている。簡単に解決できる問題ではないが、投機的なロケット科学ではなく、工学的な取り組みのように感じる。

多くのAI生成コードベースが実際にインシデントが多く保守性が低いことに悩まされているのは十分理解しているが、一般的なことと可能なことを区別することが重要だと思う。一方の修正は検証の厳格さを改善することであり、もう一方の修正はひどいコードを受け入れるかLLMを諦めるかだからだ。

ここでは純粋な推測だが、ふと思ったことがある。自動化プロセスが職人をどれだけ早く追いやるかの例えとして家具がよく使われるが、ある意味では自動化後も職人が生き残り繁栄する方法の例えにもなるのではないか。確かにIKEAはEthan Allenよりはるかに多くの家具を売っている。しかしEthan Allenの手作り家具ははるかに高品質で、プレミアム価格で売られている。

消費者は全面的に恩恵を受ける。余裕のある人は高品質の手作り品を買え、大多数の余裕のない人は許容品質の家具を安く手に入れられる。

純粋な推測だが、AIの普及でソフトウェアも徐々にこのように進化するのではないかと思う。多くの基本的なタスクでは、消費者はAIツールを使って基本的に自分のソフトウェアを書けるようになるだろう。高品質ではないかもしれないが、少なくとも安く速く生産でき、平均的なコンピュータユーザーが自分のマシンでやりたいことをするための障壁を大いに下げる。一方、パフォーマンスや質の高い体験が重要な特別なニーズを満たすために、少なくとも部分的に専門家が手作りした高品質ツールのニッチ市場はずっと小さくなりながらも繁栄し続けるだろう。いずれにせよ、このシナリオではSaaSの重要性と目立つ存在感は徐々に低下していくと思う。

もうそれは問題ではないと思う。ソフトウェアはブラックボックスになりつつあり、やりたいことの合理的な仕様と少しの監督と指示を与えれば、エージェントが動かしてくれる。

今は、良いソフトウェアエンジニアリング原則に従うのは得意ではない。冗長なコード、大量の重複、抽象化の漏れ、無駄なユニットテストなどで仕事をこなす。

それは問題か？長期的には問題になる、AIは自分が導入した複雑さを扱えなくなると思うかもしれないが、私はあまり心配していない。ほとんどのソフトウェアはそれほど大きくなく、エージェントは日々良くなっている。そして本当に設計を気にするなら、エージェントに自分の基準に従うよう指示するのは難しくない。

そうでないことを望むし、自分の経験と専門知識をあと数年正当化できればいいと思うが、事実はそこにある。

記事に反対はしないが、AI以前の手書きコードが脆弱でなかったという印象を読者に与えるかもしれない。

Oracle RDBMSの2500万行のコードベースについての有名なコメントがある：https://news.ycombinator.com/item?id=18442941

何百万行ものコードを持つ大企業のコードベースはどれも同じ状態に堕落する。小さなコードベースはクリーンな概念的整合性で始まる。そして、より多くの人が加わるにつれて、不可解なスパゲッティコードに必然的に腐敗していく。後から来た開発者が初期チームほどコードを気にしない、締め切り、壊すことを恐れてリファクタリングを避けるなど、様々な理由がある。

AIに脆弱なコードを作らせたくないなら、AI以前の手書きコードに適用していたのと同じ品質ゲートを適用して、すべてをクリーンに保つ必要がある。ほとんどの企業はそれをしていない。

AIが減らすものの一つは、好奇心旺盛なエンジニアがコードベースをいじくり回すことだ。それはデッドコードや最適でない構造などを見つける素晴らしい方法だ。AIではそれがすべてなくなる。

コード品質は約6ヶ月前からほとんど誰にとっても関心事ではなくなった。ソフトウェアは今やブラックボックスだ、慣れろ。