Part 1 of the blog series drawn from The Infinite Engineer guide by Orlin Radev and Alexander Alexiev. This series explores both sides of the shift: what happens when engineering throughput stops being the bottleneck, and why software value doesn’t disappear when AI makes building faster.
A growing backlog of validated, valuable customer-requested features is a defining constraint for every software company. Features that are genuinely needed and commercially important sit in queues for months because teams are already operating at full capacity. Every sprint is a prioritization exercise, and every roadmap is a list of what must wait.
This was AMPECO’s reality for most of our history. Then something changed in 2025 – and it matters beyond engineering, because it directly affects how quickly the features our clients need reach production.
The backlog has always been the story
Every feature in the backlog has already cleared the hardest part. It’s been identified, scoped, validated, and prioritized. A customer has explained why it matters, and both sides agree it would create real value. And yet, it waits.
This isn’t a failure of prioritization but the natural result of a constrained equation: there is always more to build than there is capacity to build it. Teams can optimize within this constraint by setting better processes, tighter scoping, and more focused sprints, but they cannot change the equation by working harder at its edges.
At AMPECO, this had been true since day one. As we build software that runs EV charging networks and manages real-time operations across dozens of markets and regulatory frameworks, our backlog has only grown, while we’ve continued to operate at full capacity.
In June 2025, we stopped asking how to manage that constraint and started asking what it would take to remove it entirely.
What we found when we asked the question
The question was deliberately ambitious: what would 20x look like, not 20%, but 20 times? We assumed the answer was probably two or three years out. So we started from the end and asked, what would the engineering process need to look like to produce twenty times the output, and then worked backward to figure out what had to change.
The first experiments with AI-assisted development produced results we hadn’t expected. We were looking for the ceiling of what was possible. We didn’t find it.
“We started experimenting with Claude Code for the first time. And everything we tried worked. So we figured: maybe it’s not two years away, maybe it’s already here and we just missed it.”
Alexander Alexiev, CTO, AMPECO
What followed was a rebuild of the software engineering process. The CoOperator Dev Agent (CODA) AMPECO’s internal AI-powered development system is a structured system in which each step is verified by a fresh agent before the next begins, with quality checks built into the workflow rather than layered on top of it. By October 2025, the system was in full production across the engineering team. Virtually all production code is now agent-generated. The team doesn’t bypass the system as there’s no reason to.
Over the months that followed, the metrics moved. First 2x, then 4x, then 7x, measured against our pre-CODA feature delivery rate. But the number isn’t the story. What the number revealed is.
The moment the backlog reversed
By late 2025, something happened at AMPECO that had never happened before in the company’s history.
Features from future quarters started being pulled forward. The team had capacity, and the question became what to bring in ahead of schedule. For the first time, we were looking at the backlog not as a queue to manage but as a prioritized set to draw from.
We call this the Backlog Inversion: the point at which the direction of work reverses, and features are no longer pushed back to future quarters, but pulled forward because capacity is available.
This wasn’t a one-off result, but months of sustained acceleration, with compounding gains continuing beyond it.
So, the backlog didn’t disappear. But for the first time, it started moving the other way.
From building faster to deciding better
When engineering capacity stopped being the constraint, something else became it. That’s how bottlenecks work: solve one, and the next appears.
Before CODA, the limit was the team itself. Every feature competed for the same engineers, and the queue grew because capacity didn’t. Most software companies are still here.
Once capacity opened up, the bottleneck shifted to code review. More code was moving through the pipeline than human review could handle, so review became part of the workflow itself. Code produced by one agent is reviewed by a separate one, with fresh context and no memory of how the work was done.
By January 2026, the bottleneck moved again, this time to specification quality. This is where the feedback loop becomes self-correcting: every review comment that identifies a gap feeds back into the knowledge base so it doesn’t make the same mistake twice.
Now the bottleneck is shifting again and is becoming a judgment issue. When you can build almost anything that’s been scoped, the constraint becomes scoping itself. What should we build? In what order? For which customers, and why now?
Each stage is a sign of progress, not a problem. The bottleneck moved because the previous one was solved.
What this means if you’re waiting on a feature
The change shows up in the smallest things first. A recent Monday review illustrates it clearly:
The team identified a simple need: additional filters on a transactions view, specifically the ability to filter by partner or site host. A product manager opened a five-minute conversation with Claude Code to create the specification, using it as a sparring partner to pressure-test the approach before grooming even started. The assigned developer reviewed it briefly with the PM and then marked it ready. From there, the system handled the rest: architecture, implementation, testing, code review, and acceptance testing. The human work for this feature: five minutes of specification and a final review.
That was a simple filter. But the features that have historically sat longest in backlogs — complex integrations, multi-market logic, compliance-adjacent work — are exactly the ones that benefit most from this kind of throughput. They were never deprioritized because they weren’t valuable. They were waiting because the queue was always full.
That’s no longer the case.
The question gets harder
The Backlog Inversion is not a finish line. It’s the point at which a constraint that defined the company’s history stopped being the constraint. What’s left is the question that was always underneath it: “what’s worth building next, and in what order?” That’s a harder problem, and a more interesting one.”
