# AI Code Generation is Bottlenecking CI/CD > AI coding tools accelerate code creation, but the real bottleneck is now the time spent waiting for slow CI/CD pipelines to validate the new code. **Source:** Broke It (https://brokeit.dev/posts/ai-code-generation-is-bottlenecking-ci-cd/) **Published:** 2026-09-22 **Original source:** https://news.ycombinator.com/item?id=49822533 **Topics:** developer-tools, ci-cd, coding, community --- AI coding assistants make you faster at writing code, but they don't make your test suite run any quicker. The result is a new bottleneck: continuous integration. We've shifted the wait time from thinking and typing to watching spinners in pull requests. ## What's the new bottleneck? The core problem is that code generation velocity is outpacing code validation velocity. A popular discussion on Hacker News, sparked by an article from Linear, put a fine point on this. Developers are shipping more pull requests, more frequently, and each one triggers a cascade of builds, static analysis, and tests. I see this in my own workflow. I can use an AI tool to refactor three components, open three separate PRs, and then... I wait. The CI system becomes a traffic jam. My total "time to merge" hasn't actually decreased; the delay has just been reallocated to the CI queue. ## Why are existing pipelines failing? Our CI/CD philosophy is what broke. Most pipelines are built on a brute-force model: on every push, build everything and test everything. This was tolerable when commits were human-paced. Now that a single developer can generate the commit volume of three, that model falls over. The knee-jerk reaction is to throw more runners at it. This helps, but it’s a costly, linear solution to a potentially exponential increase in load. The real fix isn't just faster hardware, but smarter execution. For example, instead of running the entire test suite, a pipeline should only run tests affected by a specific code change. This requires tools for test impact analysis, which aren't standard in most CI setups. A concrete implementation is to move beyond simple `npm test` commands in your YAML file. You need a build system like Bazel or a monorepo manager like Nx that understands your project's dependency graph. You can then configure CI to run a command like `nx affected:test`, which only targets projects with actual changes. This is a significant architectural lift, not a simple config tweak. ## Should you fix your CI? The verdict is clear: the old CI model is unsustainable with AI-driven development. We have to stop treating the pipeline as a dumb, linear process. Investing in dependency-aware task runners and test impact analysis is no longer an optimization for massive companies; it's becoming a requirement for any team that wants to actually benefit from AI's speed. So yes, you should absolutely start refactoring your CI. It's a project in itself and won't be a quick win. But the alternative is paying for AI tools that just help your developers get stuck in a queue faster. ## FAQ ### Isn't this just a problem for large repositories? Not anymore. Even a solo developer with a moderately complex project will feel this pain. AI assistants increase your individual commit frequency, and your validation loop time will become the primary drag on your productivity. ### Why not just run more tests locally before pushing? Running tests locally is a good practice but doesn't solve the core issue. The CI pipeline is the ultimate source of truth, running checks in a clean, consistent environment that you can't perfectly replicate locally. Furthermore, full integration and end-to-end test suites are often too slow or resource-intensive to run locally on every minor change. ### Are there tools that solve this out of the box? Some tools move you in the right direction. Monorepo tools like Turborepo and Nx have built-in remote caching and affected-project detection. CI providers like CircleCI and GitHub Actions offer test splitting and parallelization. But there is no magic bullet; they all require you to structure your code and pipeline to take advantage of these features.