アリババエンジニアリング、AI 编程時代の認知・意図の負債を指摘

当理解成为瓶颈：AI 编程时代的认知债与意图债

原创 聂晓龙 2026-07-28 18:18 浙江

这是 2026 年的第 42 篇文章

（本文阅读时间：约 20 分钟）

失传的大马士革钢

公元前 5 世纪的印度，工匠们用坩埚炼出被称为「乌兹」的钢锭。这些钢锭经过中东铁匠反复锻打，成就了冷兵器时代的巅峰——大马士革刀。

然而到了十八世纪，这门传承了两千年的技艺却在短短几十年间彻底失传。当时的铁匠们依然守着祖传的口诀，一丝不苟地重复着每一个动作，却再也锻造不出那种无坚不摧的锋芒。

直到二十世纪末，现代冶金学才揭开谜底：那神话般的性能，源自特定矿脉中微量的钒、钼杂质在锻打过程中析出的碳化物纳米结构。真正致命的是，从头到尾没有人真正理解它「为什么」如此出众。工匠们拥有完整的流程和炉火纯青的手感，但那份理解只存在于他们机械的敲打之中，从未被真正看懂。

当矿脉采尽、那个谁也没留意的隐藏变量悄然改变时，只会重复却无法解释的铁匠们，便再也无力回天。

从生成代码到理解代码

Programming should be regarded as an activity by which the programmers form a theory of the matters at hand, rather than the production of a program and certain other texts.

-- Peter Naur《Programming as Theory Building》

译：编程应被视为程序员对所处理事务建立起一套「理论」的活动，而非对程序及其他文本的生产。

半个多世纪后的软件领域，同样的故事正在重演。当 AI 以远超我们阅读的速度生成代码时，我们正越来越像那些只会重复配方的铁匠：系统运行良好，功能不断交付，可一旦追问「这里为什么这么设计」、「换掉它会发生什么」，我们却陷入沉默。

写代码从未如此之快，真正的瓶颈却悄然从「生产代码」转移到了「理解代码」。早在 1985 年，Peter Naur 在《Programming as Theory Building》中就提到：程序的本质不是代码文本，而是程序员脑中那套「理论」；当掌握理论的人离散，程序便「死」了，哪怕代码一行未改。

刀，还是那把刀的样子。而当理解成为瓶颈，我们迟早要面对那个悄悄堆积起来的账单——软件世界把它叫作「债」。

「理解」こそがボトルネック：AI プログラミング時代の認知債務と意図債務

ソフトウェアの負債は、もはや新しい話題ではありません。

ソフトウェア工学における負債の概念は、すでに 50 年以上前にさかのぼります。フレッド・ブルックスが『The Mythical Man-Month（ミステリアスなマンマンス）』で指摘したソフトウェアの複雑さや、ロバート・C・マーティンの『Clean Code（クリーンコード）』『Clean Architecture（クリーンアーキテクチャ）』といった名著が教えるのは、すべてこの複雑さをどう制御するかという知恵です。そして、その複雑性を適切に管理し隔離できなくなった結果、後続のイテレーションに影響を及ぼすようになったものが、まさにソフトウェア工学における「技術負債」なのです。

ウォード・カニンガムは、未完成のリファクタリング作業を「借金をすること」と表現しました。マーティン・フローワーも『Refactoring（リファクタリング）』の中でこう述べています。「多くの企業は、効率的に機能するためにある程度の負債を抱える必要がある」。

しかし、負債が生じることを否定する必要はありません。遠く離れたアメリカでは、ドル、米国株、米国債という 3 つの柱が世界最大の金融帝国を支えていますし、中国政府債務も今年 5 月末には 100 兆元を突破しました。ソフトウェア開発の世界でも、私たちはしばしば借金をしながら前進します。重要なのは、負債率を適切にコントロールすることです。負債そのものは恐れるべきものではありません。

「理解」こそがボトルネック：真の課題か、それとも偽りの目標か

過去のソフトウェア負債については、誰もが深い共感を抱いています。前人が遺した「伝説のコード」に対し、私たちができるのは愚痴をこぼすか、「汚い床に花を飾る」ような無理なリファクタリングを行うことくらいでした。

しかし、AI を活用するプログラミング時代には状況が一変します。人間にとっては耐え難いほど複雑な多層構造の条件分岐や、無限にネストされた関数コールバックといったコードも、機械にとっては扱いやすいものになり得ます。何より重要なのは、実際にコードを書き下す主体がもう人間ではないということです。

英伟达（NVIDIA）の黄仁勲氏は度々、「具体的なプログラミング技術を学ぶ必要はない。AI こそがプログラミング技術であり、自然言語こそがプログラミング言語である」と述べています。もちろん、トークン供給側の立場にある黄氏が発する言葉には、先ほど触れた「ループ・エンジニアリング」のようにトークンビジネスの側面が含まれている可能性も考慮し、批判的に受け止める必要があります。

エリック・マスキルの提唱する「第一原理思考」に立ち返れば、「理解すること」こそが追求すべき核心ではありません。真の目標は、私たちの要求を達成できるかどうかです。負債が生じることを認め、コードの意味を完全に理解していないことさえも認めた上で、大模型の能力が向上し続ける中で、シンプルなプロンプト（指示）だけで必要なソフトウェアが構築できるようになるなら、「理解」は本当に重要なのでしょうか？

「バイブコーディング」が世界を席巻する

「バイブコーディング」と呼ばれる新しいプログラミングの形があります。これは、その場の雰囲気や直感に身を任せ、指数関数的な可能性を信じ、コードそのものの存在さえも忘れてしまうようなスタイルです。

—— アンドレイ・カルパティ（Andrej Karpathy）

2025 年 2 月、OpenAI の共同創設者であるアンドレイ・カルパティ氏が X（旧 Twitter）でこの言葉を発したことで、「バイブコーディング」が正式に誕生しました。その後、瞬く間にテック界隈の流行語となり、コリンズ英和辞典では「2025 年の年間単語」にも選出されました。

低コスト・高速化・自然言語による駆動といった特徴を持つこの手法は、開発者の役割を「現場で手を動かす職人」から「要件を指示する発注者」へと変えました。プログラミングの知識が皆無な人でも、ゼロから一まで迅速に完全なソフトウェアを構築することが可能になったのです。

歌手の胡彦斌氏が、バイブコーディングを活用してファン向けに開発したインタラクティブコミュニティアプリ「彦火（Yanhuo）」はその好例です。iOS と Android 両プラットフォームに対応し、AI プログラミングツールを用いてわずか一ヶ月で開発と改善を完了させました。彼はまた、SNS で「バグ修正の日々」をユーモアを交えて更新。自然言語による指示で AI がコードを生成し、アーキテクチャの設計からデバッグ、デプロイに至るまでの全工程を自ら体験した様子を公開しました。

最近、ネット上で話題となったインタビューの内容は、「理系人材の使命はすでに完了した。AI 大モデルを生み出したのは彼らだが、これからは自然言語でシステムを駆動する時代であり、文系出身者の方が優位に立つだろう」というものでした。バイブコーディングには現在も多くの課題が指摘されていますが、それでも「理解していない」という前提条件のもとでは、一定の目標達成が可能であることは否定できません。

Grok が描く、バイナリ直接生成の未来

2024 年、東京大学の研究チームは、人型ロボットが運転席に座る形で自動運転を実現する技術を開発しました。このロボットは、生体模倣型の骨格と筋肉システムを備え、高精度カメラを搭載。手足には高感度センサーが配置されており、車両自体の電子システムを複雑に改造したり、高額な外部センサーキットを取り付けたりする必要はありません。人間の運転判断や操作行動を模倣するだけで、完全自動運転を実現します。

このニュースを聞いた当初は不思議に思いました。車そのものが一つのシステムであり、システム間であれば電気信号による通信で十分です。わざわざ物理層を介在させる必要はないはずです。

現在のコンピュータプログラミングの世界では、システムは 0 と 1 の機械語で動作しますが、人間が直接機械語を書くことはできません。そこで人類はプログラミング言語とコンパイラを発明し、コードを機械語に変換して実行できるようにしました。そして今、AI が参入しています。しかし AI システムがコンピュータに直接接続するわけではなく、人間と同様にコードを生成している点では、本質的な生産プロセスは変わっていません。単に、ある工程の担当者が「人間」から「AI」に入れ替わっただけなのです。

もしかすると、今年末までにはコーディング自体をする必要もなくなるかもしれません。AI がコンパイラよりも効率的に、直接バイナリを生成するようになるのです。

—— イーロン・マスク

もしかすると今年末には、コードを書く必要すらなくなるかもしれません。AI が直接、どのコンパイラーよりも効率的なバイナリファイルを生成するようになるのです。

この考え方は、2026 年 2 月に xAI の全社員向けイベントで語られたマスカの発言に由来します。「AI はソースコードを飛び越えて、直接バイナリを生成する」というものです。これが本当に実現するかどうかは定かではありませんが、東京大学の自動運転技術や、「AI を知らない人々が単なる検索エンジンとして扱っている現状」を比較すると、現在の模式では AI が既存の工程の一部だけを効率化するに留まり、これは「AI ネイティブ」とは言い難いことがわかります。

マスカの言う通り、バイナリ直接生成が最終形となるなら、AI は単に生産ラインの特定の作業員を置き換えるのではなく、ラインそのものを再構築することになります。もしこれが現実のものとなれば、ソフトウェアエンジニアにとって「理解」などという概念はもはや無意味なものとなります。なぜなら、「ソフトウェアエンジニア」という存在自体がなくなるからです。

05

「理解」は何を決めるのか？

カナダのコンピュータサイエンティストであり、ビクトリア大学のソフトウェア工学教授であるマーガレット＝アン・ストーニー氏は、自身が教える起業家育成コースで、AI 活用によるプログラミングの典型的な問題に直面しました。学生チームは AI を駆使してソフトウェア製品を開発し、機能の実装やマイルストーン達成を迅速に行うことができました。しかし、8 週目になるとあるチームで問題が発生します。簡単な修正が予期せぬ場所でシステムを壊し、開発が立ち往生してしまったのです。

当初は、この問題の原因を前期のスピード重視の開発が生んだ技術債務——混乱したコードや急ぎで作られた実装、アーキテクチャ上の妥協点——だと考えていました。しかし分析が進むにつれて、別の問題も浮き彫りになります。チーム内の誰も、なぜ特定の設計判断がなされたのか説明できず、システムの各部分が本来どのように連携すべきかも把握できていなかったのです。コード自体は確かに混乱していましたが、より本質的な問題は、チーム全体で共有していたシステムに対する理解（理論）が静かに崩壊してしまったことにありました。

三元債務モデル（Triple Debt Model）

マーガレット＝アン・ストーニー氏は『From Technical Debt to Cognitive and Intent Debt』において、生成 AI がソフトウェア工学の課題を消し去るものではなく、その性質を変化させるだけだと指摘しています。彼女は AI によるコーディング時代におけるソフトウェアシステムの債務を、以下の 3 つに分類しました。

技術債務 (Technical Debt)

技術的負債は、三つの負債の中で最も馴染み深いものです。それはコードの中に存在します。

1993 年、ワード・カニンガムが初めて「負債」という言葉を使って、納期に追われて後回しにしたコードを表現しました。その後、ケント・ベックやマーティン・ファウラーらが、テスト駆動開発（TDD）、リファクタリング、コードレビューといった一連の返済ツールを整備しました。

技術的負債がそれほど暴走していないのは、それが「見える」からです。測定しやすい循環複雑度や重複コード率といった定量的な指標もあれば、過度な設計や論理の不明瞭さといった定性的な人為的な複雑さも含まれます。しかしプログラマーはこれらの問題を明確に認識しており、デザインパターンや関心の分離、複雑性管理などの手法を通じて、少なからず改善をもたらすことができます。

生成 AI は技術的負債を減らす一方で、認知負債と意図負債の蓄積を加速させる可能性があります。

-- マーガレット＝アン・ストウリー『技術的負債から認知負債と意図負債へ』より

訳：生成 AI は技術的負債を軽減する一方、認知負債と意図負債の蓄積を加速させる可能性がある。

AI によるプログラミング時代において、技術的負債は管理しやすい負債と言えます。コードの難易度に応じたリファクタリング、単体テストの自動生成、コードロジックの説明、AI を活用したコードレビューなど、これらは大規模言語モデルが得意とする領域です。もちろん、これが重要でなくなったわけではありません。むしろ、ソフトウェア工学において継続的に戦わなければならないエントロピー増大の要因であり続けます。しかし AI 時代においては、認知負債と意図負債に対して、より一層警戒を怠ってはいけません。

認知負債（Cognitive Debt）

技術的負債がコードの中に存在するのに対し、認知負債は「人」の中に存在します。それは特定の個人が一時的に理解できないという問題ではなく、チーム全体としてのシステムに対する「共有された理解」が欠落している状態を指します。

誰一人としてシステムのすべてを理解する必要はありません。ソフトウェアは常に、「十分な量の共有理解」によって、人々とドキュメントの間に分散して運用されています。認知負債とは、まさにその共有理解に生じる、そして蓄積していく空洞のことです。

開発者がゼロからコードを書く場合、たとえ汚いコードであっても、その摩擦や労力を通じて、少なくとも部分的なメンタルモデル（心の中のモデル）を構築することになります。しかし AI が同じコードを生成した場合、開発者はその理解度を維持せずにコードを受け入れてしまう可能性があります。

-- マーガレット＝アン・ストウリー『技術的負債から認知負債と意図負債へ』より

訳：開発者がゼロからコードを書く場合、たとえ汚いコードであっても、その摩擦や労力を通じて、少なくとも部分的なメンタルモデル（心の中のモデル）を構築することになります。しかし AI が同じコードを生成した場合、開発者はその理解度を維持せずにコードを受け入れてしまう可能性があります。

この形成メカニズムこそが最も危険です。自分で一行ずつコードを入力しているとき、たとえコードの質が悪くても、「つまずき」や「苦労」というプロセス自体が、システムに対するメンタルモデルの構築を強要します。しかし AI が同じコードを生成して提示した場合、開発者はそれをそのまま受け入れてしまい、理解を深めるプロセスを経ないまま進んでしまいます。

例えば、5 年前に誰かが作成したコードベースを引き継いだとき、頭が真っ白になる経験をしたことがあるでしょう。あるいは「すべて適用（accept all）」ボタンを連打して 5 日後には、プログラムが実際にどのように動作しているのかさえもわからなくなってしまうケースです。

意図負債（Intent Debt）

「意図の負債」はコードの中にも、人の頭脳の中にも存在しません。それは製品の中にあります——要件定義書、アーキテクチャ決定記録（ADR）、実装計画、テストケース、仕様書などです。

意図の負債とは、システムの進化を導くべき目標や制約、そしてその理由が、最初から明確に表現されず、人間も AI も参照できる何らかの製品に記録されないまま、静かに積み重なっていく借金のことを指します。頻繁な確認が必要になったり、技術的には正しいが文脈にそぐわない回答を求められたり、コンテキスト不足のために予想以上のトークン消費が発生したりする時、それは意図の負債が顕在化した兆候です。

将来を見据えれば、開発者の核心スキルはコードを書くことではなく、「システムが何をしているのか」「なぜそうしているのか」「そしてどう進化できるのか」という正しい理解を維持し続けることにあるでしょう。

—— Hicks『The New Developer』より（意訳）

コードに込められた「意図（intent）」とは、単なる「このコードは何をしていて、どのように実装されているか」ではありません。それは「当初なぜそうする決断を下したのか」という理由です。生成 AI 登場以前であれば、その「なぜ」は必ずプログラマーの頭の中で一度は処理されていました。たとえコメントを書くのが面倒で省略されたとしても、その理由は少なくとも人間の記憶の中に残っていたのです。

しかし、AI がコードを生成する時代になると、その判断や妥協点はモデルが「統計的に最も妥当な続き」を選んだ瞬間に決定されます。それはコードにも記録されず、誰の記憶にも残りません——生成された瞬間に消えてしまうのです。

意図の負債は「認知の負債（誰も『なぜ』を書かないため、新人がシステムを頭の中で再現できない状態）」を生み出します。そしてその認知の負債は、「システムを理解していないために不適切な実装をしてしまう」という技術的負債へと繋がります。これらは互いにかみ合い、増幅し合うように作用して、まるで深く沈んでいく渦のように機能します。その中心には、静かに譲渡されてしまった「理解」が存在するのです。

理解の本質は「参加するため」にある

2026 年 7 月、元 MIT 研究者で現在は Notion のデザインエンジニアである Geoffrey Litt が、「AI Engineer Conference」で以下のような見解を述べています。

「理解の本質は検証のためではなく、参加するためです。それはあなたがシステムの次の改善案を提案できる能力を与えるものです。」

時系列を 3 年前に戻ってみましょう。当時 AI は主にコード補完の役割を果たしており、私たちは確かに AI が推奨する次のコードが正しいかどうかを検証していました。

しかし、3 年後の現在では、Agentic AI の発展により、仕様（SPEC）や結果検証の基準さえ定めておけば、AI は私たちよりも優れた成果を出すことさえあります。

「私たちが理解するのは『検証するため』ではなく、『参加するため』です。システムに対するあなたの理解こそが、次のアイデアを生み出す源泉となるのです。」

—— Geoffrey Litt（AI Engineer Conference, 2026）より

では、なぜ私たちは「理解」を必要とするのか。Geoffrey Litt が示す答えは「参加するためには理解が必要だ」というものです。

AI はコードを書く行為自体を容易にしましたが、「次に何をすべきか」を考え抜く作業は、依然としてシステム全体を頭の中に描ける人間にしかできません。この結論は、Storey 教授が提唱した見解と全く同じです。たとえ成果が完璧でなくても、そのプロセスを通じて自分なりの「心のモデル（メンタルモデル）」を構築できるのです。

プロジェクトとは、「一度だけ指示を出して AI に任せて終わり」というものではありません。それは人間と AI エージェントの間で行われる、何千回という試行錯誤のループです。各サイクルが終わるたびに、人間が次の問いを発する必要があります。「もしこうしたらどうなる？」「別のアプローチを試すべきか？」。そして、その次の一歩を問えるかどうかは、頭の中にシステム全体を捉えた心のモデルがあるかないかで決まります。この心の備えがないと、指示は次第に曖昧になり、画一的なものへと退化し、最終的には創造性という舵さえも手放すことになります。

Vibe Coding の自己修正

Vibe Coding は、その手軽さと低参入障壁、そして即座に成果が出る特性から、発表後すぐに世界中で流行しました。しかし、実際に生産環境のプロジェクトに応用してみると、期待されたほどの効果は得られませんでした。なんと 95% の開発者が、「AI に生成させたコードを修正するために、さらに多くの時間を費やさなければならなかった」と回答しています。場合によっては、バグを直すのに要した時間が、本来節約できた時間よりも多くなることさえあります。あるネットユーザーは皮肉を込めて、自分たちのことを「大モデルの善後（お掃除）エンジニア」だと称しました。

Karpathy もこの問題に気づき、Vibe Coding が登場してから 1 年後、その流行に一時的なブレーキをかけました。彼は Vibe Coding を主に「面白い単発プロジェクト」「デモ」「探索的な試み」に限定すべきだと考えます。現在、AI エージェントを活用したプログラミングは、プロフェッショナルの標準的なワークフローとして定着しつつあります。

そこで Karpathy は、「Vibe Coding」という用語に代わる新しい言葉として「Agentic Engineering（エージェント工学）」を提唱しました。私たちが今まさに実践している「Harness Engineering」も、この Agentic Engineering の思想を実装した一つの形態と言えます。

You can outsource your thinking but you can’t outsource your understanding.

-- Andrej Karpathy

訳：思考は外注できるが、理解まで外注することはできない。

Karpathy は『From Vibe Coding to Agentic Engineering』というポッドキャストで、「思考を外注できても、理解を外注することはできない」という重要な視点を述べています。AI は、どの技術スタックが要件に適しているか、あるいは特定のシナリオにおいてどのアルゴリズムが最適解かを考える作業を代行できます。しかし、このシステムがなぜ存在するのか、その根底にある本質的な課題は何かを理解する作業まで AI に任せることはできません。

Karpathy は言います。「私はまだこのシステムの不可欠な一部であり、情報は私の頭の中に入ってくる必要がある」と。そして、「何をすべきか」「なぜそれを行う価値があるのか」「それをどのようにエージェントに割り当てるべきか」といった判断は、私たちの「理解力」によって制約されるのです。

06 おわりに

「債務」という言葉を初めて聞いたのは、『ゲーム・オブ・スローンズ』の中でした。「ランニスター家は必ず借金を返す」。この言葉はティリオン（小悪魔）が頻繁に口にするセリフです。ソフトウェアの世界における債務も同様で、決して消滅することはありません。ただ帳簿に記され、他へ移転され、先送りされるだけです。それは堤防を少しずつ浸食する洪水のようであり、ある日突然、取り返しのつかない致命的な災難を引き起こします。

「AI は 70% の道程を高速で達成させてくれる。残りの 30% が、熟練したエンジニアがその価値を発揮する場所だ」

—— アディ・オスマニ『The 70% Problem』より

AI によるコーディング時代において、単なるコード記述は徐々に AI に委ねられるようになりました（私はコーディングのプロセス自体を楽しんでいますが、残念なことに）。しかし、コードとは理解の「産物」であって、「理解そのもの」ではありません。システムが何をしているのか、ユーザーが何を求めているのか、将来の方向性はどこにあるのか——そうした理解こそが重要なのです。

AI は代替者ではなく増幅器です。強みはさらに強化されますが、弱点もまた拡大します。シリアス刀（ダマスカス・ブレード）はより鋭利になりますが、それをどの方向へ向けるかは、刀を握る人間が決めます。あなたが AI に置き換わらないための前提条件は、新しい理解を絶えず育み続けることにあります。

References

[01] 大马士革刀

https://baike.baidu.com/item/%E5%A4%A7%E9%A9%AC%E5%A3%AB%E9%9D%A9%E5%88%80/3915274

[02] Programming as Theory Building

https://pages.cs.wisc.edu/~remzi/Naur.pdf

[03] 《The Mythical Man-Month》

https://book.douban.com/subject/6039354

[04] 《Clean Code》

https://book.douban.com/subject/3032825

[05] 《Clean Architecture》

https://book.douban.com/subject/26915970

[06] Loop Engineering

https://baike.baidu.com/item/loop-engineering/68324937

[07] 什么是第一性原理

https://hr.edu.cn/xueshu/202502/t20250218_2655003.shtml

[08] Andrej Karpathy

https://karpathy.ai/?spm=ata.21736010.0.0.1b4a21d7q2BAI0

[09] Vibe Coding

https://baike.baidu.com/item/Vibe%20Coding/67529160

[10] Margaret-Anne Storey

https://margaretstorey.com/about/

[11] From Technical Debt to Cognitive and Intent Debt

https://arxiv.org/pdf/2603.22106

[12] Geoffrey Litt

https://www.geoffreylitt.com/

[13] AI Engineer conference

https://www.bilibili.com/video/BV1fAKg6kE8N

[14] Agentic Engineering

理解がボトルネックに：AI プログラミング時代の認知負債と意図負債

エージェント・エンジニアリングの確立

「ハルネス・エンジニアリング」への移行は、単なるツールの変更ではありません。これは、開発プロセスそのものの再定義を意味します。

従来の「バイブコーディング（直感に頼るコーディング）」から、「エージェント・エンジニアリング」へとパラダイムがシフトしています。AI が単なるコード補完の補助役ではなく、自律的なタスク実行者として振る舞う時代において、開発者が直面する新たな課題とは何か。

本稿は、著者の個人的な技術的考察と経験則に基づいています。企業の公式見解や立場を代表するものではありません。また、文中で触れられている技術動向や将来予測については、執筆時点の知見に基づく推測を含みます。読者は各自の環境や要件に合わせて、独立した判断を行う必要があります。

ご意見やご感想をコメント欄でお待ちしています。一緒に議論しましょう。

※微信（WeChat）で本文を読むには、リンク先へジャンプしてください。