I have spent most of this year on planes. Seven countries, somewhere north of a hundred customer conversations, most of them with teams well past the pilot stage.
The thing I keep coming back to is what changed between the January conversations and the July ones.
In January and February, as agentic coding adoption climbed, people bragged about lines of code being generated. Not sheepishly. Proudly, with slides. By summer, nobody was bragging about that anymore. What replaced it is the interesting part, and it has changed what I think good agentic architecture actually looks like.
The number that didn’t survive contact
Anyone who has written software knows counting lines of code is a terrible proxy for value. Dijkstra wanted lines spent rather than produced. Gates compared measuring programming progress by lines of code to measuring aircraft progress by weight. DORA’s contribution, starting in 2014, was to define delivery performance in terms of throughput and stability instead of output volume, and to keep testing that definition for a decade.
So, the lines-of-code brag didn’t come back because people forgot about its weaknesses. It came back because AI made output volume newly impressive and there was no other number ready to hand.
The industry has since caught up. By spring, DORA was writing about “tokenmaxxing,” the practice of ranking developers on raw token consumption, and filing it in the same drawer as lines of code and commit counts. The question worth asking is which metric the teams who moved past it reached for instead, and what they’re building to move it.
What actually replaced it
Start with the data, because it explains the architecture.
CircleCI’s 2026 State of Software Delivery, drawn from more than 28 million CI/CD workflows, found that for the median team, feature-branch throughput rose 15% while throughput on the main branch, where code actually gets promoted to production, fell 7%. More motion where the writing happens. Less where the shipping happens.
DORA’s survey of nearly 5,000 technology professionals reaches the same place from the human side: higher AI adoption is associated with an increase in both software delivery throughput and software delivery instability. Faster and shakier at once. The mechanism they describe is a verification tax, where effort saved on typing relocates downstream into review and validation, and where AI tempts teams away from small batches into larger, riskier changes. DORA’s ROI report this spring gave the cost a shape: a J-curve, with the dip arriving before the return.
The trick isn’t code volume; it’s how fast an organization can get code into production and how reliable it is once it gets there. How does an organization use AI to achieve this?
The wrong fix to faster, more reliable production releases
The instinct is to build a super agent. One agent that owns the software development lifecycle end to end: reads the ticket, writes the code, opens the pull request, runs the tests, ships it. I have watched it demo beautifully more than once.
It also concentrates every failure mode in one place, needs the entire universe of context to do anything at all, and gives your humans nowhere familiar to look when it goes sideways.
So, if a super agent is the wrong answer, what’s the right one?
What teams are actually building
The pattern I keep finding in the field is the opposite of the super agent. Small agents, each one sitting on top of a system of record that already exists.
Walked out concretely, the chain looks like this:
- Jira ticket to GitHub issue. One agent. It reads the business request and produces a technical issue with enough specificity for engineering to act on. That’s it. That’s the whole job.
- GitHub issues to point poker to sprint organization. A separate agent, independent of the first. It estimates, groups, and sequences.
- Coding. Another agent. This is the one everybody thinks of as “the AI,” and it is one of five.
- Pull request merging. Another. Review, conflict resolution, merge discipline.
- System testing. Another.
The important word is independent. This is not one brain with five subroutines. It is five agents that happen to touch adjacent records, each one narrow enough that you can describe its job in a sentence. If this pattern sounds familiar, it should, because it borrows a lot conceptually from microservices.
Why this way
Keep your systems of record. This is the most underrated idea in the whole pattern. Most agent discourse assumes you are building a new pane of glass, a console where you watch the agents work. The opposite is right. Put the agent behind the pane your people already watch.
Your humans in the loop don’t need training, don’t need a new dashboard, and don’t need to change where they look to see whether things are on track. Jira is already that place. Human-in-the-loop fails less often because people refuse to supervise and more often because supervision got moved somewhere they don’t live.
Limit the blast radius. An agent scoped to sprint organization cannot ship bad code. It can misfile a story, and you will find out at standup. In DORA terms, you are addressing change failure at the stage where the change happens, rather than measuring it at the end of a pipeline where you can no longer tell which step broke it.
Architect and release independently. I watched service-oriented architecture become microservices at HP and again at Cisco, and the thing that made the transition worth its considerable cost was not elegance. It was that you could change one piece without renegotiating the whole system. The same applies here. Swap the coding agent’s model without touching the testing agent. Version them separately. Kill the one that isn’t earning its keep.
There is a fourth benefit that compounds with the others. Each micro agent needs a fraction of the context a super agent needs. Last month I argued that the lever nobody pulls is what a single pass costs, and that the answer is picking the right 200K instead of sending the wrong million. Narrow scope is how you get there structurally rather than through tuning. Cheaper and more accurate, for the same reason as before.
The proof point
One of these customers is a retailer. Over nine months, running this pattern, they took their idea-to-production time down by a factor of five.
Be precise about that metric, because it invites scrutiny. Idea to production is wider than DORA’s change lead time, which starts the clock at commit. Theirs starts when a business stakeholder files the request. I think the wider boundary is the honest one for agentic work, because a meaningful share of what these agents do happens before anyone commits anything. Ticket refinement, estimation, sequencing. Measure from the commit and you miss the part the agents changed most.
They did not move their lines-of-code number. I doubt they know what it is anymore because it’s become irrelevant.
And here is the part that matters more: no layoffs. They are using the capacity to take on projects they could never staff before.
In February I argued that a development team is a productivity multiplier rather than a cost center, and in March I made the bank-teller case that automation which expands what’s economically possible tends to expand employment rather than contract it. Both of those were theory when I wrote them. This is the first field evidence I have been able to publish for either one.
Objections
- “Isn’t five agents more operational overhead than one?” Yes. It is the same trade microservices always were, and the same trade small batches always were. More ceremony per unit, less risk per unit. If you have made that trade before, you know whether you liked the outcome.
- “Won’t agents-per-stage recreate our handoff problems?” Conway’s law applies to agents. Your agent topology will mirror your team topology whether you design for it or not, so design for it. That is a constraint to work with, not a gotcha.
- “Systems of record are legacy. Shouldn’t agents live in a purpose-built layer?” The system of record is not where the data is. It is where the humans already look.
The honest caveat
The microservices analogy cuts both ways, and I would rather say so than have it said to me.
Microservices also brought distributed tracing problems, cascading failures, and orchestration complexity that took the industry years to tame. Micro agents will bring their own version of all of it. Observability across five agents is genuinely harder than across one, and right now the tooling for it is thin. What makes the trade worth it is the same thing that made it worth it for services: you can reason about, test, and replace one piece without holding the entire system in your head. And keeping the existing systems of record in place helps mitigate this distributed tracing problem since there aren’t new locations but the same old ones you’ve had for years.
The scoreboard
The lines of code brag was the sound of an industry measuring the only thing AI had obviously changed.
The teams that moved past it stopped asking how much their agents produce and started asking how small they could make each one. Five times faster from idea to production, no layoffs, and a backlog that finally has room in it.
DORA’s metrics have been revised in 2015, 2018, 2021, 2023 and again in 2024, when the four keys became five. What survived every one of those revisions is the pairing underneath them: throughput and stability, measured together, because either one alone will lie to you.
That is still the scoreboard. It was never going to be the tokens or lines of code.