Speedrunning Software — Amplitude EPD × AI
MUSIC
(any%)
How we 3×’d PRs in 6 months, and how you can too
▶ Read & play game<br>¶ Read as article
Read & play<br>Read as article
pssst…. want to play fullscreen?
Have you ever watched someone try to speedrun a video game?
It takes most people hours to beat a game like Super Mario Bros. The world record is just under five minutes. Speedrunning is a competitive hobby where players try to finish a game as fast as possible, down to the second.
You might think it takes superhuman reflexes. Do the same thing every time, just mechanically faster. It’s not that simple. Speedrunners spend most of their time studying the route, finding shortcuts, and engineering the system and environment to go faster each time.
Somehow, building an autonomous software factory feels the same. We wanted to see how fast we could get software into the hands of our customers.
After six months, we’ve 3x’d our PRs.
Why does speed matter, really?
We wanted to ship more PRs, and speed is how you do that with the same headcount. On the surface, that might sound like a vanity metric. PRs can be artificially inflated, and more code isn’t inherently valuable. But teams used to think the same about engagement, until they saw how it drives stickiness, retention, and growth.
PRs are a leading indicator of customer value because each one is an experiment. A faster software factory means you can put more ideas in front of your customers to figure out what works. The goal is to run more experiments and see good ideas surface much faster.
Agentic coding assistants have led to a new builder’s block, where the holdup is deciding what to build.<br>— Andrew Ng, DeepLearning.AI founder
AI made building cheap. Knowing what to build is the new game. Speeding up your software factory lets you take more shots at what to build. With the same team, that’s how you out-iterate everyone else.
It’s also how you move engineers from in the software loop, doing every step, to on the loop, steering it.
The software development pipeline
Think of shipping software as a pipeline. An idea becomes code, the code gets validated and reviewed, and then it gets deployed to production. That path is the same whether the change is a one-line bug fix, a new feature release, or a sweeping migration across the codebase. Simple enough. But for us, it slowed down at a few specific steps.
The pipeline gates slowing us down
Before we made a bet on our software factory, most steps in the pipeline were manual. Engineers worked in local environments they had to assemble themselves. Setting one up meant figuring out which dependencies (and the dependencies of dependencies) were needed for testing, then spinning them up. The local frontend alone could take up to 3 minutes to start, and CI runs could stretch beyond 30 minutes. On a bad day, an engineer could lose most of their time just setting up and shipping a single change.
Despite its flaws, this design worked for years because writing code was the slowest part of the system. It was a natural limitation on how many changes could enter the pipeline at once. But agents changed that. Faster code generation meant that a trickle of PRs suddenly became a flood, and the manual validation and review became the stoppage points.
This is the Theory of Constraints , the idea that every system has one main bottleneck that limits how fast the whole thing can move. Speeding up one part of the system moves the goal post to the next-slowest step. What a beautifully messy problem to solve! We were up for the challenge.
For us, the heaviest gates to push through were the ones that stayed largely manual: validation and review. Like any speedrun, we had to shave time off the route.
Rebuilding the pipeline’s foundations
So we rebuilt the foundations under the pipeline and opened those two gates. The PR cycle time is now under an hour, which is 7x faster than before. That’s 2.5 hours below the industry benchmark.
PR cycle time · 7x faster<br>5.2 hrs → 44 min
When Shopify built their coding agent, they found something interesting: What’s good for agents is good for humans, too. We agree. An agent needs the same things a good engineer does: a clean codebase, fast feedback when something breaks, and an environment that comes up the same way every time. Fix those for agents, and engineers get the benefits too.
But we hadn’t made these fixes a priority. For years, we optimized for what we shipped, but agents forced us to finally fix how we ship. Brightside? They also helped us improve much faster than expected.
That improvement started with the foundations the pipeline runs on. We rebuilt three areas: the CI every PR passes through, the local environment engineers work in, and the legacy patterns that tripped up humans and agents. These changes made every step of the pipeline faster.
Custom local dev...