The Bottleneck Moved

00:00:04 Laurie Voss laid out the numbers behind autonomous coding agents this week, and one figure keeps showing up in every postmortem I can find. The headline is seven hundred forty-one percent. Developers who turn on these tools write eight times more code. But shipping velocity?

00:00:21 It doesn't match. The data says they ship thirty percent faster. That gap is the whole story. Thirty percent faster is excellent for moving a product forward, but it means we're stuck somewhere specific. We aren't delivering eight times more software. We're delivering just over a third more.

00:00:40 Where are we stuck? Code review. There's an enormous study from Cisco twenty years ago about human code-review capacity that keeps coming up when anyone tries to scale these agents out. A human's ability to parse what's actually happening in a block of code drops off radically after about 450 lines per hour.

00:01:00 If an agent writes a ten-thousand-line diff, it would take you roughly a week to review it properly. Nobody is doing that. We're all just throwing massive diffs around. The obvious move was to let the machines do the reviewing too. That's already happening. GitHub Copilot now handles more than one in five of the code reviews on the platform.

00:01:23 OpenAI has said their humans may review pull requests, but aren't required to. You can even opt into letting the machine be the final reviewer before something hits production. But the machine reviewers aren't reliable enough yet. The data shows that if you run four different AI models across a codebase, they all find bugs.

00:01:44 They find actual issues. But they don't agree on any single bug. Each model spots a different problem. You can use them as safety nets, but you can't rely on one to tell you the code is safe. Some people tried skipping review entirely. Dexter Horty spent six months telling teams not to read the code they generated and just merge what the agent produced.

00:02:07 After half a year, he got back on stage and admitted he was wrong. He had to rip out and replace whole systems because the agents weren't one-shotting it yet. Amazon went through a similar phase after their coding agent produced a lot of slop and they just released it without thinking.

00:02:26 That caused a run of outages, and now senior engineers at Amazon have to sign off on code reviews. The cost of producing plausible code has collapsed while the cost of knowing whether to trust it has stayed exactly the same. We hit a wall at review because the information required to merge a pull request lives in the brain of the maintainer.

00:02:48 It isn't encoded in the codebase. It's code style, side effects, external systems, and history. Voss lays out a specific theory for what happens when we solve this. He assumes we figure out automated review. We push that bottleneck forward. The next hurdle becomes operations: how do you deploy this at scale?

00:03:08 Then security: how do you make sure it isn't going off the rails? If you solve all of those, the final bottleneck is simply describing the problem and defining what "good" means for a specific business. Every piece of software is a formalization of something a human wanted to get done.

00:03:27 If a customer tells you they need to track their orders, there are ten thousand pieces of software that do exactly that. Only one of them is actually good if you're running an auto parts store. The requirement isn't sufficient. The work of finding out what the customer means isn't in the training data.

00:03:47 It's in the mind of the person who runs that business. That's what we're left to do.

00:03:52 There's a personal essay on HN that captures the exact weight of this shift. It isn't about benchmarks or throughput; it's about what happens when you realize your career goals have been overtaken by a tool. Alex Gusev wrote "Challenge Is Gone" after turning forty.

00:04:09 For his whole life, his unconscious goal was always to challenge himself and try to succeed. He built apps for public transport routes, games on the App Store, and services for booking car washes. The problem is that he used to choose his challenges by weighing his own abilities.

00:04:27 It was extremely important that they be hard but achievable. If they were too easy, it was just an easy stroll and didn't bring joy. If they were too hard, it was a disappointment. Now, the challenge is gone. He wrote: "I simply know that I can solve any engineering problem (that I can come up with) with the help of artificial intelligence.

00:04:49 I've tried it a few times — it works." He spent several months cleaning up what he had vibe-coded for one project last year. Now he sometimes doesn't even look at the code the agents write, because he has gotten used to the fact that they will simply do certain tasks well.

00:05:06 If they make mistakes, other agents will find them and tell him. The shift in his head is profound. He says he is now completely absorbed in thinking about what to do rather than whether he can do it. A couple of examples from his post illustrate the new terrain: he found a way to create an image that is a memory bomb for a certain image processing library, making it take up ten gigabytes of memory even though the file is less than a kilobyte.

00:05:34 He also built a scanner app that finally works on macOS, which had stubbornly refused to work with the manufacturer's official drivers. Why does this feel like luck to him? Because someone built large language models, then multimodal models, then agents and everything that comes with them, and freed him from that challenge-achievement loop.

00:05:56 He could have died as someone who never climbed onto the second step. Now he has a chance to learn to think all over again. This hits on something Dan Luu wrote recently about building custom software tools. His name is Michael Malis, and he has been showing Dan interesting things he's done, saying we should be more ambitious with the software we build.

00:06:19 Since early this year, Malis has been using agents to find real bugs in Postgres—numerical bugs that cause valid SP-GiST operations to fail, format cache bugs that produce incorrect results from JSONPath, memory safety bugs in the dictionary loader. Lu calls these projects "vibeslop" when he looks at them on a news aggregator.

00:06:40 If he didn't know Malis, he would assume it's just another slop benchmark. But because he knows Malis, he trusts the work. He notes that building these highly custom tools—a bespoke regex engine tuned for his specific workload, a Rust interpreter that gets a fifty-percent speedup on cold compiles, a fork of Rust that sped up builds—would have taken a year or more to get to "works for me" quality five years ago.

00:07:06 Now it took a low single-digit number of hours. If you can build a superhuman board-game AI in about twenty hours instead of months, you change the shape of what you attempt. The problem is that the models are getting good enough to read a paper and implement the techniques from it, but they aren't quite there yet.

00:07:27 If you hand GPT-5.1 a paper, every suggestion it makes is wrong, and you have to do a lot of steering. When the model is that far from being able to do the right thing, if you don't know anything about board game AIs, it's fairly time-consuming to check if the model did what was claimed.

00:07:45 But for anyone willing to put in the work, the gap between the model and "just working" has shrunk so much that you can tackle problems that were previously too expensive. You can write a Rust interpreter because your compiler was slow. You can fix the fact that modern disks outpace the old *nix filesystem API because you are now writing developer tooling that uses direct I/O instead of normal file system operations.

00:08:12 There is a counterpoint to this ambition, from Yossi Kreinin. He wrote on HN that for most people, they should be less ambitious with the software they build using AI, or they will experience abject failure. If you use AI to speed up some flow, you will often add a bunch of messy code that is overfit for the one use case you tested and won't generalize or maintain itself when things change.

00:08:37 If you have a manager who thinks there is no reason for software to be slow and pushes people to use AI to make random parts fast, you should run for cover. The situation is analogous to why Dan Luu doesn't like it when people talk about how AI gives a hundred-thousand-fold productivity increase.

00:08:56 Some things get sped up by a factor of over a million. Some things don't get sped up at all. If you do exactly what you would have done five years ago, but with AI, the speedup is fairly poor because of Amdahl's law. But if you are looking for things that are productive to do, choosing to build custom tooling and highly specific benchmarks often seems like it involves things that were previously too expensive to do.

00:09:23 All this coding acceleration is running on top of some very specific, brutal infrastructure math. If you look at what it actually takes to run a model that can write this much code, Cerebras just published a deep technical breakdown of how they are deploying trillion-parameter frontier models.

00:09:44 They used the open-source Kimi K3 model, which has roughly three trillion parameters, as their illustrative example. A single Cerebras WSE-3T wafer has 44 gigabytes of on-chip memory. Trillion-parameter frontier models need terabytes for their weights alone. If you store those 3T parameters at a 4-bit quantization—half a byte per parameter—you are looking at a raw payload of 1.5 terabytes.

00:10:12 How do you fit that on a wafer? You don't. You split the model across multiple wafers and run it in a pipeline. Kimi K3 has 69 linear-attention layers and 24 dense layers. A dense layer needs additional room for a key-value cache — the KV cache — because every token in every active request stores keys and values.

00:10:34 So Cerebras places one dense layer per wafer and leaves the remaining SRAM for that KV cache. A linear-attention layer doesn't require full room for a KV cache. Instead of storing keys and values for every single token, it keeps a small, fixed-size state per request.

00:10:53 That leaves room for two linear layers per wafer. Using this math, Cerebras needs 59 wafers total to run Kimi K3. They map the model layers across regions of these wafers, and the runtime maps the path for tokens to flow between them. For ultrafast latency, only activations need to be passed between the wafers, which they do via RDMA over Ethernet at roughly two microseconds per hop.

00:11:20 Because each layer fits entirely on a chip—69 linear layers and 24 dense layers across 59 total—the model weights never have to move. Only the activations stream between the stages. If you send one request down the line, Wafer 1 runs layers one and two, sends its activations to Wafer 2 for layers three and four, and so on until the last wafer produces the next token.

00:11:47 But if you only sent one request at a time, the system would be running at a batch size of one, which is an inefficient use of the pipeline. So they keep the entire pipeline full with different requests. While stage three processes a token for Request A, stage two processes one for Request B, and stage one processes one for Request C.

00:12:11 Each stage can also process a micro-batch, a small group of requests, rather than just a single request. The number of requests in flight is roughly the number of stages times the micro-batch size. This setup lets them hit 1,000 to 2,000-plus tokens per second.

00:12:29 The tradeoff here is between micro-batch size and total throughput. Smaller batches make each individual request faster. Larger batches increase the total token throughput per unit of power, measured in tokens per second per megawatt. What this means is that you can write a trillion-dollar compute play where model weights stay in place on massive SRAM wafers while activations stream across them at two-microsecond hops.

00:12:59 You hit 741% more code generation by doing this math. But the bottleneck isn't the KV cache anymore. The bottleneck is deciding what to do with the code once it's generated. When you can build custom tooling in a low single-digit number of hours, you realize that the heavy lifting was never about the syntax or the types.

00:13:22 It's about the systems analyst work from the 1960s—figuring out what the problem actually is.

00:13:29 Laurie Voss lays out a specific prediction for what happens when code review, operations, and security are finally solved by agents. We are collapsing back to the 1960s. In the 1960s, there was a job called the systems analyst. Their job wasn't to write code. Their job was to talk to the business and find out what the problem was.

00:13:50 Then that analyst role turned into the product manager we know today, splitting one job into two and a half professions. Voss bets they are now collapsing back into one. He calls this new hybrid job the product engineer. It is somebody who finds out what people need, defines what good looks like, and ships it with agents doing the typing.

00:14:12 The market is already paying for this. Forward-deployed engineer job postings rose 800% in nine months of 2025. The average compensation for a forward-deployed engineer is two hundred and forty thousand dollars, which is to say it pays like a senior engineer because it is a very senior role.

00:14:30 Fred Brooks, who ran the IBM System/360 project, wrote about this in "The Mythical Man-Month." He split the difficulty of software into two kinds. There's accidental complexity—the difficulty of the tools and languages, the typing and syntax. And then there is essential complexity, which is the actual problem itself.

00:14:50 Brooks predicted that no single tool would make us ten times more productive because the essential part is the hard part. That prediction is looking pretty solid. We made code eight times faster with agents, and we still didn't get very much faster at shipping because the hard part is the essential part.

00:15:10 Code is just a lossy projection of the specification. Whoever writes the spec—the PM or the lawmaker or the engineer—becomes the programmer. This is why the bottleneck stays locked on defining what good means. Anything you can verify cheaply, you can train against until you beat it.

00:15:28 Cognition tried to write down exactly what it counts to merge a PR for their benchmark. They asked if the code was actually mergeable by looking at style, side effects, and history. They built that benchmark, and then they trained a model on it. The moment the maintainer takes knowledge out of their brain and puts it somewhere written down that a model can train on, the bottleneck moves again.

00:15:53 That is why Voss thinks security can go and operations can go. We will write those things down eventually, even though we haven't done it yet. What is left is just describing the problem to a human being and making sure you understood them right. The ecosystem is already cracking under the strain of this shift.

00:16:13 The open source subreddit instituted a hard ban on solo projects and anything built with large language models. The community decided that the flood of low-effort, AI-generated repositories was consuming too much maintainer time. Solo projects without clear provenance or maintenance pathways are being excluded entirely from the main hub.

00:16:35 It is an immune response to the collapse of the coding bottleneck. When generation becomes free, curation and human trust become the absolute scarcest resources. You can write seven hundred forty-one percent more code. But if no one can review it, merge it, and trust what it actually does, you are just leaving a lot of messy commits on a branch.

00:16:57 The real work is figuring out what good looks like for your business, defining the spec, and then having the humans talk to each other until it makes sense. The machines can handle the typing. They just can't flap their meat parts at each other to figure out if the auto parts store actually needs a different kind of order tracking system.

00:17:18 Leave that trade-off on the table.