私にとって、みんなが大好きな素晴らしいテストシステムを作れれば、実際にそれを使って機能を作るようになって、後回しにならないから、メンテナンスがずっと楽になるんだよね。よく「テスト駆動開発」って言われるけど、開発者体験が良くてちゃんと機能する形でやられてるのはあまり見たことがない。でも、もしそれができたら、素晴らしいプロファイリングができる。そうなれば、正確性やパフォーマンスを測れるようになるから、実装がそれほど重要じゃなくなる。そうすると、AIにコーディングを任せるのがずっと楽になるよ。

コードレビューも同じだね。AIがコードレビューをもっと見栄えよくできるか気になる。例えば、人間のコードレビューだと、開発者はコードの見た目を変えないようにすぐに学ぶんだ。コードのリフローやコメントの変更、インデントの変更（ツールが抑えられないところ）、関数の移動や行の削除、その他の無駄な変更はしないようにね。それに、無駄にリファクタリングもしないし、レビューを機能変更と見た目変更の2つに分けることもできるかも。

私の経験では、AIはメンテナンスコストを下げる。とはいえ、ここでは文脈が重要かもしれない。私は数十年にわたるプロジェクトに取り組んでいて、新しい機能開発がたくさんある一方で、古いコードやプロジェクトが急に扱いやすくなったり、近代化が進んだり、場合によっては完全に排除されたりしてる。古いライブラリやビルドツールへの依存も、更新されたり、排除されたりして、ビルドが速くなって、開発者にとっても楽になった。エンドツーエンドのテストも設定や自動化がずっと楽になった。DevOpsも大幅に改善されて、プロダクションの問題診断が劇的に向上した。たくさんのログや情報があって、重要なことをキャッチするためのダッシュボードやモニタリングもいろいろあるけど、今はデプロイしたシステムの分析がもっとできるようになったよ（約50プロジェクトくらい）。

なるほど、これは納得できる意見だね。残念ながら、メンテナンス性は「非機能的」な要件として単純に分類されてしまう。メンテナンス性（や似たような非機能的要件）は、実際には将来の機能要件を保ち、実現するために必要なものとして考えるべきだと思う。非機能的要件を「ソフトウェアがどうやってやるか」として捉えるのに対して、「何をするか」/機能要件が「本当に重要なこと」として位置づけるのとは対照的にね。その観点から見ると、プロジェクトにとって機能や改善の安定した流れが重要なら、メンテナンス性は実際には非機能的要件ではなく、機能要件に等しいんじゃないかな。

これは私にとっても正しい方向性に感じる。ここ6ヶ月間、私が開発の仕事で苦しんでいる問題の80%は、メンテナンスやレガシーコードが新しい機能開発を妨げていることだ。一部の開発者はAIを使うことに過剰に積極的で、私もその流れに乗り始めている。なぜなら、追いつく必要があるし、実際にIDEでAIと一緒に作業するのが楽しいから。自分のコードベースの部分を理解しやすく、一貫性を持たせるために多くの努力をしているけど、チームの他のメンバーからはそれが見られない。完璧ではないけど、私は一貫性がないものや、一目で理解できないものに非常に敏感なんだ。とにかく、この記事の新しい（私にとっては少なくとも）視点が好きだよ！

AIを使えば、最初に考えていなかった問題の原因をモデル化できるかもしれないと思うんだ（例えば、「すべてのバグを直さない、すべての依存関係をアップグレードしないことにした」とか）。AIツールを使うことで、「fooに関連することにどれくらいの時間を使っているか」を掘り下げて聞けるようになるのもいいよね。AIツールは、持続可能なソフトウェアの実践をどう見えるかを構築する場にもなり得るから、同じような後ろ向きな努力をする決断をしないようにできる。メンテナンスのアップデートを扱うツールを作ることもその一環だと思う。AIツールの本質は、やっぱり人間の注意管理を強化する活動に向けてトレーニング（または誘導）される必要があるってことだね。

記事のメンテナンスと機能の比率についての枠組みが、自分のワークフローで感じていることと重なるんだ。あまり注目されていない点は、AIセッションのアーティファクトの表面積がコードの表面積よりもずっと早く増えること。Claude Codeの出力が1時間あると、コードの変更だけじゃなくて、スクリーンショット、生成された画像、エクスポートされたトランスクリプト、仕様ドラフト、ダウンロードしたモデルの重みなどが出てきて、Finderがどこに落としたかも分からなくなる。メンテナンスコストの議論もここに当てはまる。適切なアーティファクトにすぐにアクセスできないと、既に持っているものを再生成したり、最悪の場合、セッション間でのコンテキストを失ったりする。作業環境の「メンテナンス」は、記事が説明している比率に対する実際の負担になる。特にファイルの問題に取り組もうとしているけど、広い意味では、AIコーディングエージェントは周囲のツール（ファイル管理、コンテキストの切り替え、アーティファクトの整理）が追いつかない限り、ネットのメンテナンスコストを減らすことはないと思う。

追加したいことが2つある。1. ソフトウェアには技術的なメンテナンスだけじゃなくて、ユーザーサポートもあって、ソフトウェアが成長するにつれて増えていく。2. メンテナンスコストが線形にスケールするとは思えない。たとえ線形にスケールしたとしても、最終的にはメンテナンスがすべての時間を占めるようになる。

彼が見逃している賭けは、多くの会社が今始めようとしているか、少なくとも考えていることだけど、AIがコーディングが上手くなるということ。だから、次のモデルやハーネスがメンテナンスの負担を引き受けるっていうのが理論なんだ。

もし著者が自信過剰にならず、主張を裏付ける本当の証拠を示していれば、これは良い文章になったかもしれないね。HNのフロントページをソースとして挙げるのは軽薄で、すぐに結論に疑いを持たせたよ。著者がこのテーマについてどれだけリサーチしたのか興味があったけど、どうやら全然やってないみたい。LLMが根拠なしに自信満々な文章を提供してきたら、どうする？