信頼の負債とは、「バイブコーディング」をやめ、新世代のソフトウェアエンジニアリングを受け入れよう が、エージェントが生成するコードのスピードが、そのコードが信頼に値することを確かめる能力を上回ったときに蓄積するものに与えた名前である。これは独立した失敗としてではなく、トレードオフのもう一方の半分として導入されている。この記事は バイブコーディング が確かにスピードをもたらすことを認めたうえで、負債をそのスピードに真っ向から対置している——スピードはそこにあり、そして信頼の負債は猛烈に積み上がっている、と。
用法
この用語は、ある手法を断罪するためではなく、文脈を区別するために使われている。一度きりのスクリプトやプロトタイプについては、この記事は感覚に任せて作業することを問題ないどころか魔法のようだとさえ扱っている。同じやり方を、信頼性が求められる長期にわたって使われるソフトウェアにとって維持不可能にしているのがこの負債であり、記事はそれをペイントソフトで海を渡る橋を設計することにたとえている。
負債がどのように生じるかについての説明は、制約がどこにあるかをめぐるものである。人間がコードを 1 行ずつ打ち込んでいた間は、出力量に対する物理的な限界が、図らずもコンテキストを吸収し、アーキテクチャ上の境界を検討し、裏で品質チェックを走らせるための時間を生み出していた。生成がボトルネックでなくなると、人間の注意力とレビューの帯域幅が制約となる——このウィキが別の箇所で名づけている レビューのボトルネック である。そして従来の対応——プルリクエストを開き、差分を読む——は、複数のマイクロサービスにまたがって数秒で生成され、スキーマ変更や新たな依存関係を含む数百行のコードに対しては機能しなくなる。記事の描写によれば、後に残るのは局所的には過剰に最適化され、全体としては一貫性を欠くコードであり、そうではないことを誰も確かめていないということこそが負債なのである。
この用語は、慎重さを促すものではなく、エンジニアリング上の取り組みを動機づけるものとして提示されている。同じ記事は後に扱うテーマの 1 つとして信頼エンジニアリングを挙げ、その仕組みとして AI 時代のための 3 次元の部品表を提案しており、全体としての答えを、体系的なエンジニアリング上の制約を通じて、人間とエージェントの混成チームから信頼に足るソフトウェアを届けることとして位置づけている。
どの程度確立しているか：これは一人の著者による捉え方であり、著者自身のコラムの第 1 回で述べられたもので、計測された知見ではなく診断として提示されている。記事は負債の計測値も、それを観察する方法も示していない。
関連用語
- 検証負債 — 密接に隣接する、検証されていない出力のコスト
- 理解の負債 — チームの誰も理解していないコードのコスト
- レビューのボトルネック — この負債がその背後に蓄積するとされる制約
- バイブコーディング — そのスピードの裏返しがこの負債である実践