Skip to content
Tech News
← Back to articles

Towards Self-Driving Codebases

read original more articles
Why This Matters

This piece captures the current gap between the hype of autonomous coding agents and the messy reality of deploying them in real engineering organizations, where token-heavy agent loops have produced lots of code but little genuine productivity gain. It matters because it reframes the AI coding narrative: the bottleneck isn't model capability but missing infrastructure and practices, which will shape how companies invest in AI-driven software development next.

Key Takeaways

We're post-tokenmaxxing. What are we pre-? How do we get there?

Agents can oneshot games that are actually fun. With the right guardrails, agents can execute incredibly impressive migrations in complex codebases, even rewrites in new languages. But basically all “real” software work still has human engineers driving the process. How do we get to a place where a much bigger portion of the work gets handled for us, without requiring our attention?

It seems like agents should be able to build entire software systems themselves. Why is this going so poorly in practice? What new primitives will we need to make it all work? How far can this go?

What comes after tokenmaxxing?

A lot of engineering orgs spent the first half of this year offloading as much work as possible to armies of agents and adversarial loops. The results have been pretty disappointing: mountains of dubious code, but no tsunami of incredible software. The ROI on all those tokens has been sketchy at best.

In hype cycle terms, we’re in the trough of disillusionment. We’re working out how to deliver on the utopian vision we had a few months ago that isn’t working yet in practice.

What happens next? In every other adoption cycle, the answer has been: figure out best practices, figure out where our shiny new hammer is well-suited for a nail vs where we’ve been using it to smash screws, and then create the building blocks we didn’t realize were necessary until we got our hands on the shiny new toy.

One diagnostic we can use to help us get there is to ask: when the software mostly drives itself, what will engineers do?

A common answer is: setting up Loops! We used to write code, then we wrote prompts, now we set up loops of agents and write /goal a lot.

I think this is mistaken. Right now, setting up a viable software loop that produces net-positive software change without incinerating money is a ton of work, but mostly that’s because the toolchain isn’t ready. When we have the right moving pieces, these loops are going to be easy to set up, easy to trust, and cost-effective. This won’t be where our time goes.

... continue reading