StarSling (YC X25)

Shout-out to @starslingdev 🚀 We moved Divi's CI over and our test runs are now ~4x faster, down to 6–7 minutes. Faster feedback = faster shipping for our users (investors). If your team lives in GitHub Actions, check them out. h/t @yonasbe and team! My CTO sent me this:

Anthropic, Linear, and many other companies are all hitting the same wall in AI software development: CI For twenty years CI was designed for human output. Now a five-person team can generate the code of a 50-person team, and all of it lands at the top of the CI pipeline in seconds. What this means: - 𝗢𝗽𝘁𝗶𝗺𝗶𝘇𝗶𝗻𝗴 𝗶𝘀 𝗮 𝘀𝘁𝗮𝗰𝗸 𝗼𝗳 𝗽𝗮𝗽𝗲𝗿𝗰𝘂𝘁𝘀. Anecdotally one team quadrupled its tests and still got PR waits down to about 5 minutes with a dozen small fixes: tsgo instead of tsc, oxlint, sparse checkouts, preinstalled dependencies, balanced test shards. - 𝗦𝗺𝗮𝗿𝘁 𝘁𝗲𝘀𝘁 𝘀𝗲𝗹𝗲𝗰𝘁𝗶𝗼𝗻 𝘄𝗼𝗿𝗸𝘀 𝘂𝗽 𝘁𝗼 𝗮 𝗽𝗼𝗶𝗻𝘁. Doing some form of test impact analysis so each change only runs the tests it touches is helpful. Even such smart selection systems get strained past a certain job volume. - 𝗖𝗜 𝗯𝗲𝗰𝗼𝗺𝗲𝘀 𝘁𝗵𝗲 𝘃𝗲𝗿𝗶𝗳𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗹𝗮𝘆𝗲𝗿: engineers can't review all the code agents write, even with AI reviewers. CI is where trust in that code gets established. It’s clear writing code stopped being the bottleneck. Now the systems to verify their correctness at scale are a new chokepoint.

Introducing Adaptive Compute ⚡️ Up to 2.3x faster GitHub Actions, with no workflow changes. Intelligent routing, instant failover and temporary resource boosts. (+25% vCPU and +50% RAM) starsling.dev/blog/adaptive-…

Levels of CI - a full guide for making your GitHub Actions cheaper and faster 👇🏾 Level 1: use Actions cache cache every dependency install, keyed on the lockfile so it actually hits. 🔗 Docs: docs.github.com/en/actions/r… 🔗 Agent prompt: starsling.dev/best-practices… Level 2: swap runners get faster, cheaper machines by changing the runs-on label. Your workflows, triggers, and checks stay exactly as they are. 🔗 Runner comparison: starsling.dev/compare 🔗 Right-size runners: starsling.dev/best-practices… 🔗 Cut queue time: starsling.dev/best-practices… 🔗 Runners that automatically adapt: starsling.dev/blog/adaptive-… Level 3: optimize your tests and workflows cache dependencies and builds, split long suites across parallel jobs, skip work a change can't affect, cancel runs a newer push replaced. Skills: 🔗 ci-speedup (@starslingdev): github.com/starslingdev/skil… 🔗 ci-cd-and-automation (@addyosmani): github.com/addyosmani/agent-… 🔗 test-audit (@steipete): github.com/openclaw/openclaw… Posts and guides: 🔗 18 best practices (agent-friendly): starsling.dev/best-practices… 🔗 16 optimization recipes (agent-friendly): starsling.dev/github-actions… 🔗 Where your CI money goes (prompt): starsling.dev/github-actions… 🔗 Why your CI is slow (prompt): starsling.dev/github-actions… Do all the above, or just let StarSling agents ship PRs like these for you: starsling.dev/products/runne… Level 4: switch CI engines Meta and Google built Buck2 (buck2.build) and Bazel (bazel.build) for aggressive caching and test selection, so each PR runs only the tests relevant to its change. A custom engine controls the whole execution layer, which gives you a much larger surface to optimize. Options for engines: 🔗 Dagger (dagger.io) 🔗 Buildkite (buildkite.com) 🔗 Depot CI (depot.dev/products/ci) 🔗 CircleCI (circleci.com) 🔗 GitLab CI (docs.gitlab.com/ci/) Level 5: throw out CI engines entirely A few different approaches are being discussed that were never possible pre-AI. This is the future: 1. Agent-driven test selection. "My plan is to let codex decide which tests actually need to run and drastically nix CI and run tests hourly." @steipete (nitter.cf/steipete/status/210430…) 2. CI after merge with auto-remediation. "have something that is running actual functional tests off of your master branch on a cron, and then if any regressions occur, automatically have an LLM bisect and figure out the bug and then patch it..." @yacineMTB (nitter.cf/yacineMTB/status/21043…) 3. Agents replace CI: a verification agent that writes just-in-time tests for each change. @Meta's research: engineering.fb.com/2026/02/1… Most teams are somewhere between Level 2 and 3. Figure out which level you're at and give your agent this full post: starsling.dev/blog/levels-of…

moved our CI from GitHub-hosted runners to Starsling (starsling.dev). just about 5 minutes of work. Full runs went from 4m23s to 2m50s, so ~35% faster, and every test stage sped up. It's also ~57% cheaper per run though we were inside GH's 2,000 free minutes anyway.

Linear's CI playbook (for GitHub Actions): 1. Faster runners: Linear moved CI off GitHub's runners onto faster machines. Jobs ran 34% faster on average, and typecheck 52% faster. 2. Native type-checking: switching from tsc to tsgo, the native TypeScript compiler, cut the typecheck's weekly median by 73% and took it off the critical path. 3. Lint without types: they rewrote the lint rules that needed type info as syntax-only rules. API lint got 68% faster, the whole repo 55% faster, with far less memory. 4. Oxlint: syntax-only rules made the move to Oxlint easy, and it cut the runner minutes spent on linting. 5. Lighter checkouts: a shallow fetch took the slowest gate job from 94s to 20s, and dropping checkout from jobs that never read files took 27s to 7s. 6. Resilient checkout: a checkout that retries and aborts a stalled fetch after about 30s, instead of hanging, meant far fewer runs stuck waiting on git. 7. Off the critical path: moving a cache write out of the final merge check saved 42s on every API PR and merge-queue entry. 8. Preinstall in the CI image: baking the Postgres client into the base image saved 7-8s per test shard on every run, and stopped a setup step that occasionally hung. 9. Filtered installs: installing only the API package, not the whole monorepo, cut pnpm install from 44-73s to 16–18s. 10. Drop a costly cache: a node_modules cache took about 28s to restore, slower than a 7.5s fresh install, so they removed it. Along with moves 8 and 9, per-shard setup fell 44%. 11. Schema snapshots: loading a schema snapshot instead of replaying every migration cut database setup from about 12s to 1-2s per container. 12. Batch short checks: merging seven tiny jobs into two that run their tasks in parallel saved about 87,000 runner-minutes a month, 11.8% of their CI. 13. Balance the shards: splitting oversized test files and moving from 4 to 8 shards made the critical job about 19% faster and 19% cheaper. 14. Share module state: letting test files share setup was their single biggest win. The slowest shard went from 300-379s to about 195s, and shard runner time from 32.8 to 22 minutes per run. 15. Setup bounds sharding: with setup down to about 40s, 8 shards now spend less total setup time than 4 used to, while running tests twice as wide. If you want your CI to look like theirs with all of these optimizations (and 50+ more), give your agent this post: starsling.dev/blog/linear-ci

instead; have something that is running actual functional tests off of your master branch on a cron, and then if any regressions occur, automatically have an LLM bisect and figure out the bug and then patch it and then ban the engineer responsible for merging for 1 (one) week