Ask HN: How fast is your CI these days?

8 points · 5 visible top comments · 2026-10-25 20:34:28 UTC

news.ycombinator.com · Read Story HN original

With the age of agents CI costs are generally going up, how is your build setup handling things? Have you been able to optimize, and how did you? Most importantly, how fast is it?

Comments

verdverm · 2026-10-25 20:42:08 UTC

Trigger a review agent for any commit which has an open PR and has passed build. Use open weights, or at minimum a different model family from the one which wrote the code. I will be publishing a write up soon(tm), inspired by but different from, cloudflare's post.

I would napkin math the averaged cost per-review to be less than $1, which is less than our most rigorous validation pathway in CI (needs GPU for up to an hour). Time-wise around ~10-15m, with variability - and a bug in Argo with pod scheduling delays. This is fine because developers check in on their own PRs when they do and then make the changes that are needed. A key point here is that we are keeping humans in the loop in the PR.

This is a large monorepo, I would expect much lower numbers for polyrepo setups.

easterncalculus · 2026-10-25 21:23:56 UTC

That's impressive! Would certainly read it when it comes out.

verdverm · 2026-10-25 21:54:26 UTC

teaser question, what parts of your agent PR process can you move to scripts?

caranlharris · 2026-10-26 04:13:32 UTC

My experience has made me more interested in seperating deterministic checks the judegment based reviews.Authentication changes have also taught me that passing inidividual checks doesnt mean an integration works end to end.

rozenmd · 2026-10-26 14:40:17 UTC

4 mins critical path, 1h30m wall clock time (bunch of optional tests)

was around 40 mins on the critical path at the start of the year. gains came mostly from sharding tests, replacing webpack with vite, eslint/prettier with oxlint/oxfmt, caching node modules

AlexITC · 2026-10-27 08:36:01 UTC

Fun to see this topic, I just wrote about how I got mine to 4 minutes, optimization details in my blog: https://alexitc.com/blog/2026-10-23-from-27-minutes-to-4-cut...

More or less, I did:

- Avoid unnecessary work

- Don't boot more often than needed

- Parallelism in tests

- Caching rules

My post has an ongoing live survey with ~570 responses:

- 30% says 5-15m

- 26% says >30m

- 23% says 15-30m

- 13% says 2-5m

- 8% says <2m

Jeremy1026 · 2026-10-27 16:34:46 UTC

We were at about 20 minutes, with minutes 5-20 being just the ~55 accessibility tests running, loading chromium browsers, navigating to the different pages and looking for color issues, aria, keyboard navigation tags, etc. A couple months ago, when I got beat to merging on deploy day three times making me rebase and rerun, I parallelized them and now we are at 6 minutes for the full suite.