AI 让编码更快，为什么软件交付反而更慢？

New Story AI Made Coding Faster—So Why Did Software Delivery Get Slower? by Mike Dabydeen September 10th, 2026 TLDR Your browser does not support the audio element. byMike Dabydeen@firelinks byMike Dabydeen|@firelinks Engineering leader in Toronto: enterprise APIs, distributed systems, and reliable AI-agent delivery. AI made the coding stage faster. That does not make the system faster. It raises the arrival rate at whatever stage comes next, and for most teams that stage is human review. Here is where the bottleneck actually went, and what to measure instead of coding speed. The number that should bother you The individual-productivity numbers look excellent right up until you put them next to the team numbers. A 2025 study of experienced open-source developers found they were about 19% slower on familiar codebases when using AI tools, after predicting the tools would make them 24% faster. Even after finishing, they estimated they had been sped up by roughly 20%. Sit with that gap. Not slower than they thought. Slower in absolute terms, while feeling faster. Junior developers, by contrast, picked up real gains, somewhere in the 10 to 30% range on the kind of well-bounded work they were already doing. Now zoom out to the team. Coding might improve 30 to 40%, but if planning, testing, and release stay manual, overall throughput often rises less than 10%. The 2026 data circulating now puts numbers on the side effects: review times stretching, code churn climbing from around 3% to closer to 6%, and AI-generated code carrying materially more security defects, with one analysis citing nearly three times the vulnerability rate. The most common developer complaint is not “it is wrong.” It is “it is almost right, but not quite,” which is the most expensive kind of wrong because it survives a casual review. None of that means the tools failed. It means we measured the wrong thing and then celebrated. Why this is a flow problem, not an AI problem I ran a quarter at Purolator’s Digital Lab where our deployment frequency was high and our customer satisfaction scores were flat. The pipeline was healthy. The problem selection was not. The metric was telling the truth. We were asking it the wrong question. AI in the SDLC is that same lesson with a new cause. Deployment frequency and individual coding speed are local optimizations. They tell you how fast one stage runs. They tell you nothing about whether the whole system moves work to done any faster. That is what flow efficiency measures, and flow efficiency is where the AI story comes apart. When you make the coding stage three times faster, you do not speed up the system. You increase the arrival rate at the next stage. If the next stage is human review and review capacity is fixed, you have built a bigger queue. Queuing theory has been clear about this since before any of us were writing software. You cannot speed up a system by accelerating a stage upstream of the constraint. You can only move work to the constraint faster, where it waits. So the question every engineering leader should be asking is not “how much faster is our coding?” It is “where is our constraint now, and did AI move it?” For most teams I talk to, it moved to one of two places. Review bandwidth, or requirements quality.## The constraint that moved to review Review was always a quiet bottleneck. AI made it loud. When a senior engineer reviews human-written code, they are reading the work of someone who had to reason through every line. The reasoning leaves fingerprints. When that same engineer reviews AI-generated code, the fingerprints are gone. The code is plausible, internally consistent, and confidently wrong in places that do not announce themselves. The reviewer cannot lean on “would a person have written it this way,” because a person did not. That is why experienced developers slow down. The validation burden went up even though the typing burden went down, and validation is the harder cognitive task. We optimized the easy part and added load to the expensive one. The teams handling this well are not reviewing harder. They are instrumenting the review surface. They treat AI-generated changes as a distinct class with their own telemetry: change failure rate tracked separately for AI-assisted versus human-authored work, churn measured on AI-touched files, and a clear policy on what an agent may merge without a human in the loop. You cannot manage a risk you cannot see. Right now most teams cannot see which of their incidents trace back to code no human fully reasoned about. The honest admission: I got this one wrong myself. I assumed faster generation plus a normal review process would net out positive. It does not, unless you change the review process to match the new failure mode. The constraint that moved to requirements The second place the bottleneck landed is further upstream, and it is the more interesting one. When implementation was the slow, expensive step, teams could afford to be vague about requirements and absorb the cost later, during the long build, in hallway conversations and mid-sprint corrections. The build was slow enough to hide a great deal of ambiguity. Agents removed that slack. When an agent implements a fuzzy requirement in an afternoon, the fuzziness does not get caught during a slow build anymore. It ships, quickly, and the ambiguity surfaces in production. This is why intent engineering is becoming a real role rather than a buzzword. The scarce skill is no longer writing code. It is writing a specification precise enough that a fast, literal, non-deterministic implementer cannot misread it. That is an architecture skill, and it is the one I would invest in if I were building a team for the next two years.## What the classroom shows that the dashboards do not I teach at Sheridan and Conestoga, and the split in the productivity data matches exactly what I see in a lab. Give a second-year student an AI assistant and they move faster, because they are doing bounded work where plausible and almost right is good enough to learn from. Give the same assistant to someone doing genuinely hard, context-heavy work and it slows them down, because now they are validating output instead of reasoning forward. The tool is a force multiplier on whatever you already are. It multiplies a junior’s output and a senior’s review load. That has a direct and uncomfortable implication for how we build teams. The traditional path of juniors write, seniors review gets worse under AI rather than better, because you have increased the volume of code needing senior review while making each review harder. If your plan for AI adoption is “juniors generate more, seniors check it,” you have designed a system that maximizes load on your scarcest resource. The teams getting this right are inverting it. Seniors use AI to draft and explore at the architecture level, where their judgment catches the failure early. Juniors learn to review before they learn to generate. We may be teaching the sequence backwards. A note on non-determinism, because I have seen this movie At Skrumble, we built decentralized peer-to-peer communication infrastructure in the Ethereum era, before most of the current AI conversation existed. We shipped redundancy and assumed it bought us resilience. It did not, because we had not instrumented the system well enough to know which node failed, when, or why. Redundancy without observability is distributed failure with more moving parts. AI agents in the pipeline are a non-deterministic component and they deserve the same discipline. The same prompt against the same codebase can produce different output on different runs. That means an AI-assisted SDLC needs its own reliability budget, separate from your deterministic services, because the failure modes are different and the blast radius is harder to predict. If you cannot answer “which agent produced the change that caused this incident, and can we reproduce the decision,” you are operating the way we were at Skrumble. I can tell you how that ends. So what do you actually do You do not slow down adoption. You change what you measure. Stop reporting coding speed as a win on its own. Start tracking flow efficiency end to end, so the queue AI created at review becomes visible instead of hiding inside a healthy-looking deployment-frequency chart. Separate your change-failure-rate telemetry for AI-assisted work so you can see the real defect cost before it surfaces ninety days out. Invest in the specification skill, because requirements quality is your new constraint whether or not you have named it. And give AI-generated change its own reliability budget, the same way you would treat any non-deterministic component running in production. The honest version of the AI productivity story is not “it is overhyped” and it is not “it changes everything.” It is that AI made the cheap part of building software cheaper, which means the value and the risk both moved to the parts that were always hard: deciding what to build, and verifying that what got built is correct. Those were never the parts a faster typist could fix. I have been wrong about technology timelines before. But I would bet the teams that win the next two years are not the ones generating the most code. They are the ones who saw the bottleneck move and re-instrumented for where it went. If you are tracking flow efficiency or change failure rate separately for AI-assisted work, I would be interested in comparing notes on what your telemetry shows. That data is scarce right now and it is the data that matters. About Author byMike Dabydeen|@firelinks Engineering leader in Toronto: enterprise APIs, distributed systems, and reliable AI-agent delivery. Read my storiesAbout @firelinks TOPICS Software Engineering #ai#software-development#engineering-management#devops#productivity#ai-software-development#change-failure-rate#sdlc-bottlenecks