<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/XAQ5PlQ9R" -->

---
title: AI coding has made CI a bottleneck, so we reworked ours...
description: Linear&#x27;s engineering team details how they reduced CI pull request wait times from over 6 minutes to just over 5, despite nearly quadrupling their test suite,...
canonical: https://daily.dev/posts/ai-coding-has-made-ci-a-bottleneck-so-we-reworked-ours-to-keep-up-xaq5plq9r
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: AI coding has made CI a bottleneck, so we reworked ours to keep up | daily.dev
og:description: Linear&#x27;s engineering team details how they reduced CI pull request wait times from over 6 minutes to just over 5, despite nearly quadrupling their test suite,...
og:url: https://daily.dev/posts/ai-coding-has-made-ci-a-bottleneck-so-we-reworked-ours-to-keep-up-xaq5plq9r
og:image: https://api.daily.dev/og/posts/XAQ5PlQ9R.png
og:image:alt: AI coding has made CI a bottleneck, so we reworked ours to keep up
og:image:width: 1200
og:image:height: 630
og:locale: 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.

# AI coding has made CI a bottleneck, so we reworked ours to keep up

**[Linear](https://daily.dev/sources/linear)** · 10 min read · 7 upvotes · 4 comments

## Summary

Linear's engineering team details how they reduced CI pull request wait times from over 6 minutes to just over 5, despite nearly quadrupling their test suite, while cutting runner time per test roughly in half. Changes included moving off GitHub Actions to faster third-party runners, switching to the tsgo native TypeScript compiler, rewriting lint rules to avoid full type-graph builds, minimizing critical-path jobs, reducing repeated setup (scoped installs, base images, schema snapshots, batching short checks), and reworking Vitest sharding (going from four to eight shards, disabling test isolation for eligible files). The isolate:false change alone delivered roughly 17% in monthly savings. They also updated internal agent skills so AI-generated tests follow the new performance constraints by default.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://linear.app/now/ci-bottleneck-reworked>

## Questions this post answers

### How can I make Vitest run faster across multiple shards without breaking test isolation?

Introduce an opt-in Vitest project configuration with isolate:false so safe test files share a module registry within each worker instead of rebuilding the entity, GraphQL, and decorator graph per file. Mark eligible files explicitly with an opt-in comment and add proper teardown for shared state. Files using fake timers or unsafe shared state should stay isolated. This approach cut the slowest shard from roughly 300-379 seconds to about 195 seconds and reduced total API-shard runner time from 32.8 to 22 minutes per run.

_Engineers tuning Vitest sharding strategies can find deep dives like this through daily.dev._

### Why does increasing test shard count sometimes make CI slower instead of faster?

Doubling shard count also doubles the fixed setup overhead paid per shard, so if setup time per shard is high, more shards can spend more total time on setup than on actual tests. At 110-140 seconds of setup per shard, going to eight shards would have consumed 15-19 minutes of runner time on setup alone, exceeding test execution time. Reducing setup to around 40 seconds per shard made scaling to eight shards net beneficial.

_Teams debugging CI scaling tradeoffs often compare notes on setup overhead via daily.dev._

### How much faster is the tsgo native TypeScript compiler compared to tsc for CI type checking?

Switching from tsc to tsgo, the native TypeScript compiler, cut the weekly median of the tsc check by 73%, large enough to remove typechecking as the CI bottleneck entirely. This was combined with a runner infrastructure switch that separately made tsc workloads run up to 52% faster on average.

_Developers evaluating faster TypeScript tooling for CI pipelines can track such comparisons on daily.dev._

## Community discussion

Top comments from developers on daily.dev.

**@leonidbugaev** · 1 upvotes

> I'd have thrown more shards at it. At 110-140s of setup, eight of them spend 15-19 minutes just booting, more than the tests.

**@trevorsuna** · 0 upvotes

> The interesting part is how many small changes moved the critical path: faster runners, less repeated setup, better sharding, and cheaper linting. Updating agent guidance too is smart, since newly generated tests can quietly undo CI gains if they ignore the same constraints.

**@agustinbarrientos** · 0 upvotes

> It might help to shuffle the file order for the shared-module tests from time to time. What about showing the failure output shows the seed so you can rerun tests in the same order?

## Similar posts on daily.dev

- [We halved our continuous integration pipeline](https://daily.dev/posts/we-halved-our-continuous-integration-pipeline-w7assusoy) · LeadDev · 0 upvotes · 1 comments

---

Tags: [#typescript](https://daily.dev/tags/typescript), [#cicd](https://daily.dev/tags/cicd), [#github-actions](https://daily.dev/tags/github-actions), [#vitest](https://daily.dev/tags/vitest)

[View this post on daily.dev](https://daily.dev/posts/ai-coding-has-made-ci-a-bottleneck-so-we-reworked-ours-to-keep-up-xaq5plq9r)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"TechArticle","headline":"AI coding has made CI a bottleneck, so we reworked ours to keep up","url":"https://daily.dev/posts/ai-coding-has-made-ci-a-bottleneck-so-we-reworked-ours-to-keep-up-xaq5plq9r","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/ai-coding-has-made-ci-a-bottleneck-so-we-reworked-ours-to-keep-up-xaq5plq9r"},"datePublished":"2026-09-21T18:39:55.192Z","dateModified":"2026-09-21T18:40:27.731Z","description":"Linear's engineering team details how they reduced CI pull request wait times from over 6 minutes to just over 5, despite nearly quadrupling their test suite,...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/3df4528bc4f1732acb57d5bc124fbe05?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/3df4528bc4f1732acb57d5bc124fbe05?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Linear","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Linear","logo":"https://media.daily.dev/image/upload/s--ntgmTyoI--/f_auto/v1716187332/logos/linear","url":"https://daily.dev/sources/linear"},"commentCount":4,"discussionUrl":"https://daily.dev/posts/ai-coding-has-made-ci-a-bottleneck-so-we-reworked-ours-to-keep-up-xaq5plq9r","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":7},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":4}],"keywords":"typescript,cicd,github-actions,vitest","timeRequired":"PT10M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Linear","item":"https://daily.dev/sources/linear"},{"@type":"ListItem","position":3,"name":"AI coding has made CI a bottleneck, so we reworked ours to keep up"}]}
{"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/ai-coding-has-made-ci-a-bottleneck-so-we-reworked-ours-to-keep-up-xaq5plq9r","comment":[{"@type":"Comment","text":"I’d have thrown more shards at it. At 110-140s of setup, eight of them spend 15-19 minutes just booting, more than the tests.","datePublished":"2026-09-22T10:58:33.733Z","url":"https://daily.dev/posts/XAQ5PlQ9R#c-da7fvoKnC","author":{"@type":"Person","name":"Leonid Bugaev","url":"https://daily.dev/leonidbugaev","image":"https://lh3.googleusercontent.com/a/ACg8ocLhMgurwTmJElWaH9A8Ju8cHvZxgMCDt009jEYkmFCyUGAoaGSw=s96-c"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1}},{"@type":"Comment","text":"The interesting part is how many small changes moved the critical path: faster runners, less repeated setup, better sharding, and cheaper linting. Updating agent guidance too is smart, since newly generated tests can quietly undo CI gains if they ignore the same constraints.","datePublished":"2026-09-22T02:37:28.339Z","url":"https://daily.dev/posts/XAQ5PlQ9R#c-LTXORSJKO","author":{"@type":"Person","name":"Trevor Suna","url":"https://daily.dev/trevorsuna","image":"https://media.daily.dev/image/upload/s--dZ7gXxpp--/f_auto/v1784081551/avatars/avatar_EMoP47rpuw8DNjhp6R1b6?_a=BAMAMicg0"}},{"@type":"Comment","text":"It might help to shuffle the file order for the shared-module tests from time to time. What about showing the failure output shows the seed so you can rerun tests in the same order?","datePublished":"2026-09-23T08:10:53.741Z","url":"https://daily.dev/posts/XAQ5PlQ9R#c-hm1xJOMD9","author":{"@type":"Person","name":"Agustin Barrientos","url":"https://daily.dev/agustinbarrientos","image":"https://media.daily.dev/image/upload/s--5ayxQnqn--/f_auto/v1788281802/avatars/avatar_wQYYVe5Tbj0NJ7C7qPoa8?_a=BAMAMicg0"}}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/ai-coding-has-made-ci-a-bottleneck-so-we-reworked-ours-to-keep-up-xaq5plq9r#faq","mainEntity":[{"@type":"Question","name":"How can I make Vitest run faster across multiple shards without breaking test isolation?","acceptedAnswer":{"@type":"Answer","text":"Introduce an opt-in Vitest project configuration with isolate:false so safe test files share a module registry within each worker instead of rebuilding the entity, GraphQL, and decorator graph per file. Mark eligible files explicitly with an opt-in comment and add proper teardown for shared state. Files using fake timers or unsafe shared state should stay isolated. This approach cut the slowest shard from roughly 300-379 seconds to about 195 seconds and reduced total API-shard runner time from 32.8 to 22 minutes per run. Engineers tuning Vitest sharding strategies can find deep dives like this through daily.dev."}},{"@type":"Question","name":"Why does increasing test shard count sometimes make CI slower instead of faster?","acceptedAnswer":{"@type":"Answer","text":"Doubling shard count also doubles the fixed setup overhead paid per shard, so if setup time per shard is high, more shards can spend more total time on setup than on actual tests. At 110-140 seconds of setup per shard, going to eight shards would have consumed 15-19 minutes of runner time on setup alone, exceeding test execution time. Reducing setup to around 40 seconds per shard made scaling to eight shards net beneficial. Teams debugging CI scaling tradeoffs often compare notes on setup overhead via daily.dev."}},{"@type":"Question","name":"How much faster is the tsgo native TypeScript compiler compared to tsc for CI type checking?","acceptedAnswer":{"@type":"Answer","text":"Switching from tsc to tsgo, the native TypeScript compiler, cut the weekly median of the tsc check by 73%, large enough to remove typechecking as the CI bottleneck entirely. This was combined with a runner infrastructure switch that separately made tsc workloads run up to 52% faster on average. Developers evaluating faster TypeScript tooling for CI pipelines can track such comparisons on daily.dev."}}]}
```

