Reducing Feedback Latency with Local CI for Developers and AI Agents
ProductsPayments<br>Stablecoins<br>Ledgers
SolutionsCross-Border<br>Digital Wallets<br>Embedded ACH<br>Global USD Accounts<br>Lending<br>Payroll<br>Rewards & Points<br>Stablecoin Orchestration<br>Programmatic Sub-Accounts
ResourcesLibrary<br>Journal<br>Newsroom
DocsPayments<br>Ledgers<br>API Reference<br>Release Notes
CustomersPricing
Join us June 25th with Spritz — see how fiat and stablecoins work seamlessly in a real product. Register Here →
Journal•June 30, 2026
Reducing Feedback Latency with Local CI for Developers and AI Agents<br>Faster cloud CI helped us merge code more quickly, but it didn't solve the problem of waiting for feedback while developing. By bringing CI back to developer machines, we were able to reduce context switching, improve agent workflows, and make iteration substantially faster.<br>Harsh Deep / Engineering
Contents&]:rotate-180" fill="currentColor" height="24px" role="img" viewBox="0 -960 960 960" width="24px" xmlns="http://www.w3.org/2000/svg" aria-hidden="true">
Explore With AI&]:rotate-180" fill="currentColor" height="24px" role="img" viewBox="0 -960 960 960" width="24px" xmlns="http://www.w3.org/2000/svg" aria-hidden="true">
Topics<br>Engineering
We’ve spent a lot of time speeding up our cloud Continuous Integration (CI) runs. Improvements like better caching, faster machines, DAG reordering, and eliminating slow steps reduced the time to get feedback and merge new code to roughly 5–7 minutes. Yet even after all of that work, the feedback loop still felt too slow during local development. Cloud CI was still carried overhead from provisioning environments for each pull request, pauses between pipeline stages, reporting infrastructure, and the coordination costs of a distributed system, with each layer adding latency before we can act on the results.<br>Problem: Long Cloud CI Waits<br>After making any Pull Request, developers often faced a long enough wait for cloud CI that they would switch to another task while it ran. Even when CI completed, they typically wouldn't return immediately; instead, they would wait until the new task reached a natural stopping point before context-switching back to address any errors CI had surfaced.<br>In practice, this meant having a few different code changes lingering in every engineer’s mind even after the bulk of work was done. If LLMs were involved, their rate of iteration was quite slow as it waited longer between each change.<br>Solution: Local CI<br>Recent developer machines have gotten very powerful For example, the M4 Macbook Pro I’m writing this on has 14 cores and 48 Gigabytes of RAM, giving it comparable resources to our CI cluster used for a single commit. This ended up powerful enough to run the entire test suite for our smaller projects, and run almost all our steps of our main monolith quite quickly.<br>This reduced overhead across various areas:<br>Setup: Bringing the CI loop locally removed setup overhead as a developer already had everything installed and running as part of the building out the feature, letting us skip to running the actual checks.<br>Network: Running locally eliminated the network and coordination overhead inherent in cloud CI. Rather than pushing code to GitHub, waiting for GitHub to trigger our CI provider, and then waiting for results to propagate back through multiple services, developers received feedback directly on their machines.<br>Worker allocation: In cloud CI, each step ran on a short-lived worker provisioned and coordinated by a shared cluster. This introduced several seconds of overhead between steps, along with occasional delays caused by resource contention from other builds competing for the same infrastructure.<br>Faster Feedback<br>Fast local feedback meant we no longer had to wait for cloud CI before feeling confident in a change. If local CI passed, cloud CI would typically pass as well. This faster feedback allowed for tighter iteration loops for developers and LLMs alike. In the past, only the relevant test would run after someone made a change, but now the entire CI was run after every change, catching issues faster.<br>Less Context Switching<br>Being able to just run CI and see results right away meant being able to fix issues immediately instead of waiting for a cloud run to finish. Getting immediate feedback led to faster iterations, both for developers and for workflows involving LLMs.<br>Despite spending considerable engineering effort optimizing our cloud CI, local runs still ended up being faster due to reduced overhead from competing resources, container initialization, compute allocation, and so on.<br>LLM Harness<br>At that point, we were already having LLMs work against our extensive test suite (written in RSpec and Jest) as a harness loop in some cases, but we would still encounter situations where code appeared to work fine, only to later fail cloud CI because an autogenerated type was missing, a linter rule missed, or a license check had failed.<br>Having a local CI allowed us to expand our...