Faster Code Isn’t Faster Delivery  🔗 **Source:** [Faster Code Isn’t Faster Delivery](https://leaddev.com/software-quality/faster-code-isnt-faster-delivery) > [!note]+ Document Notes > --- > tags: [ai-assisted-development, code-review, engineering-leadership, developer-productivity, delivery-metrics, ai-adoption] > author: Emma Bostian > source: LeadDev > reference: [https://leaddev.com/software-quality/faster-code-isnt-faster-delivery] > date created: 2026-10-06 09:38 > --- > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > # 🏷️ Title: Faster code isn't faster delivery > Published 2026-10-06 on LeadDev. The captured copy is about 1,260 words. It holds 17 links and 2 images. Image 2's alt text ("NYC 27 Pre sale ticket block image") is a ticket promotion embedded in the page. It isn't article content, and nothing below treats it as such. > ## 🧭 Table of contents > - [📝 Summary](#-summary) > - [📖 Main Content](#-main-content) > - [🗒️ Notes](#️-notes) > - [📚 References](#-references) > - [🗣️ Paraphrase](#️-paraphrase) > - [📰 Newsletter](#-newsletter) > - [✅ Action Items](#-action-items) > - [🧪 Hypotheses](#-hypotheses) > - [📊 Methodology](#-methodology) > - [❓ Questions](#-questions) > - [🔮 Future Research](#-future-research) > - [💡 Implications](#-implications) > - [🧠 Learning Styles Assessment](#-learning-styles-assessment) > - [📊 Accessibility Assessment](#-accessibility-assessment) > - [🌍 DEIB Assessment](#-deib-assessment) > - [✅ Logical Validity](#-logical-validity) > - [🛡️ DARVO Analysis](#-darvo-analysis) > - [🎯 Conclusion](#-conclusion) > - [🔄 Refactor Appendix](#-refactor-appendix) > ### 🔗 References > - [Faster code isn't faster delivery (LeadDev)](https://leaddev.com/software-quality/faster-code-isnt-faster-delivery) — the article. > - [Estimating AI productivity gains from Claude conversations (Anthropic)](https://www.anthropic.com/research/estimating-productivity-gains) — external primary source for the 1.8% figure. Fetched. > - [AI-generated workslop is destroying productivity (HBR)](https://hbr.org/2025/09/ai-generated-workslop-is-destroying-productivity) — external primary source for four statistics. Paywalled; headline and intro only. > - 12 further leaddev.com articles — LeadDev's own earlier writing. Not opened. Assessed individually in the References section. > ## 📝 Summary > - **What happened:** LeadDev published an opinion piece arguing that AI coding tools haven't made delivery faster, because the constraint moved from writing code to reviewing it. The three key takeaways at the top say the same: review is the new bottleneck, mandates add code but not value, and leaders should measure the whole delivery system. > - **Why it matters:** The piece answers a question leaders now ask (why hasn't AI made us faster) with a cost model: author time saved becomes reviewer time spent. If that model holds, any program that celebrates generation speed rewards the wrong stage. > - **Key stakeholders:** Reviewers (the article's main victims), PR authors including non-technical colleagues, engineering leaders who set mandates and expectations, and the organizations that carry the maintenance cost. > - **Risks and tradeoffs:** The article names three code risks (security vulnerabilities, codebase bloat, edge case bugs) and three human risks (eroded trust, fragmented concentration, burnout). It offers five practices in return, each of which costs time, so the tradeoff is slower individual output for steadier team output. > - **Bottom line:** Of the stages the title implies (writing, review, integration, deployment), the article evidences only review, and mostly through a general-workplace survey, not engineering data. It ends by telling leaders to optimize for the entire system, not for how fast code appears. Its two external studies support the direction of the argument. Its delivery claims rest on LeadDev's other articles, which I didn't open. > ## 📖 Main content > The argument runs in nine steps. > 1. **The question flipped.** A year ago companies asked how AI could help. The article says they now ask why it hasn't made them faster. > 2. **The expectation source.** Anthropic estimated in late 2025 that current-generation models could raise US labor productivity growth by 1.8% annually over the next decade. The article says many tech leaders turned projections like this into a finite expectation: more code, fewer resources. > 3. **The counter-claim.** Producing code faster isn't a typing problem. Handing whole parts of the engineering process to AI, or having non-technical colleagues produce code, affects system quality and engineer wellbeing. > 4. **The bottleneck moved.** The constraint shifted from writing code to reviewing it. Pull requests pile up faster than engineers can understand, test, and approve them. Prompting an agent to finish a ticket is easy. Verifying business requirements, architecture, organizational knowledge, edge cases, and long-term maintainability is hard. > 5. **The human cost of that shift.** A reviewer who keeps hitting obvious errors reconstructs the author's logic, which can erode trust. Non-technical authors may paste review comments into an agent and push the fix without understanding it, producing a find-request-prompt-push loop. Engineers who launch several agents and switch tasks rebuild context at each switch and end up exhausted. > 6. **Mandates add volume, not value.** The article cites HBR on workslop (1 hour 56 minutes per instance, 40% of respondents reviewed it in the past month) and says the saved author time becomes downstream reviewer time, which compounds in a codebase. It lists three risks and states a rule: whoever starts the work owns its quality. > 7. **Collaboration is a delivery input.** AI can generate alternatives and shorten execution, but it can't replace the friction of people challenging each other's assumptions. HBR's trust figures (42% less trustworthy, 37% less intelligent) support the link between AI-generated filler and eroded trust. Teams may ship minimum viable products to be first, not products customers value. > 8. **Five practices.** Keep responsibility with the author. Teach how AI works. Document institutional knowledge where people and approved AI tools can use it. Protect the review process with entry criteria and measure the entire delivery system. Protect time for human collaboration. > 9. **The closing frame.** Leaders should ask how AI can help teams build better products without sacrificing judgment, trust, or people. When expectations rise faster than people adapt, gains turn into burnout. Sustainable adoption means optimizing for the entire system. > **Where the article says the bottleneck moved:** review (stated outright), organizational expectations (closing paragraph), and human attention and collaboration (cognitive cost and collaboration sections). **Where it doesn't say:** integration and deployment. I searched the captured text and neither appears. The title claims delivery, but the evidence covers the step before merge. > **Terms:** The article uses *workslop* without defining it. The HBR excerpt I could read doesn't define it either (see References). *Concentration fragmentation* is the article's label for task-switching across multiple agents. *Mob-programming* appears undefined in the closing recommendation. > **Contested or uncertain:** The article hedges the mandate claim in the body (may increase the amount of AI-generated code without increasing its value) but states it flatly in the takeaways (mandating AI use adds code but not value). The body is the defensible version. > ## 🗒️ Notes > - **Numbers, as stated, with stated source** > - 1.8% annually over the next decade: Anthropic, late 2025, about US labor productivity growth. > - 1 hour 56 minutes per instance of workslop: HBR. > - 40% of survey respondents had reviewed workslop in the past month: HBR. > - More than 1,000 US-based full-time employees surveyed: HBR. > - 42% perceive colleagues who sent workslop as less trustworthy; 37% as less intelligent: HBR. > - Every other count in the piece is structural: three takeaways, three risks, five practices, one year ago. > - **No stated source:** no data on PR volume, review latency, cycle time, incident rates, or burnout. [](https://leaddev.com/software-quality/faster-code-isnt-faster-delivery)[AI coding mandates are pushing developers to the brink](https://leaddev.com/software-quality/faster-code-isnt-faster-delivery) **Key takeaways:** * The bottleneck **moved from writing code to reviewing it**, and reviewers are paying the price. * Mandating AI use adds code but not value. **Authors still own quality**. * Measure the **whole delivery system**, including review time, not just output. One year ago, companies were asking “how can [AI](https://leaddev.com/ai/best-ai-coding-assistants) help us”? Today they’re asking a very different question: “why hasn’t AI made us faster?” [AI has become a standard tool](https://leaddev.com/ai/your-ai-coding-tools-buying-checklist-for-2026) in the software development pipeline, but its adoption has brought consequences that many organizations did not plan for. Engineers are reviewing more code, carrying more cognitive load, and spending less time collaborating with one another. The [bottleneck in software development](https://leaddev.com/velocity/writing-code-was-never-the-bottleneck) hasn’t disappeared. It’s moved. In late 2025, [Anthropic estimated](https://www.anthropic.com/research/estimating-productivity-gains) that “current-generation AI models could increase the US labor productivity growth by 1.8% annually over the next decade.” Many tech leaders translated projections such as this into a finite expectation: if AI helps engineers produce work more quickly, teams should deliver more code with fewer resources. However, producing code more quickly is not simply a typing problem. Outsourcing entire parts of the engineering process to AI, or asking AI-augmented colleagues without technical backgrounds to produce code, has consequences which impact the quality of our systems and the mental wellbeing of those engineers responsible for them. A tool which was once thought of as a catalyst for shipping more with less is [now creating bottlenecks](https://leaddev.com/velocity/ai-productivity-gains-are-being-offset-by-organizational-bottlenecks) in places they were not intended to be. #### The cognitive cost of AI Why doesn’t [AI automatically make us more productive](https://leaddev.com/ai/the-struggle-to-prove-ai-productivity-gains)? The biggest misconception is that generating code more quickly creates faster software delivery. While AI can complete tasks quickly, the work still requires [human judgment](https://leaddev.com/software-quality/meta-turned-engineers-judgment-into-agent-skills). In many teams the constraint has shifted from writing code to reviewing it. Pull requests accumulate faster than engineers have the capacity to understand, test, and approve. It’s easy to prompt an [agent](https://leaddev.com/technical-direction/how-to-prepare-for-ai-agents) to complete a ticket. It’s much harder to verify that the result fully satisfies the business requirements, upholds the desired architecture, reflects organizational knowledge, handles vital edge cases, and will be maintainable long-term. The bottleneck transfer from code writing to code reviewing has a human cost. A reviewer who repeatedly encounters obvious syntactical or logical errors is not simply reviewing pull requests, they are reconstructing the author’s logic. Over time, this can erode trust between colleagues. This dynamic is further complicated when non-technical colleagues open pull requests to solve a business need. While their initiative could be valuable, they may not understand the broader implications of their change. When a reviewer requests a revision, the author may feed the comment back to an AI agent and push the immediate fix without understanding the underlying issue. This can become a cycle: find a problem, request a change, prompt the AI, push the change, repeat. AI also causes concentration fragmentation. Engineers may begin one task, launch several agents, switch to another task, and return later to validate the output. Each switch requires them to rebuild context. The work of prompting, monitoring, correcting, and refocusing can [leave engineers exhausted](https://leaddev.com/ai/ai-productivity-is-burning-out-your-best-engineers). #### The risk of AI slop in our codebases There is an assumption that leveraging AI tools and agents will allow all kinds of tasks to be streamlined. Some have responded by mandating usage or asking less technical roles and engineering leads to produce technical work through AI. This mandate may increase the amount of AI-generated code without increasing its value. [Harvard Business Review](https://hbr.org/2025/09/ai-generated-workslop-is-destroying-productivity) reports that employees spend an average of one hour and 56 minutes handling each instance of ‘workslop,’ and that 40% of survey respondents had reviewed workslop in the past month. The time that seems to be saved by the author becomes time spent by the folks downstream responsible for reviewing the work. In a codebase, this cost compounds. Common risks include: * **[Security](https://leaddev.com/culture/why-security-everyones-responsibility) vulnerabilities**: generated code may introduce vulnerabilities or deprecated technologies. * **Codebase bloat**: AI may duplicate existing logic or include unnecessary code (i.e. tests) which over time compound. * **Edge case bugs**: AI may not identify organizational edge cases, leading to unintentional bugs. Regardless of whether a pull request was written by a person or generated with AI, the person who initiated the work is responsible for the quality. They should be able to explain the change, test it, and review it before asking a colleague to do so. AI can produce code, but it cannot take accountability for maintaining that code years down the line. #### AI can’t replace creative collaboration One of the least acknowledged side effects of AI adoption is what happens when people spend more time collaborating with machines than with one another. Innovation comes from a multitude of ideas, disagreement, domain expertise, and different experiences. AI can generate alternatives and shorten execution timelines, but it cannot replace the constructive friction that occurs between people when they challenge each other’s assumptions. Human connection matters for trust as well as creativity. In a survey of more than 1,000 US-based full-time employees, [Harvard Business Review](https://hbr.org/2025/09/ai-generated-workslop-is-destroying-productivity) discovered that 42% of respondents perceive colleagues who sent them AI-generated workslop as less trustworthy, while 37% perceived them as less intelligent. When collaboration is reduced to a series of AI interactions, the conversations that shape architecture and make products beloved become easier to skip over in the pursuit of speed. Teams risk shipping minimum viable products in order to be the first, rather than shipping products that customers genuinely value. #### What healthy AI adoption looks like The answer is [not to abandon AI](https://leaddev.com/ai/ai-adoption-has-to-be-driven-from-the-top). It’s to build it into a culture where AI augments human judgment instead of replacing it. First, responsibility should be preserved with the author. Team members should validate and understand AI-generated work prior to handing it over to someone else for review. AI is useful for challenging assumptions, generating alternatives, and validating a line of reasoning, but the final judgment must remain with the human. Second, teams should be taught how AI actually works. Engineers must understand hallucinations, common failure modes, security risks, and effective prompt engineering. Shared expectations for AI-augmented work makes review clearer and reduces frustration created by workslop. Third, document institutional knowledge to make it accessible. Architecture decisions, coding standards, product constraints, and edge cases should be noted where both people and approved AI tools can use them. Explicit context improves output, but does not eliminate the need to verify it. NYC 27 Pre sale ticket block image Fourth, protect the review process. Define what must be true before AI-augmented code can be submitted for a review, for example the author must be able to explain it, relevant tests pass, and security and privacy concerns must be met. Measure the entire delivery system, not just how quickly code is produced but also the time needed to review the influx of work, rework, and maintainability. Finally, protect time for [human collaboration](https://leaddev.com/ai/designing-human-agent-engineering-teams). Review your team rituals and question whether they still create space for engineers, product managers, and designers to think together. A weekly mob-programming session, architecture discussion, or “what I built this week” showcase can restore human connection. The primary question for [engineering leaders](https://leaddev.com/the-engineering-leadership-report-2026/) should not be “how much more code can we squeeze out of each individual contributor.” It should be, “how can we use AI to help our teams build better products without sacrificing judgment, trust, or the people who make our products possible?” AI may increase capacity over time, but when organizational expectations rise faster than people can adapt, learn, and build trust, productivity gains turn into burnout. Sustainable adoption requires leaders to optimize for the entire system, not only the speed at which code appears., Faster Code Isn’t Faster Delivery, Emma Bostian, 01m48pr8n1g0zm71411hab6xmv.