--- title: "You didn’t create more bugs, you just found them faster" url: https://daily.dev/posts/you-didn-t-create-more-bugs-you-just-found-them-faster-ktcpii9qj source_url: https://leaddev.com/software-quality/you-didnt-create-more-bugs-you-just-found-them-faster type: article source: "LeadDev" published: 2026-08-25T07:05:43.054Z updated: 2026-08-25T07:06:11.190Z tags: ["leadership", "ai-coding", "code-review", "technical-debt"] reading_time: 9 upvotes: 0 comments: 0 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # You didn’t create more bugs, you just found them faster **[LeadDev](https://daily.dev/sources/leaddev)** · 9 min read · 0 upvotes · 0 comments ## Summary AI-assisted development compresses build time but not the fixing time, so the bugs from eight weeks of work now surface all at once, creating an illusion of declining quality. The piece argues pausing feature work to fix quality is a symptom of not funding quality work continuously, that code review and product decisions become bottlenecks as engineers ship more code, and that teams should track change fail rate, recovery time, pull requests per incident, and deployment confidence rather than raw bug counts. It closes by noting the practices that produce good software haven't changed, only the speed at which skipping them catches up with you. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why does it feel like there are more bugs since my team started using AI coding assistants? Compressing build time does not compress the time it takes bugs to surface. Work that used to take eight weeks now ships in one week, but the same volume of bugs still needs to surface and get fixed, so instead of trickling out over eight weeks they all show up in the week after shipping, making quality feel like it collapsed even though the total defect count may be similar. _Track engineering quality trends like this alongside AI tooling coverage on daily.dev._ ### What metric can I use to measure whether AI-generated code is actually causing more incidents, not just more volume? Pull requests per incident is a useful ratio, tracking how much work shipped for each disruption caused, an approach reportedly used internally by Microsoft's engineering team. It should not be watched alone, since larger pull request batch sizes can inflate the number without real quality improvement; pairing it with batch size and keeping-the-lights-on share gives a clearer signal. _Engineers weighing AI-driven throughput against reliability can follow metrics discussions like this on daily.dev._ ### How much did pull request batch size change with AI coding tools between 2025 and 2026? Median pull request batch size roughly doubled between early 2025 and early 2026, based on a sample of 1,500 engineering organizations analyzed by Swarmia. Bigger changes tend to break in more places, which partly explains why teams using AI coding assistants report more bugs and incidents even when overall code quality hasn't necessarily worsened. _Follow data-backed shifts in engineering practice like this on daily.dev to benchmark your own team._ ## Similar posts on daily.dev - [You can just choose how many bugs you want now](https://daily.dev/posts/you-can-just-choose-how-many-bugs-you-want-now-yybwzht7p) · Read the Tea Leaves · 0 upvotes · 0 comments - [How Software Quality Changes When AI Enters the Build Loop](https://daily.dev/posts/how-software-quality-changes-when-ai-enters-the-build-loop-llzgc7n9q) · Medium · 0 upvotes · 0 comments --- Tags: [#leadership](https://daily.dev/tags/leadership), [#ai-coding](https://daily.dev/tags/ai-coding), [#code-review](https://daily.dev/tags/code-review), [#technical-debt](https://daily.dev/tags/technical-debt) [View this post on daily.dev](https://daily.dev/posts/you-didn-t-create-more-bugs-you-just-found-them-faster-ktcpii9qj)