AIでコードが増えていくこの時代に、メンテナンスコスト削減にもAIを

AIにIssueを渡してPRを作らせたり、夜中に作業を進めてもらったりすることが当たり前になり、実装速度が上がっている実感はかなりあります。

一方で、実装速度が上がるほど気になることは、このままのペースで増やしたコードを、来年も同じように直せるんだろうか？という点です。

AIコーディングの話では「どれだけ速く作れたか」が目立ちます。
でも、その裏側にあるメンテナンスコストの存在は忘れられがちです。私も忘れがちです。

圧倒的なスピードでコードを積み重ねる体験はAIコーディングハイです。

しかし、ここを見ないまま生成速度だけを上げると、未来の変更コストを積み増しているだけになりかねません。
最近の課題意識の大部分はこの点にあります。

たとえば、AIで2倍速くコードを書けるようになったとして、AIが書いたコードの保守性が人間と同じでも、総量が増えればメンテナンスの総量も増えます。

近い話として、Addy Osmaniが紹介している認知的降伏（cognitive surrender）があります。
AIに作業を任せつつ判断は自分で持つのがオフローディングだとすると、降伏はAIの出力をそのまま自分の判断として受け入れてしまう状態です。

理解していない差分が増えると、それも後からメンテナンスコストとして返ってきます。

AIをコードベースの掃除に使う

ソフトウェア開発のコストは書く瞬間だけで決まりません。
長く効いてくるのは、書いた後のコストです。

こういうものが少しずつ増えると、あとからチーム全体の速度を削っていきます。
さらに、AIによってコードが一気に増えるようになると、その影響も早く大きく出ます。

だからこそ、AIにやらせるべき仕事はコードを増やすことだけではありません。
新機能の実装だけでなく、既存コードを直しやすくする作業にもAIを回す方が健全に感じます。

自分の環境でも下記スライドで紹介した仕組みを元にして、毎朝AIにリファクタリングやルールファイルとの差分修正を行う自動パイプラインを走らせています。
上記リファクタリングの自動PRパイプラインは、ここ数ヶ月で一番作って良かったです。

大規模なリファクタ以外は、ほぼバックグラウンドで動くAgentic Workflowに任せていますが、勝手にコードベースがクリーンアップされて、毎朝PRが届くのは家事代行みたいで良い体験です。

循環的複雑度や認知的複雑度のようなメトリクスを見て、複雑になりすぎた箇所を見つける。
ルールファイルやガイドラインとの差分を見て、違反している部分を直す。

どのメトリクスを見るべきか、何を違反として扱うべきかはまだ試行錯誤中です。

AIでコードを増やすだけでなく、AIでコードベースのクリーンアップを自動で行う。
個人的にはこういう使い方をもっと増やしたいです。
人間が気づいたときに掃除するだけではなく、今は毎日自動で少しずつ改善することも現実的です。

この辺りは試行錯誤ですが、例えば認知的複雑度なども見ながら、ある種機械的・システム的にコードベースを管理していくアプローチは、これだけコードを高速に積み増せる世界では考えてみてもいいと思っています

AIで速くコードを増やすだけだと、メンテナンスコストは人間側に残ります。

大事だと感じるのは、単発な仕組みで終わりにせず、自動的に直していく仕組み自体も合わせて設計することです。

PR数や実装時間の短縮だけを見ていると、Agentic Engineeringは「どれだけコードを増やせたか」に寄っていきます。

しかし、ソフトウェア開発のメンテナンスコストを下げるためにも、AIに頼む仕事も変える必要があります。
テストは増えたか。不要なコードは減ったか。次の変更で触る場所は減ったか。
AIコーディング考える時は、そういう観点も持っておきたいです。

そのためにも、テスト、型、lint、スクリーンショット、E2Eのような検証手段と検証ループをAIに渡す必要があります。

こうした検証手段をAIの作業ループに組み込むことで、AIは検証しながら変更する存在になれます。
やはりAgentic Enginneringはルンバに似ている..

AIコーディングはどれだけ速く書けるかに注目されがちです。
でも、ソフトウェア開発の本当のコストは、書いたあとにやってきます。

AIを使うたびに、テストが増える。
ルールが更新される。
自動的に構造が改善される
結果として次の変更で触る場所が少し減る。

そうやって、AIを使うほどコードベースが直しやすくなる状態を作りたいです。
メンテナンスコストを忘れたAIコーディングハイは、未来の自分たちに仕事を積むだけです。

AIでコードを書くのが当たり前の時代、AIがコードを書けたかではなく「その差分を未来のチームが直せるか」にも向き合わないといけないなという気持ちです。