{"id":36836,"date":"2026-10-23T13:56:34","date_gmt":"2026-10-23T11:56:34","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/?p=36836"},"modified":"2026-10-23T13:56:36","modified_gmt":"2026-10-23T11:56:36","slug":"your-ai-writes-code-faster-than-your-ci-can-keep-up","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/ai-ml\/your-ai-writes-code-faster-than-your-ci-can-keep-up\/","title":{"rendered":"Your AI Writes Code Faster Than Your CI Can Keep Up"},"content":{"rendered":"\n

Faster coding only becomes faster shipping if the pipeline behind it can absorb the extra load.<\/em><\/p>\n\n\n\n

At Codemotion we talk with developers about AI tooling all the time, and one question deserves more attention: what happens after the code is written? Datadog has a concrete take on it, backed by real teams. Here is the idea, and where their approach fits.<\/em><\/p>\n\n\n\n

There\u2019s a quiet assumption in much of the AI-coding conversation: if developers write code faster, software ships faster. It sounds obvious. It\u2019s also wrong, or at least incomplete.<\/p>\n\n\n\n

Code creation is only the first stage of a long conveyor belt. After the editor comes the pull request, then the build, the tests, the review, the merge, the deploy. Speed up the first stage by a wide margin and you haven\u2019t sped up the belt. You\u2019ve just made a bigger pile appear at the next bottleneck. And for most teams, that bottleneck is CI.<\/p>\n\n\n\n

More code means more of everything<\/strong><\/h2>\n\n\n\n

AI assistants and agents don\u2019t just help you type. They lower the cost of trying things. A change that used to take an afternoon to prototype now takes a prompt and a coffee. So developers open more pull requests, push more commits, and iterate more freely.<\/p>\n\n\n\n

Every one of those triggers a pipeline. More pull requests means more builds, more builds means more test runs, and more test runs means more compute, more waiting and more chances for something to fail for reasons nobody can explain.<\/p>\n\n\n\n

The uncomfortable part is that CI problems you could previously tolerate don\u2019t stay constant as volume grows. They get amplified. A pipeline that was merely annoying at ten PRs a day becomes a daily tax at fifty. A test that fails randomly once in a hundred runs goes from a rare nuisance to a near-certainty that someone\u2019s build is red right now, for no reason.<\/p>\n\n\n\n

The reflex that doesn\u2019t work: add more runners<\/strong><\/h2>\n\n\n\n

When the queue gets long, the instinctive fix is capacity. Spin up more runners, buy more compute, let more jobs run side by side.<\/p>\n\n\n\n

It helps, up to a point. But think of it as adding lanes to a highway when the real problem is a crash blocking one of them. Extra capacity gives you more room for work, yet it does nothing about the slow job at the end of the critical path, the test suite that reruns everything when one file changed, or the flaky test that sends a developer back to click \u201cretry\u201d. You pay more to run the same inefficiencies in parallel.<\/p>\n\n\n\n

So the bill grows roughly as fast as the volume does, and developers still wait. That\u2019s the worst of both worlds.<\/p>\n\n\n\n

Four ideas that scale better than hardware<\/strong><\/h2>\n\n\n\n

If throwing machines at the problem isn\u2019t enough, what is? Looking at how teams that keep CI healthy actually behave, it comes down to four habits. None of them is exotic. What\u2019s hard is doing them consistently, and that takes visibility.<\/p>\n\n\n\n

1. Find the real bottleneck.<\/strong> Pipelines feel slow, but \u201cslow\u201d is rarely evenly distributed. Usually a handful of jobs or stages account for most of the wait time. Until you can see where time actually goes, you\u2019re optimizing by intuition, and intuition tends to point at whatever annoyed you last week.<\/p>\n\n\n\n

2. Treat flaky tests as a trust problem, not a nuisance.<\/strong> A flaky test is more than wasted minutes. It teaches developers that red doesn\u2019t mean broken. Once people learn to rerun and hope, they stop reading failures carefully, and the day a real regression shows up, it gets the same shrug. Flakiness has to be prevented where possible and contained<\/em> where not: quarantined, owned by someone, and tracked until fixed.<\/p>\n\n\n\n

3. Run only what\u2019s relevant.<\/strong> Most changes don\u2019t touch most of the code. Yet many pipelines run the entire test suite every time, because it\u2019s the safe default. Intelligent test selection flips that: use what you know about the change and about test history to run the tests that could plausibly be affected. Less work, same confidence, faster feedback.<\/p>\n\n\n\n

4. Balance what remains.<\/strong> After you\u2019ve cut the unnecessary work, spread the rest sensibly. Parallelization only helps if the shards finish at roughly the same time. One overloaded shard means everyone waits for the slowest one, and the extra machines sit idle.<\/p>\n\n\n\n

Notice that these are all about work<\/em>, not capacity: do less of it, make it more reliable, distribute it better. Capacity is what you buy once that\u2019s done.<\/p>\n\n\n\n

What it looks like in practice: Betterment<\/strong><\/h2>\n\n\n\n

Betterment\u2019s story<\/a> is a useful illustration because it starts from a very familiar place. As the codebase grew, tests became flaky, CI pipelines stretched to nearly 40 minutes, and fewer than half of builds succeeded. The second-order effect mattered more than the numbers: developers lost confidence in the pipeline. When most builds fail for reasons unrelated to your change, you stop believing any of them.<\/p>\n\n\n\n

The fix wasn\u2019t a heroic rewrite. The team used Datadog CI Visibility and Test Optimization to identify which tests were actually causing trouble, assigned clear ownership for them, and used Workflow Automation to monitor and catch regressions instead of relying on people to notice.<\/p>\n\n\n\n

The results are worth reading slowly:<\/p>\n\n\n\n