コードは負債である（Code is Debt）
(tornikeo.com)- AIコーディングツールの使用は、コード負債を増やす行為である
- 同じ製品と売上を持つ2社のうち、100万行のコードを持つ会社よりも、10万行のコードで運営される会社のほうが、はるかに理解と修正が速い
- つまり、コードが多いほど負債が積み上がるという意味であり、AIによるコード生成は生産性を高める一方で、同時に負債を増やす行為とも解釈できる
- 負債には肯定的/否定的な両面性がある
- 肯定的: 短期間での急成長を可能にする
- 否定的: 長期的に管理に失敗すると、プロジェクトの**崩壊リスク** を招く
- つまり、負債は良くも悪くもなり得て、利子がある場合もない場合もあり、急成長を可能にする一方で、プロジェクトを崩壊させることもある
- 重要なのはツールを使うかどうかではなく、責任を持って管理する姿勢である
- ツールへの容易なアクセス性を確保しつつ、生成されたコードの品質と長期的なコストを考慮する必要がある
5件のコメント
コードが非常に長くても、「何をしているのか」を簡単に説明できるなら負債ではありません。
AIの無分別な使用はそれを難しくするため、負債を生むという話です。
コードは負債である (Code is Debt)
https://github.com/kelseyhightower/nocode
本文には明確に記されていないのですが、AIでコードを書くと、人が直接書いたものに比べてなじみがなく、そのため負債になるという意味とも考えられるのではないでしょうか？
Hacker Newsの意見
表面的にコード行数（LOC）ですべてを測るやり方は断片的だと感じる。Company Aが100万行のコードをはるかにクリーンに整理し、文書化しているなら、10万行の不十分に書かれたCompany Bより良い状態だと言える。重要なのはコードではなく複雑性であり、行数は複雑性を大まかに測る指標にすぎない。コードは資産だ。ソフトウェア会社の成果物であり資産だ。もちろん資産が多ければ複雑性も上がるが、それはあまりにも当然の話だ。アメリカの高速道路網が保守しにくく複雑だからといって、全面的に否定的に見ることができないのと同じだ。AIの話は脇に置くとしても、結局著者の主張は「複雑性は少ないほどよい」という基本的で誰でも分かる結論だ。だからこの記事の最も重要な要点は「AIコーディングツールが不要な複雑性を完成コードに加えていないか、必ず確認せよ」という程度に圧縮できる
むしろ複雑性はここでの核心的な争点ではないと思う。すでに生き残っているソフトウェアビジネスがあると仮定して逆に考えると、すべてのコスト（購入、賃金など）は原則として可能な限り下げるのが最善だ。複雑性は単純さより悪いと言われるが、それは本当に複雑だと高くつくからだ。しかし最終的に重要なのは、短期であれ長期であれ、資本的であれ運用であれ、コストそのものだ。LLMが生成したコードがコストを下げるのか、あるいは上げるのかが本当の問題だ。コードの規模、複雑性、そしてOPやあなたが挙げていない無数の変数がすべて重要だ
私は自分の関数の複雑性をcyclomatic complexityで見るほうだ。SwiftLintで複雑性を測定して、基準を超えたら表示されるようにしている。たまに適当に分割することもあるが、たいていはもっと単純にできる方法を必ず探そうとしている。私のファイルはかなり長いが、コメントとコードの比率を50:50くらいに合わせようと努力している。LLMに複雑性を下げてコメントを増やすよう促すプロンプトを与えれば、十分うまくやれる気がする
コードは揮発性の化学物質のように、資産であると同時に負債でもある。正しく迅速に使えば金を生むが、放置したり漏らしたりすれば負債になる。ソースコード自体が自然に劣化することはないが、組織の目標やプロセスが変わるにつれて、「目的適合性」は変化し続ける
「なぜ私たちはシンプルなソフトウェアを作れないのか？」というテーマが面白いと感じる。複雑性について「システム同士が相互作用すると複雑性が生まれる。複雑なシステムは不合理な方向へ暴走することがあり、思いがけない創造性も生まれる」という点が印象的だ
私はソフトウェアそのものが資産であって、コードが資産なのではないと思う。ちょうど高速道路の資産がコンクリートではなく完成したインフラであるように。コンクリートの品質は資産の価値低下（減価償却）や保守費用に影響し、それが再び資産価値に影響する。ここにはリスク管理の観点も必ず考慮されるべきだ
キャリアの初期には、たくさんコードを書くことが重要だと思っていた。20年経った今では、より多くのコードを削除することを誇りに思っている。セキュリティエンジニアの立場では、コードは単なる負債ではなくリスクでもある。特に外部ライブラリへの依存は大きなリスクだ。最近、同僚と一緒にRust標準ライブラリだけを使って、600行にも満たない小さなLinux init systemを書き、複数の組織の本番環境で使われている。依存関係はなく、起動も1秒未満で終わる。systemdや数百万行のCコードがなくても、アプライアンス型のLinuxサーバーは十分作れると感じた。自分で作ればコード量ははるかに少なく、システム全体を完全に理解できる
AIが生み出すコードの最悪のシナリオは、会社というより個人的なプロジェクトでより明確に見えると思う。自分がよく分かっている1万行の優れたコードを自分で書くこともできるし、その何倍も速く、2万行の問題だらけのコードを雑に作ることもできる。私はその中間でバランスを取ろうとしている。もし開発を継続的に拡張しようとするなら、最初のケースで費やした時間は結局損になると思う
中間点は常に存在すると思う。私の場合、実際のコード生成をAIに任せたのはBashやPythonスクリプトのような自己完結型のコードに限られていた。こうしたスクリプトはコマンドラインとだけやり取りするので境界が明確で、管理しやすかった。こういうコードは一度書いた後、二度と見ていない。しかしコアな業務ドメインコードをAIで生成するのはあまり意味がないので、そうしていない。どうせコードレビューは必要だし、本当に自分が必要としているのはコードの保守性を検証できることだ。コードをそのまま捨てられるか、簡単に確認するだけで済む状況でないなら、コード生成ツールを使う必要はない。もしAIがプロダクトオーナーの役割を果たし、実質的なビジネス損失を理解して改善までできるなら話は別だが、そのときはむしろユーザーがいなくなるリスクまで心配しなければならない
私もAIにあまりにも多くのコードを信じて任せたときはいつも、いずれ失われた生産性の代償を痛感することになった。もしすべてがvibe coding（その場その場でAIに好みどおり書かせること）でできたアプリなら、最も必要な能力は「本当にこの機能が必要だったのか？」を判断する力だと思う。スパゲッティコードのデバッグで、一行一行が何をしているのかまったく把握できないのは本当につらいはずだ
最初のケースで時間を失ったと言っているが、二番目（より悪いコード、より速い時間）のケースも結局は時間の損失だ。本質は中間地点を見つけることにあると思う
簡潔すぎて変数名が悪かったり、妙に賢しらったコードは、冗長でもよく文書化され、変数名が豊富なコードに比べるとはるかに劣る。負債は結局、コードを理解し、変更し、拡張するのにかかる時間に比例する。コード行数は負債を完全に測定できる指標でもない。本当にすべての条件が同じなら、コード量を減らすことで読みやすいコードが犠牲になり、負債がむしろ増えることもある。だから「理論の欠如こそが負債だ」という主張のほうが正しい気がする。むしろ短いコードそのものがLLMの観点では負債になりうる。LLMの利用が理論構築を最小化してしまうからで、これはAIがプロジェクト全体についての理論を自ら構築し、それを適切にエンジニアへ伝えられない現状では特にそうだと思う
私はプログラミングを理論構築の過程として見るのが好きだ。特に業務用プログラムの場合、その理論はビジネス中心であるべきだ。たとえば「このコードベースに開発者を簡単に採用できるか」「事業モデルはどれほど安定しているか」「各機能のビジネス上の重要度はどうか」といった観点が必ず入るべきだと思う
ふとアイデアが浮かんだ。AIにコード内の変数名や関数の説明を尋ねることはできるのだろうか。私はこれまでコード生成にしかAIを使ったことがない
長く在籍していた会社の中には、自前のコード資産はないが、中核事業が外部のサードパーティ製エンタープライズサービスに依存しているところもあった。ここで気になるのは、この場合実際にどれだけのコードがあるとどう測るべきかということだ。たとえばレガシーSaaS事業者に依存しているなら、向こう側のコード行数までこちらの負債と見なすべきなのか悩む
私の見るところ、サードパーティのサービスに依存するとき最大のリスクは、相手が倒産したり、買収や合併でサービス条件が変わったりすることだ。多くの場合、資金力だけはあるスタートアップで、サービスがまだ自立できていない状況なのに、こちらがそれを使わなければならないことが多い
この点には完全に同意する。以前の会社でメールマーケティングSaaSを使っていたが、私たちが書いた統合コードはたった500行だったにもかかわらず、サービスの問題が多くて火消しに非常に苦労した。結局、必要な機能だけを別途作り直してインハウス化したところ、コストも苦労も大幅に減り、コード行数は約3000行増えた
よく分からない。
コードが明らかに資産であることは確かだが、ハードウェアと同様に、さまざまな原因（欠陥、ソフトウェア/ハードウェア業界の変化など）で価値は減価償却される。ソフトウェアコードが増えるほど、毎年償却しなければならないコストが上がる。十分に管理しなければ（たとえば開発者数に対してコードが多すぎるなど）、後になって問題を修正するコストが指数関数的に増える。減価償却という概念に「利子」がつくようなものだ。だから「負債」という表現を使うのは理解できるが、完全に一致する概念ではない
もちろん最も完璧なリポジトリはこれだと思う
以前は月にマイナス2万行のコードを削除するのが自慢だった。数年前、20人のリモート開発者チームとそれをもう一度やろうとしたが、プルリクエストが殺到してとても追いつけなかった。今はClaude CodeやGPTとペアプログラミングしていて、完全に後者の感覚だ。ここには賢いリファクタリングの機会があると思う。ただ、もっと多くのコンテキストが必要そうだ。CursorとClaude opus 4.1でレガシーコードにこういうことを試してみたが、100万トークンでも足りなかった。おそらく個人LLMと共有LLMの間を翻訳するような形にすればどうかと思うのだが、こういう経験のある人がいるのか気になる
「機能Xを完全に実装するのに絶対的に必要な最小コード量はいくらか？」という非常に重要な問いを、誰もあまりしていない気がする。もちろん正確に答えるのは不可能だが、こう考えること自体が効率的なマインドセットを生む。一方で人々は、実質的には重要でない形式検証などに関心を持ちがちだ。形式検証は、最小実現コード量を考慮しなければ、むしろ無駄で無意味になりうる。そして普通はエンジニアの書いたコードはすべて良いものだと思われがちだが、実際には大半が不要な抽象化と複雑性を追加して、かえって仕事を増やしている。ソフトウェアエンジニアリングのかなりの部分は、むしろマイナスの価値だ。もちろんプラスとマイナスが混在しているので、だからこそ判断がより難しい