ボトルネックは決してコードではなかった
(thetypicalset.com)- Codexは.txtで1年以上先送りされていた構造化生成アルゴリズム実験の最初の動作バージョンを数時間で作ったが、核心的な変化は個人のコーディング速度よりも協業のボトルネックが露わになった点にある
- エージェントが実装を担うようになると、チームの速度を遅らせるのはコードを書く人ではなく、ロードマップ、受け入れ基準、設計ドキュメントのように、エージェントがすぐ実行できる精密な仕様を作ることへと変わる
- コード作成コストが下がると、以前なら作らなかったプロトタイプや社内ツールが増える一方で、ユーザーが吸収できる速度は変わらないため、何を作るかではなく何を作らないかを決める集中の規律がより重要になる
- エージェントはSlack、PR、Issue、コミット、設計ドキュメントから暗黙の意思決定や慣行を抽出してナレッジベースを作れるが、人が直接積み上げる共有コンテキストを完全に復元することはできない
- 次の10年の優位性は、最高のモデルよりも、50人、200人、2,000人規模になっても縮小された意思決定集合に整列する組織的一貫性を維持できる会社にある可能性が高い
コーディングエージェントが変えたボトルネック
- .txtで1年以上先送りされていた実験は、構造化生成アルゴリズムとオープンソースの代替案をテストし、単に「この文字列を受理するか」ではなく「正しいトークン分布を生成するか」に近い問題を確認する作業だった
- この実験はロードマップに残り続けていたが、Codexにアプローチを30分ほど説明した後、数時間で動作する最初のバージョンが作られた
- コーディングエージェントは個人がコードを書くやり方をすでに大きく変えているが、個人の生産性向上がそのままソフトウェア産業全体の速度向上に直結するとは言いがたい
- 影響力のあるソフトウェアは多くの場合、複数人の協業によって作られるため、より興味深い分析単位は個人の生産性ではなく協業である
- ソフトウェアは、人々がシステムに何をさせるかを交渉したあとに残る結果物に近く、コードは重要ではあるが、より難しい作業の残余物である
ロードマップが限界になる
- エージェントが実装を担うチームで速度を遅らせるのは、エージェントがそのまま受け取って実行できるほど精密な仕様を作ることだ
- ロードマップ、受け入れ基準、「私たちが本当に欲しいもの」は、テストスイート、チケット、設計ドキュメントのような形で明確に書かれていなければならない
- 機能は非常に速く実装され、エンジニアが他のエンジニアを待つ代わりに、次に来る正しく書かれた仕様を待つ状況が生まれる
- ボトルネックはコードを書く人から、どんなコードが存在すべきかを決める人へと移り、これはすなわちマネジメントの問題である
安くなったコードはより多くの合意を要求する
- コード作成コストが下がると、同じ結果のために10%の労力で済ませるのではなく、以前は価値がないと思われていた結果に同じ労力を使うようになる
- 3か月前なら「時間の無駄」と見なされていたプロトタイプが午後ひとつで作られ、明確な需要のなかった社内ツールが作られては忘れられることもある
- ユーザーが吸収できる機能の速度は、チームが10個出そうと50個出そうと概ね変わらない
- Steve Jobsが1997年に語ったように、「集中とは断ること」であり、Appleはその年に製品群の約70%を整理した
- エージェントがあると新機能を出す感覚がより簡単になるため、何を作るかだけでなく、何を作らないかを決める規律はさらに難しくなる
コンテキストが中核資源になる
- 交渉と合意は、組織内の共有コンテキストの上で機能する
- コンテキストには、何を作っているのか、なぜ重要なのか、何を試したのか、誰が何を決めたのか、何が本質で何が痕跡にすぎないのかが含まれる
- チームの人間は同じ部屋にいて、同じSlackチャンネルを読み、深夜2時に同じ障害をデバッグしながら、自然にコンテキストを積み上げる
- このコンテキストの大半は文書化されておらず、シニアエンジニアがPRレビューで「これはマイグレーションを壊す」と言うときも、文書になっていないコンテキストを使っていることがある
- エージェントはそのような浸透を行えず、部屋の中にいたり、計画の会話を半分聞いたり、過去の障害の記憶を持ったりすることでコンテキストを得ることはできない
- プロンプト、ファイルツリー、ツール、明示的な指示の中に入っていないコンテキストを、エージェントは安定して保持していない
- コンテキストがなければ、エージェントは少し間違った問いに対してもっともらしい答えを作ってしまうことがある
- .txtでエージェントが有用な仕事をしたときでさえ、実際には人があらかじめコンテキスト作業をしていたのであり、その図式を次の10人のエンジニアが自動的に持てるわけではない
- 組織がこれまで常に暗黙に依存してきたコンテキストは、いまや速度を制限する入力となっており、人はその明示版を読む対象がなかったために、それを暗黙のまま残しがちである
エージェントがコンテキストを生産するループ
- 人が簡単に消費できるコンテキストを作ることは、人が好まない作業である
- エージェントはPRコメント、クローズされたIssue、コミットメッセージ、古い設計ドキュメント、Slackアーカイブを漏れなく読み、誰も文書化してこなかったパターンを抽出することに強みがある
- .txtでは、コードベース、Issue、PR、スレッドをクロールして、暗黙の意思決定、慣行、「なぜこうしたのか」をナレッジベースにするエージェントの構築を始めた
- このナレッジベースは単に「このモジュールが存在する」というだけでなく、「このモジュールが妙なのは、マイグレーションが既存の挙動を保つ必要があるからだ」や、「このベンチマークが重要なのは、以前の最適化が分布を静かに変えてしまったからだ」といったコンテキストを含む
- 別のエージェントは、コードベース上で行動する必要があるとき、このナレッジベースを利用する
- 人が非公式に行っていた浸透が、エージェントと人の双方が読める形で外部化される
- コンテキストを消費するエージェントには、コンテキストを生産するエージェントが必要であり、このループが回れば、組織は自ら作ってこなかった文書化された土台を持つことになる
- ただし、このループが作るものは常に部分的な図にすぎない
- Michael Polanyiの言葉を借りれば、「私たちは語れることよりも多くを知っている」のであり、ある種の重要なコンテキストは、言葉として書かれたことがないからこそ存在し、書いた瞬間に変わってしまうこともある
- 人が直接会って積み上げる浸透の層は、文書化された副産物だけでは完全に復元できない
- 結果として得られるものは完全な復元ではなく、有用な出発点に近い。そして、それが累積効果を生むのに十分かどうかは、なお実験的な問いとして残っている
新しい堀は技術より組織にある
- 次の10年の勝者は、必ずしも最高のモデルや最高のエージェントインフラを持つ会社ではなく、50人、200人、2,000人へと拡大しながらも、縮小された意思決定集合に整列したまま、1人あたりの産出を増やせる会社である可能性が高い
- そうした会社は、エージェントが来る前から最も難しい問題が一貫性であると分かっていた組織である
- これは文化とマネジメントの問題であり、ずっとそうだった
- IDE、バージョン管理、CI、マイクロサービス、DevOpsのような前世代のツールは、より良いツールで調整を解決すると約束したが、実際には、すでに存在していた組織的一貫性を増幅する役割を果たした
- 小さなチームは一貫性をほぼ無料で得られるため、その増幅効果は概ねポジティブであり、エージェントを強く支持する声が小規模チームから多く出る理由も、彼らの文脈ではたいてい正しいからである
- 一定規模を超えると、一貫性は作られ維持されなければならず、その増幅効果は両方向に鋭く作用する
- 良い組織はさらに良くなり、悪い組織はより速く壊れていく方向に動く
- エージェントは以前のツールよりはるかに大きな増幅器であり、個人がコードをより速く書く手段としては過大評価され、組織が知っていることを外部化する手段としては過小評価されている
会社文化の拡張としてのエージェント
- エージェントは自分の思考の拡張のように感じられることがあり、その感覚は強力だ
- より難しい課題は、エージェントを会社文化の拡張にすることである
- そのためには、書く文化、自分たちが依然としてコンテキストのボトルネックになっている地点を見極められるだけの思慮深いマネジメント、そして一貫性を維持すべき実際の成果物として扱う人々が必要になる
- 新しくなった点は、これらの一部をいまや構築できるようになったことだ
- 読んで抽出するループはその一形態であり、他の形も現れるかもしれない
1件のコメント
Hacker News の意見
キャリアを通じて、チーム会議、アジャイル儀式、課題トラッカー、バックログ、Slack、メール、設計レビューのような、自分たちが最も本質的で神聖な活動だと言って守ろうとしていた数時間のコーディングの没入状態を妨げるあらゆるものに不平を言っていたエンジニアたちが、機械が自分たちより速くコードを書くようになるや否や、急に恥じることもなく協業活動の重要性とコード・コーディングの取るに足らなさを説き始めるのが滑稽に感じる
間違ってはいないが、1年前までどのチームでも最も反社会的で協調性のなかった人たちが見せる露骨な偽善には、やはり驚かされる
いずれにせよ、次の2つは同時に真でありうる。コードを書くことがボトルネックではないため、機能をデプロイ可能な速度より速く開発できること。そして、深い集中が必要な仕事をしているときに邪魔されるのは腹立たしく、フローを断ち切ること
https://en.wikipedia.org/wiki/Group_attribution_error
顧客とコーダーの同期を高める会議は稀で貴重だ。大きな組織では、間違った理由で儀式的な会議が増える。人々は顧客とコーダーの間のプロセスに自分を挟み込んで存在感を示そうとする
個人的には、顧客、最終ユーザー、UXデザイナー、実際のステークホルダーとの会議は好きだ。社内政治的な忙しさで帯域を食い、社内での影響力のために動く人たちとの会議は大嫌いだ。自分のユーザーと自分の間に、さらに別の中間管理職が入り込む必要はない
一方で、コード記述は非常に速くなり、達成すべきビジネス・技術要件を理解することが難しい部分になった新しい世界では、同じ人がそうした儀式をより優先し、AIエージェントがコードを書くあいだの中断を受け入れられる
状況の事実関係が変わったときに考えを変えるのは偽善ではない
会社の外で誰かと創作プロジェクトをするなら、Scrum の儀式や Jira を真っ先に思い浮かべないのには多くの理由がある。協業を重視しつつそれらを批判するのは完全に一貫している
チームは仕事が多すぎて何もできないと不満を言い、そこでマネージャーが私を投入する。すると突然、何も引き渡したがらなくなる。今まさにそのど真ん中にいる
チームは「完全に手一杯だ」と言いながら、私が処理できるほぼすべての仕事について、自分たちでやるのが最善で支援は要らないと主張する余力はある。私は別に構わない、座って金をもらえるだけだ。ただ、匂いはいつも同じだ
A: 自分たちは代替可能で、仕事もそれほど固有ではないこと、B: ボトルネックはプロセスや仕事量ではなく自分たち自身だということを認めたくない
ベテランエンジニアたちは、速度の問題の真の原因は常に技術より組織にあることをわかっていたように思う
ビジネスが集中した生産的なロードマップを定義できないことは、ソフトウェアエンジニアリングの長年の問題だった。ROIがほとんどない次のキラキラしたものへ飛びつき続ける一方で、体系的な技術的負債には手を付けさせず、私が働いたいくつもの会社を長期的に傷つけてきた
C++を1年中使っても std::unique_ptr を理解できないジュニアエンジニアを知っているし、そういう人はチーム全体で常に最も遅い
以前ジュニアエンジニアの評価を書くとき、実際に成果は速度に大きく左右されており、おおむね一定期間内に書いたバグのないコード行数で測られていた。優秀なジュニアは明確に定義された機能を受け取り、良いコードを素早く書いたし、そうでないジュニアは同じ仕事を受けて遅く書くか、速くてもバグだらけのコードを書いて、デバッグや書き直しのためにずっと多くの作業を生み出した
ビジネス上の根拠、スコープ、入力、望まれる出力を明確に理解していれば、データモデル、システム設計、コードはほとんど自然に出てくるか、少なくともずっと明確になる
— Melvin E. Conway, 1967
まず Chinchilla のようなスケーリング則がどういうものか、検証を含む強化学習が根本的にどう機能するのかを理解しているか考える必要がある
根本的な限界が、ビジネスが自分自身と戦略を一貫して表現できるかどうかにあるという点には完全に同意する
ただし今の利点は、事実上無料でプロトタイプを作れることだ。以前はエンジニアリング人員への投資に極度に慎重である必要があったが、今は同じ時間制約のなかで、はるかに多くのことを試せる
どの機能やバグ修正をいつリリースするか、製品全体をどう開発・管理するかは常に本当の課題であり、この戦略のかなりの部分は AI が素早く生み出せないフィードバックループに依存している
同時に、ビジネス側のリーダーが自分たちの悪い判断の責任を取る代わりに、エンジニアの速度をスケープゴートにすることも多いと感じる
たいていボトルネックはコードだが、コードを書くことではなくコードそのものだ。私のキャリアでは、遅いアプリケーションのせいで生じた遅延が数え切れないほどあった
Eclipse ベースのエディタを使わなければならないが、遅くて定期的に固まるかクラッシュする。ビルド作業には15〜20分かかる。最大50msで終わるはずの作業を永遠に処理する Web アプリにもよく遭遇する
こういうリストは延々と続けられる。すべての遅延は、私の集中を粉々に砕く妨害だ。今は管理職として何十人もの人と事務的な妨害に対処しているが、それでも会社でコードを書いている
ソフトウェアが遅いなら、それは私の最下位の優先事項になる。誰に影響しようが気にしない。本当に重要だったなら、私たち全員を引きずり下ろすこの遅いソフトウェアの糖蜜に人質にされてはいないはずだ
コードは負債だ
コードを資産と見なしやすいかもしれないが、根本的には負債だ。新しいコードへのいくつかの「ボトルネック」は、増えた負債を上回る成果を保証するために存在する。より速くより多くのコードを作るエージェントは、より速くより多くの負債を作るということだ
コーディングエージェントへの熱狂と懐疑のかなりの部分は、即時の生産性向上、つまり新機能や新製品・新売上といった即時の成果が、長期的な負債増加を相殺するかどうかに関するものだ。答えがわかるのは今後1〜3年先であり、分野ごとに異なるだろう
この観点では、こうしたボトルネックをエージェント型ワークフローの中に直接組み込もうとする試みにはある程度意味がある。一貫したプロジェクトビジョンを重視し、新機能や無制限なプロセスに反対できる追加の文脈をコーディングエージェントに与えることには価値がある
この記事が言いたいのはこれか？ あるエージェントにプロダクトマネジメントの責任を持たせ、できるだけ多くのものを凝集したプロダクトビジョンへ統合し、そのビジョンをできるだけ厳格にコーディングエージェントへ思い出させようという試みなのか？
そうしたエージェントは、新しい提案や新しいプルリクエストを「全体像への適合性」という観点からレビューすべきなのか？ これを文脈と呼ぼうが、ビジョンと呼ぼうが、別の名前で呼ぼうが
こうしたエージェントは、文脈を総合し、チームの価値観やビジョンに言語的には合っていそうな一貫したロードマップを提示するのは非常に得意かもしれない。しかし、優れたマネージャーやチームが持つような分別を持てるかどうかは懐疑的だ。特定のロードマップを素早く説得力をもって承認することは、得より害のほうが大きいかもしれない
追加の複雑さなしにビジネス要求を解決するために必要最小限のコードは、保守負債を伴う資産だ。農家のトラクターが保守を必要とする資産であり、放置すればビット腐敗で減価するのと同じだ
不必要な複雑さを生むためのコードは純粋な負債だ
その通りだが、コードを書くことは常に何かを教えてくれる
創業者規模のスタートアップから時価総額数百億ドルの上場企業まで働いてきたが、仕様どおりに実装すれば問題を解決するソリューションを説明したプロダクト仕様書、ピッチデック、PRD を見たことがない。実際に作ってみると、それがどう動くべきかを学ぶことになる
ソフトウェアは複雑で相互作用的な媒体だ。問題を理解し解決したい人たちとともにコードの中で反復することだけが、価値ある製品が作られる唯一の方法だった。会議やダイアグラムも役には立つが、動くソフトウェアを書くまでは、本当に何かを手にしているかはわからない
「目標は、私たちの構造化生成アルゴリズムとそのオープンソース版をテストすることであり、素朴な『この文字列を受理するか？』を、実際の問題に近い『正しいトークン分布を生成するか？』に置き換えることだった… 先月 Codex に30分かけてやり方を説明した。数時間後には動く最初のバージョンができていた。それで全部だ」
これは、ボトルネックが実際にはコードだったことを証明している。今は AI がそのコードを書いただけだ
「ボトルネックはコードではなかった」と考えた人は、すでに目標を議論し、頭の中で一貫して整理できていた状態だった
コードがボトルネックだと言うことは、必ずしも「この機能が欲しかったが、コーディングに数か月かかった」という意味である必要はない。「この機能を2年間ほしかったが、座ってコードに落とし込み、5〜10日を費やす摩擦のせいで先送りしていた」も含まれる
コードがボトルネックでなかったなら、ただ座って自分で書いていたはずだ。しかし自分でコーディングする労力と時間をかけたくなかったし、LLM ほど少ない負担では済まないこともわかっていた
最終仕様が明確でない場合でも、探索的なコーディング、確認、破棄、新しい設計の再試行は、LLM を使えばより速い。まさに「コード」の部分が速くなるからだ
言い換えれば、ボトルネックはコードだった
この文章自体も、ありきたりな表現を避けろという指示を入れたAI生成文のように見え、だからやはり読んでいて退屈だ
記事では「Jevons Paradox: 何かが安くなると、人はそれをあまり使わなくなるのではなく、もっと使うようになる」とあったが、これはジェボンズの逆説を壊した表現だ
その文は逆説ではなく、ごく自然な効果だ。何かが安くなれば使用量が増えるのは当然だ
ジェボンズの逆説が実際に説明しているのは、ある資源の利用がより効率的になって特定の作業に必要な量は減ったのに、その資源の総使用量は増えるという状況だ
しかし資源利用がより効率的になれば、その「利用」の価格が安くなるのも当然ではないか？
だから効率が上がれば使用量が上がるのも当然だ。これを逆説と呼ぶのは、効率向上が消費を減らす良い方法だと一部の人が素朴に考えるからだ
「逆説」と呼ばれるもののほとんどは、こういうふうに明白だ
あるいは、あるプロセスがより効果的、つまりより短時間で済むようになると、私たちはそのプロセスにより多くの時間を費やすようになる、ということかもしれない
何のためのボトルネックなのか？ より多くの機能のためか？
ソフトウェアの量が会社の成功を決めるとは思わない。文脈の量を捉えることも、それほど重要だとは思わない
重要なのは文脈の質だ。人間がどれだけうまく推論できるかだ
次に重要なのは態度だ。人間が悪い状況にどれだけうまく対処できるか
その次は資源管理だ。会社が人と金をどれだけうまく扱えるか
最後は運だ。自分たちで制御できない要素のうち、どれだけが味方してくれるか
こうしたものが会社にとってかなり妥当なボトルネックだ。エージェントが近いうちにこれらを解決するとは思えない
非ソフトウェア企業が使うソフトウェアアプリケーションをより良くするボトルネックは、ソフトウェアが実際にビジネスに利益をもたらすソフトウェア作業をすべて行うことを保証するところにある
時間を節約し、人間をより生産的にし、人為的ミスを減らし、ビジネスをより効率的にし、利益率を高めるようなことだ
これらすべては予測も定量化もかなり難しい。ビジネスに役立ちそうなアイデアから始め、設計し、プロトタイプを作り、試すことはできる。最終的にはソフトウェアアプリケーションを作るか改善し、それがどれだけビジネスを良くしたか測ろうとする
この全過程において、ソフトウェアが正しい問題を正しいやり方で扱い、最終的にビジネスをより良くすることを保証するのは難しい問題だ。ソフトウェアを作ることがどれだけ速く簡単になったかとは無関係に
それでも速度は本当に役に立ちうる。プロトタイプを作り、試し、フィードバックループを改善できる
AI コーディング補助を使うと、以前はジュニア開発者の仕事と見なされていたものが、今では素早いプロンプトとバックグラウンドで動くエージェントで実装される
こうしたジュニア開発者の仕事は、今やコーディング補助がほとんど人手を介さずに簡単に届けてくれる。バックログは新しい項目が追加される速度より速く空になり、処理能力がもはや問題でなくなるにつれて新しい項目もどんどん増える
今や課題は、その変更量に追いつくことだ。私たちの組織でまさにそれを見ている
別のボトルネックを思いつけるからといって、コード生成がボトルネックではなかった、あるいは今ボトルネックではないということにはならない。バックログという概念自体が、それがボトルネックであることを示している
「ソフトウェアとは、ひと群れの人間たちがシステムに何をさせるかを互いに交渉したあとに残るものだ」
この表現は好きだ。特に文脈について同意する。長期にわたって維持される経験豊富なチームが報われるのは、まさにそこだ
そういうチームを何十年も管理してきた。最終的に私たちの部門が統合されたとき、最も年次の低いエンジニアでも10年目だった
チームがそれほど長く一緒にいると、コミュニケーションのオーバーヘッドはほぼ無視できる水準まで下がる
だから最近の、日雇いのように短い在籍期間の文化がいちばんつらい
今は主に一人で働いている。生産性は非常に高いが、範囲は本当に限られている
良いチームに所属していた時代が恋しい
いったいどんなプロジェクトをやっているんだ。経営陣が望む機能を理解することだけが難しい部分で、残りはただ「タイプして出す」だけ、あるいは今では LLM に投げればいいだけなのか？
もしそれがやっている仕事なら、HN の多くの人が LLM に自分たちが置き換えられると思っているのも不思議ではない
だから私たちはまた同じ円をぐるぐる回り、不安を語り、互いに噛み合わない話をし、30分後の次のコメント機会を待つ
大半はオフショアリングとレイオフのサイクルのせいで、コード品質の面では燃えるゴミだ