We cut our CI/CD time by 95% đź‘€
by•
Hey everyone :)
We've been experimenting with AVP, the tool I launched recently... kind of a GitHub for coding agents.
Running it on our own work, we cut our CI/CD time by 95% hehe
We're turning this into a customer guide right now.
Before we write it... what's your biggest pain with CI/CD when agents are pushing code?
Is it the waiting time, the broken builds, or something else?
32 views
Replies
For the guide, could you separate time saved by faster runs from time saved by cancelling superseded runs or skipping checks? A before and after for the same checks on the same change would make the 95% much easier to interpret.
@al_kubÂ
Fair ask, and you're right: the headline mixes three effects. Here is the rough split from our two 48h windows.
1. Fewer runs, not faster ones. Before, a PR ran the full CI about 3 times, because every rebase restarted it. With AVP, a change runs one targeted proof: typecheck plus the tests related to the files it touched, 15 s median. The full suite then runs once per batch of landings. Most of the drop in CI machine time (-77%) comes from there.
2. Checks moved, not skipped. The full suite still gates staging: nothing reaches staging or prod without a green full run. What changes is that a break the related tests miss gets caught one batch later instead of before the merge. That's the real trade-off.
3. No more superseded deploys. 41% of our staging deploys were cancelled by the next merge, so a change often waited for a second deploy. Staging now follows the latest green batch, and none get cancelled.
That’s a huge time saver! Love seeing tools make developers’ lives easier 🙌