「理解すること」が新たなボトルネックになっている件

近年のエンジニアリングにおいて、処理能力やメモリといった技術的な制約以上に、「既存の複雑なコードベースやシステムを理解すること」そのものが開発のスピードを阻む最大のボトルネックになりつつあります。

"コードを読んだ" -Mitchell Hashimoto

優れたコードには優れた理解が必要だし、エージェントには卓越したガイダンスが必要。今のソロ開発でも、自分が理解できるまで読まずに本番環境へコミットするなんて考えられない。自分のコードの結果には自分で責任を持つ。それはAIエージェントには背負えない責任だから。

新しい、あるいは現在の真のボトルネックについてもっと読みたくてたまらない！

ボトルネックはどこにあるんだ？どこだよ！？教えてくれ！証拠なんていらない、男同士、ソートリーダー同士として、全部ぶちまけてくれ！

LLMにPRの概要説明を生成させてるけど、正直どこでも不評。機械的な変更をわざわざ複雑に説明するだけで、動機が全く伝わってこないんだよね。

それに、自分でコードを理解する最大の理由はLLMが間違っていないか確認するためなのに、その理解すらLLMが生成してたら意味がない。

俺の場合、理解できないコードは捨てるという解決策に行き着いた。エージェントにコードを書かせて、読んでみて不明瞭だったり、エージェントからの過度な説明が必要だと感じたら、すぐ捨てて書き直すか自分でやる。

問題の所在には同意するけど、解決策には納得いかないな。

この問題はLLM以前からある。"動く"けど基盤となるモデルを壊すようなコードを書くこと。動いてしまうから一見正当に聞こえて、何の警告も発せられないんだ。

モデルを基準として保持している人（人間であれLLMであれ）だけが、その一見動いているソリューションがモデルを壊していると気づける。

（理論上、モデルはスケーラビリティや柔軟性といった、このコードではすぐには無効化されないシステム的特徴を維持するものだけど、当然モデルそのものがダメな場合もある）

LLMはモデルの説明をするのはそれほど下手じゃない。実際、LLMとモデルの内容を議論することで明確化できることもある。ただ、LLMは平気で矛盾した発言をそのままモデルとして維持しようとするから、信頼できる権威にはなり得ないね。

理解こそが常にボトルネックだった。LLMが作業をスピードアップさせる仕組みっていうのは、理解する時間をかけずにコードを手に入れられるからだ。もしコードを理解したいなら、LLMはむしろマイナスだよ。

LLMを使って早く進めたいなら、マネージャーのように振る舞ってLLMが何をしたかについては気にしないことだ。ただ手動テストをして、ちゃんと動くか確認さえすればいい。

問題と解決策を大枠で理解することだね。ボットが書いたコードの全行を人間が理解するなんて無理だし、持続可能じゃない。コードを書くアクティブなエージェントの数はすぐ人間を追い越すだろうし。

ここで最大の課題は、俺に言わせれば正確さじゃない。エージェントに対する信頼感、つまり彼らの意図が人間と完全に一致しているかどうかってこと。Huggingfaceでのインシデントが証明したように、今のエージェントはサンドボックス内であっても、他のエージェントと共謀して複雑なマルチチェーン攻撃ができる。

これは解決がかなり難しい問題だ。他のエージェントが必要かもしれないし、モデルを使った対抗チェックのような仕組みも必要になるかもね。片方のモデルがもう片方のミスを見つければ得をするような。

理解はずっとボトルネックのまま。

チームで開発しててもそう。

LLMと俺一人でも、やっぱりそう。

退屈だしTypeScriptを読む気力がないから、Claudeに「自分は今ゼルダのゲームの中にいて、面白い比喩しか使えない」という設定で、セキュリティコントラクトの変更を説明するアプリをまるごと作らせたよ

平均的なエンジニアがエンジニアリング・リーダーシップの課題に気づき始めているのが面白い。結局、ここがずっとボトルネックだったんだよ。

マネージャーやPMがスタンドアップ会議に出たがるのも、役員が現場から離れすぎないように口うるさく言うのも、シーガル・マネジメントが起きるのもそのせいだ。

エンジニアたちがコードに集中できないと嫌っていた上司たちの行動を、今まさに彼ら自身が体験し、エンジニアリング管理の本を読む代わりに自分たちで解決策を再発明してるんだから。