{"slug": "ai-made-my-pipeline-the-bottleneck-so-i-let-ai-run-it", "title": "AI Made My Pipeline the Bottleneck, So I Let AI Run It", "summary": "Linear's test suites nearly quadrupled since January, adding roughly 2,000 tests a week with agents writing the majority, pushing pull request wait times above 6 minutes and prompting CTO complaints that \"CI costs are high,\" according to a Linear blog post. Linear cut PR wait time from over 6 minutes to just over 5 and halved runner time per test by moving off GitHub Actions to faster runners, reducing one checkout step from 94 seconds to 20, batching seven jobs into two, and rebalancing test shards. The author argues one-time pipeline tuning is only a delay against superlinear validation load and instead hands deployment decisions to agents, deploying only what changed within a set cost budget.", "body_md": "In April I was in Silicon Valley, talking with engineers at Anthropic about a problem that had not gone public yet. Coding agents were getting fast enough that the slow part of shipping software was no longer writing the code. It was everything after: CI, validation, deployment. The pipeline.\n\nThis week Linear published a post about hitting that same wall. Their test suites almost quadrupled since January. They add roughly 2,000 tests a week, and agents write the majority of them. Every pull request still has to pass through a CI system designed for a world where humans wrote code at human speed. Wait times and infrastructure costs went up together, so their CTO opened an issue: “CI costs are high.” Also, make it faster.\n\nTheir writeup is worth reading. They moved off GitHub Actions to faster runners, cut one checkout step from 94 seconds to 20, deleted redundant setup everywhere, batched seven tiny jobs into two, and rebalanced test shards. PR wait time fell from over 6 minutes to just over 5, and runner time per test dropped by about half. Solid engineering.\n\nBut reading it, I noticed something about the shape of the work. Every single optimization was a human tuning the pipeline so agents could go faster. Humans repairing the road so the robots can drive.\n\nI hit the same wall months earlier, and I made a different choice. Instead of only making the pipeline faster, I started handing the pipeline’s decisions to the agents.\n\n## Pipelines are guardrails built for humans\n\nCI/CD pipelines were designed as guardrails for careless humans. Deterministic, exhaustive, and dumb by design. Every step runs every time, because a script cannot judge whether it needs to. Every deploy rebuilds and redeploys everything, because the script does not know what changed.\n\nThat design made sense when the alternative was trusting a tired engineer at 11pm. It makes less sense when the entity doing the work can read the diff, understand the dependency graph, and state exactly what it touched.\n\nEvery fixed decision in a pipeline exists because the old executor could not be trusted with judgment. The executor has changed. The judgment calls have not moved.\n\n## What I changed\n\nMy deployment used to be all or nothing. Every release rebuilt and redeployed everything, about 15 minutes, even when the change touched one small piece. I changed the deploy interface so the agent passes parameters describing what actually changed, and the pipeline deploys only that. Everything unchanged stays put. The agent got a degree of freedom, inside boundaries I defined.\n\nThe setup work Linear’s post describes in detail, caching strategies, lean images, installing only what each job needs, I did a long time ago. That part is table stakes now.\n\nThe more interesting trade is on the other side. The same agents write far more test cases than I ever wrote by hand, and that adds CI time back. Linear saw the same thing at scale: agent-written code demands agent-written tests, so validation load grows faster than code output. I accept the cost. The reliability is worth it, and the right response to more validation work is not less testing. It is a cheaper pipeline, maintained continuously.\n\nThat last word matters. I do not tune the pipeline once and walk away. The agents keep optimizing it as the codebase grows, within a cost budget I set. Pipeline efficiency stops being a project and becomes a maintained property of the system, like uptime.\n\n## The math compounds\n\nHere is why I think this is the only sustainable path. Agent-written code needs agent-written tests to be trustworthy. More tests mean more validation work. Validation work grows faster than the code itself, because every new feature adds tests that run on every future change. The load is superlinear.\n\nAgainst a superlinear load, a one-time optimization is a delay, not a fix. Linear’s own numbers show it: without this year’s rebuild, their suite would take 11 minutes today instead of 5. Great. But they are still adding 2,000 tests a week, and their post ends by admitting the work does not end. A pipeline that only gets faster when humans stop to fix it will always lag the traffic.\n\nA pipeline that agents maintain compounds differently. Each optimization sticks, and the next one starts from a better baseline. You are still going to lose ground some months. But you are fighting superlinear growth with something that can also grow.\n\n## The obvious objection\n\n“You let an agent decide what gets deployed?”\n\nNot quite. The agent does not get permissions, it gets parameters. I define the interface, the options, and the blast radius. Within that box it exercises judgment I used to exercise by hand, like deciding whether this change justifies redeploying the whole system or one service. Bounded autonomy, not free rein. The day it makes a bad call inside the box, the box gets smaller. So far the box has only gotten bigger.\n\nThis is the same pattern I use everywhere else with agents: guardrail decisions become typed parameters, routine cases flow through, and only the weird ones interrupt me.\n\n## The bottleneck always moves to the next human\n\nThere is an old pattern here. Every time a production tool gets 10x faster, the bottleneck moves downstream to the next human in the loop. Compilers moved it to code review. Code review moved it to QA. Now agents have moved it to the pipeline, and the pipeline is the last place where every decision was frozen in YAML by a human who is no longer the one doing the work.\n\nLinear answered by making the road faster. I think the real answer is to let the drivers run the road. If you maintain a pipeline today, go look for its fixed decisions: the steps that run every time simply because the script cannot tell whether they are needed. Each one is a candidate for agent judgment. Start with the least destructive one. For me it was deploy scope. Fifteen minutes became a parameter, and I have not thought about it since.", "url": "https://wpnews.pro/news/ai-made-my-pipeline-the-bottleneck-so-i-let-ai-run-it", "canonical_source": "https://chenchen.guru/blog/ai-pipeline-bottleneck-agents/", "published_at": "2026-09-22 03:54:39.207799+00:00", "updated_at": "2026-09-22 03:54:40.561786+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "mlops", "ai-tools"], "entities": ["Linear", "Anthropic", "GitHub Actions"], "alternates": {"html": "https://wpnews.pro/news/ai-made-my-pipeline-the-bottleneck-so-i-let-ai-run-it", "markdown": "https://wpnews.pro/news/ai-made-my-pipeline-the-bottleneck-so-i-let-ai-run-it.md", "text": "https://wpnews.pro/news/ai-made-my-pipeline-the-bottleneck-so-i-let-ai-run-it.txt", "jsonld": "https://wpnews.pro/news/ai-made-my-pipeline-the-bottleneck-so-i-let-ai-run-it.jsonld"}}