Tech

AI Made the Typing Faster. Your Delivery Didn’t Speed Up — Because the Bottleneck Was Never the Code.

June 24, 2026 · Kevin Kelly, Out of Control~6 min read

Your team got an AI coding assistant six months ago. Pull requests fly out faster than ever. So look at the number that actually matters: how long does a change still take to reach production? If you’re honest, it’s the same as last year — maybe worse. You poured rocket fuel into one cylinder of an engine and wondered why the car didn’t go faster.

The number nobody wants to check

Through June 2026 this has become the loudest argument on Hacker News and in engineering blogs — the year AI is finally asked to show the money. The thread that crystallized it was blunt: the bottleneck was never the code. InfoQ reported the same finding from inside Agoda, a company with thousands of engineers: AI coding assistants did not speed up delivery, because writing code was never the slow part. A change still takes six to twelve months to travel from a commit to a live system. What eats those months is infrastructure provisioning, testing, sign-off, change management, deployment scheduling — the parts no autocomplete touches. Typing was maybe ten percent of the journey. You optimized the ten percent.

The reflex here is to argue the tool isn’t the point — that AI also helps you think, design, explore. Fair. But that is a different claim from the one being sold, which was speed: ship more, ship sooner. Measure that claim and it dissolves. A developer who used to spend two days writing a feature now spends two hours; the feature still waits a quarter for the security review, the load test, the release window, the ticket that has to be approved by someone three time zones away. The hours you saved drain into a queue that didn’t get any shorter. The savings are real and local; the system’s output is set somewhere else entirely.

Why a faster node doesn’t make a faster system

Kevin Kelly spent Out of Control arguing that the interesting things in the world are systems, not parts — beehives, economies, ecologies, software at scale. A system has its own behavior, and that behavior is governed by how the parts connect, not by the speed of any single one. Make one bee twice as fast and the hive does not gather twice the honey; the colony’s output is set by foraging routes, comb space, the queen’s pace. Software delivery is exactly that kind of creature. It is a pipeline of coupled stages, and a pipeline moves at the speed of its slowest stretch — its constraint. The constraint, this whole time, was downstream of the keyboard. So when AI made the keyboard fly, the rest of the pipe didn’t notice. Worse: a faster source can flood a narrow channel and make the jam visibly worse, which is precisely what teams are now watching happen. Think of a highway where you widen the on-ramp but leave the same number of lanes. Cars merge in faster; the traffic doesn’t clear faster; it stacks up sooner. The ramp feels like progress to everyone standing on it. The drive home is exactly as long.

The bottleneck didn’t vanish — it moved upstream

Here’s the part that gets missed. AI didn’t remove the constraint; it relocated it. Pull the weight off typing and the strain travels to the two stages that resist automation hardest: deciding what to build, and trusting what got built. The spec — figuring out the right thing, in enough detail that a machine or a junior could execute it — turns out to be the actual work, and it needs human judgment. And verification turns out to be the other wall. Addy Osmani’s analysis put a number on it: median code-review time has climbed roughly 441.5%, with first-review and average review times both about doubling. Read that slowly. When a model can emit a thousand lines in a minute, the question stops being how fast can we write and becomes how fast can a trusted human grow confident this is correct. That confidence is the scarce resource now, and no copilot ships it. A reviewer staring at a large, machine-written diff is in a worse spot than before: more to read, less context on why each line exists, and the nagging sense that the author didn’t fully hold it in their head either. So review slows, the queue lengthens, and the change that was “done” in two hours sits for a week waiting for a human to vouch for it.

What this means for you

If your delivery hasn’t sped up, the instinct is to buy a better model. Resist it. There’s a line going around — you spent six figures on AI and the real bottleneck is a four-minute CI pipeline nobody bothered to fix. That sentence is the whole memo. Before you upgrade the part that was already fast, go find your actual constraint: walk one change from idea to production and time every wait, every queue, every approval. Then aim every improvement at the longest bar on that chart — usually a review queue, a flaky test suite, a manual sign-off, an environment that takes a day to provision. Speeding up anything else feels productive and changes nothing. The discipline is unglamorous and it is the entire game: fix the bottleneck you have, not the one your tools happen to be good at. And when you do clear the longest bar, don’t celebrate yet — the constraint just moves to the next-longest one, and the work begins again. That isn’t failure; it’s what managing a living system looks like. Kelly’s point lands here: you don’t finish a system, you keep finding where it’s pinched.

Source: Kevin Kelly, Out of Control (a system’s behavior is set by how its parts connect and by its constraints, not by the speed of any single node). News peg: June 2026 debate across Hacker News (“the bottleneck was never the code”) and engineering blogs (frederickvanbrabant.com, May 15, 2026) on AI’s “show-me-the-money” year; InfoQ’s report on Agoda finding AI coding assistants did not speed delivery because coding was never the bottleneck; changes still taking 6–12 months from commit to production; and Addy Osmani’s analysis that median code-review time rose ~441.5%. Popular-science interpretation; figures are as reported.

技术

AI 让打字变快了，你的交付却没变快——因为瓶颈从来不是写代码。

2026 年 6 月 24 日 · 凯文·凯利《失控》约 4 分钟

半年前，你的团队用上了 AI 编程助手。Pull request 飞出去的速度前所未有。那就看一个真正要紧的数：一个改动，到今天为止，要多久才能上到生产环境？说实话，跟去年一样——甚至更糟。你往一台发动机的一个气缸里灌了火箭燃料，然后纳闷车为什么没跑得更快。

没人愿意去查的那个数

整个 2026 年 6 月，这成了 Hacker News 与工程博客上吵得最凶的话题——这一年，AI 终于被要求"拿出真金白银"。把它点破的那个帖子很直白：瓶颈从来不是代码。InfoQ 报道了来自 Agoda（一家有数千名工程师的公司）内部的同一个发现：AI 编程助手并没有加快交付，因为写代码从来就不是慢的那一步。一个改动，从提交到上线，依旧要走六到十二个月。吃掉这些时间的，是基础设施供给、测试、签核、变更管理、部署调度——全是自动补全碰不到的环节。打字大概只占整段旅程的一成。你优化的，正是那一成。

为什么一个更快的节点造不出一个更快的系统

凯文·凯利在《失控》里花了整本书论证一件事：世界上有意思的东西都是系统，不是零件——蜂群、经济体、生态、规模化的软件。系统有它自己的行为，而这套行为由零件之间怎么连决定，不由任何单个零件跑多快决定。把一只蜜蜂调到两倍快，蜂巢并不会采回两倍的蜜；整群的产出由觅食路线、蜂房空间、蜂后的节奏定。软件交付正是这种生物。它是一串彼此咬合的环节，而一条管线的速度，由它最慢的那一段——它的约束——决定。而这个约束，自始至终都在键盘的下游。所以当 AI 让键盘飞起来时，管线的其余部分根本没察觉。更糟的是：一个更快的源头会把一条狭窄的水道灌得更满，让堵塞肉眼可见地更严重——这正是各团队此刻在亲眼看着发生的事。

瓶颈没消失，它往上游挪了

被漏掉的恰恰是这一点。AI 没有除掉约束，它把约束挪了位。把重量从打字上卸下来，应力就转移到了最抗拒自动化的那两个环节：决定要造什么，以及信任造出来的东西。规格——把"做对的那件事"想清楚，细到一台机器或一个新手能照着执行——结果才是真正的活，而它需要人的判断。验证则是另一堵墙。Addy Osmani 的分析给它标了个数：代码评审时长的中位数攀升了约 441.5%，首次评审时间与平均评审时间都差不多翻了一倍。慢慢读这句。当一个模型能在一分钟里吐出一千行，问题就不再是"我们能写多快"，而变成"一个可信的人能多快对这份东西建立信心"。这份信心，才是如今稀缺的资源，而没有哪个副驾驶能把它交付出来。

这对你意味着什么

如果你的交付没变快，本能反应是去买一个更好的模型。忍住。有一句话正在流传——你在 AI 上花了六位数，真正的瓶颈却是一条没人愿意去修的、四分钟的 CI 流水线。这一句话就是整份备忘录。在升级那个本来就快的环节之前，先去找你真正的约束：拿一个改动，从想法走到生产，把每一次等待、每一道排队、每一个审批都掐表记下来。然后把每一项改进都瞄准那张图上最长的那根条——通常是一条评审队列、一套时灵时不灵的测试、一道人工签核、一个要花一天才能开好的环境。加速别的任何东西，都让人感觉在干活，却什么都不改变。这份功夫不光鲜，却是全部的胜负手：修你手上真有的那个瓶颈，而不是修你的工具碰巧擅长的那个。

取材：凯文·凯利《失控》（一个系统的行为由零件之间怎么连、由它的约束决定，而非由任何单个节点的速度决定）。新闻由头：2026 年 6 月 Hacker News（"瓶颈从来不是代码"）与工程博客（frederickvanbrabant.com，2026 年 5 月 15 日）关于 AI "拿出真金白银"之年的争论；InfoQ 报道 Agoda 发现 AI 编程助手并未加快交付，因为编码从来不是瓶颈；改动从提交到上线仍要 6–12 个月；以及 Addy Osmani 的分析，代码评审时长中位数上升约 441.5%。本文为科普解读；数字以报道为准。

テクノロジー

AI はタイピングを速くした。なのに納品は速くならない——ボトルネックは、もとからコードではなかったからだ。

2026年6月24日 · ケヴィン・ケリー『アウト・オブ・コントロール』約 6 分

半年前、あなたのチームは AI コーディング支援を導入した。プルリクエストはかつてない速さで飛び出していく。では、本当に大事な数字を見てほしい。一つの変更が本番に届くまで、今でもどれだけかかっているか。正直に言えば、去年と同じ——むしろ悪い。あなたはエンジンの一つのシリンダーにロケット燃料を注ぎ、なぜ車が速くならないのかと首をかしげている。

誰も確かめたがらない数字

2026年6月を通して、これは Hacker News とエンジニアのブログで最も声高な論争になった——AI がついに「金を見せろ」と問われる年だ。それを言い切ったスレッドは率直だった。ボトルネックは、もとからコードではなかった。InfoQ は数千人のエンジニアを抱える Agoda 社内から同じ発見を報じた。AI コーディング支援は納品を速めなかった。なぜなら、コードを書くことは遅い工程ではなかったからだ。一つの変更は、コミットから稼働中のシステムに届くまで、いまだに六〜十二か月かかる。その月日を食うのは、インフラの供給、テスト、承認、変更管理、デプロイのスケジューリング——どれも補完機能が触れない工程だ。タイピングは旅程のせいぜい一割。あなたが最適化したのは、その一割だった。

速いノードが、速い系を作らない理由

ケヴィン・ケリーは『アウト・オブ・コントロール』を一冊かけて、こう論じた。世界で面白いものは部品ではなく系である——蜂の巣、経済、生態系、大規模なソフトウェア。系には系自身の振る舞いがあり、その振る舞いは部品どうしのつながり方が決めるのであって、どれか一つの部品の速さが決めるのではない。一匹の蜂を二倍速くしても、巣は二倍の蜜を集めない。群れの産出は、採餌の経路、巣房の空き、女王の歩調が決める。ソフトウェアの納品は、まさにこの種の生き物だ。それは噛み合った工程の連なりであり、パイプラインはその最も遅い区間——その制約——の速さで進む。その制約は、この間ずっとキーボードの下流にあった。だから AI がキーボードを飛ばしても、残りの管は気づきもしなかった。さらに悪いことに、速い源流は狭い水路をいっそう溢れさせ、詰まりを目に見えて悪化させる——いま各チームが目の当たりにしているのが、まさにそれだ。

ボトルネックは消えず、上流へ動いた

見落とされるのはここだ。AI は制約を取り除いたのではない。制約の場所を移したのだ。重みをタイピングから外すと、応力は自動化に最も抗う二つの工程へ移る。何を作るかを決めること、そして作られたものを信頼することだ。仕様——「正しいこと」を、機械や新人がそのまま実行できるほど詳しく描き出すこと——こそが本当の仕事で、それには人の判断が要る。そして検証がもう一つの壁になる。Addy Osmani の分析がそれに数字をつけた。コードレビュー時間の中央値は約441.5%上昇し、初回レビュー時間も平均レビュー時間もほぼ倍増した。ゆっくり読んでほしい。モデルが一分で千行を吐けるとき、問いは「どれだけ速く書けるか」ではなくなり、「信頼できる人がこれは正しいとどれだけ速く確信できるか」になる。その確信こそ、いま希少な資源であり、どんな副操縦士もそれを納品してはくれない。

これがあなたにとって意味すること

納品が速くなっていないなら、本能はもっと良いモデルを買えと言う。こらえてほしい。こんな言葉が出回っている——AI に六桁を使ったのに、本当のボトルネックは誰も直さない四分のCIパイプラインだった、と。この一文がメモのすべてだ。もとから速かった部分を強化する前に、まず本当の制約を探せ。一つの変更を着想から本番まで歩かせ、あらゆる待ち、あらゆる行列、あらゆる承認をストップウォッチで測る。そして、すべての改善をそのグラフで最も長い棒へ向けろ——たいていはレビューの行列、気まぐれなテスト群、手作業の承認、用意に一日かかる環境だ。それ以外を速めるのは、働いている気にはなるが、何も変えない。この営みは地味だが、勝負のすべてだ。手元に本当にあるボトルネックを直せ。道具がたまたま得意なほうではなく。

取材：ケヴィン・ケリー『アウト・オブ・コントロール』（系の振る舞いは部品どうしのつながり方と制約が決めるのであって、単一のノードの速さが決めるのではない）。ニュースの契機：2026年6月の Hacker News（「ボトルネックはもとからコードではなかった」）とエンジニアブログ（frederickvanbrabant.com、2026年5月15日）における、AI の「金を見せろ」の年をめぐる議論。InfoQ は Agoda が、コーディングはもとからボトルネックではないため AI コーディング支援は納品を速めなかったと突き止めたと報じた。変更はコミットから本番まで依然6〜12か月かかる。そして Addy Osmani の分析では、コードレビュー時間の中央値が約441.5%上昇した。本稿は科学解説であり、数値は報道のとおり。