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.

Some of the most impactful engineering breakthroughs likely make for very boring marketing demos.

Over several decades spent leading development teams, I have seen firsthand how tempting it is to focus engineering efforts on highly visible, flashy new features. I’ve known many developers who get bogged down by the pressure to package every software update with a supremely marketable new element or two that’ll get people talking.

But in my experience, the features that most enhance a user interface are often completely invisible to users.

Performance, reliability and security are not the sexiest features, but they’re crucial elements to a satisfactory user experience. That’s especially true when you’re engineering for users working within complex vertical industries – such as architecture – who count on simple, dependable technology to bring their daily work to life as seamlessly as possible.

My foundational philosophy is that the absolute best software is the kind you can dig into without ever needing to pick up the user manual. Users shouldn’t have to spend valuable time fighting to navigate complex menus, acting as manual data routers who must convert one format to another just to connect the dots. When professionals can focus on using their tool as solely a means to an end rather than a puzzle they have to solve, that is when you know you have done your job well as a developer.

The unsung heroes of successful software: Speed, reliability and security

R&D teams often must fight to justify investing in foundational software improvements because they simply aren’t as visually marketable as shiny new capabilities. But performance is a hidden expectation that great developers cannot afford to ignore.

As a Chief Technology Officer guiding design software development for AEC professionals, I’ve learned modern users have incredibly high standards for speed. This is especially true for younger users just entering the workforce. If they have to wait more than a few seconds for their tool to function as directed, it will come at a cost to their sustained attention and workflow.

Reliability is also paramount for modern tech professionals, particularly as we integrate more automation and artificial intelligence into our workflows. When we implement automation to handle boring, repetitive tasks, our users need to know that the system is worthy of their rock-solid trust and can execute those tasks flawlessly.

To use an example relevant to my market, imagine you’re an architect designing a highly complex, multi-million-dollar project for a new hospital with thousands of rooms. You’re collaborating with dozens of other engineers from multiple disciplines, both structural and electrical, and all of you are working on the same model. If you direct the software to automatically update the wall weights across all the bathrooms in the entire hospital, you’re investing your absolute trust in that software accomplishing the task exactly right without interfering with other modeling being done simultaneously.

If the program is unsuccessful or hinders other parts of the project, the user loses trust in the software and the greater team loses trust in the user. That kind of trust is hard to build back.

And if the mistake is not addressed quickly, it could prove costly – potentially pouring significant additional spend into the project budget and contributing to the $2.1 trillion in project cost overruns that occur globally each year. What starts as a simple glitch in software performance can end with significant damage, the kind that could prevent users from ever going back to that tool.

For a similar reason, security is another pivotal foundational element developers must prioritize. In fact, data protection must be prioritized above all else – especially in fields like architecture where you’re dealing with a lot of precious intellectual property. A software user could not care less if an incredible new, time-saving feature is unveiled if, simultaneously, the software environment isn’t secure and their files are vulnerable to corruption.

Developers must focus primarily on protecting the complex digital assets and sensitive information handled with their software. To bring back our hypothetical architect, imagine a project to upgrade a government intelligence facility, with building floor plans that reveal the locations of secure rooms, surveillance locations, emergency exits and other privileged intel that, if put into the wrong hands, could jeopardize the safety of those working on-site.

Ensuring data is never lost, providing redundant storage and keeping sensitive information safe is our absolute baseline responsibility to users. While we might only briefly mention security enhancements in marketing collateral, it is a continual investment in a secure, reliable environment that keeps good software good.

Learning when what glitters isn’t gold

To measure the true return on investment for our R&D efforts here at Graphisoft, we rely heavily on product telemetry to see what users actually engage with. We recently introduced a brand-new, AI-ready data platform that allows us to analyze anonymized usage logs to see exactly which functions are being used and which are being ignored. This data is essential because if the product team convinces us to build something they believe is vital, we can calculate the development cost and then track if it delivers real value to our users.

A while ago, we unveiled a highly visual, flashy tool for our BIM software platform, Archicad, called the AI Visualizer. We were really proud of this tool. Essentially, users could start with a basic drawing or photo of random objects, such as a stack of boxes on a desk. They could then ask the AI Visualizer to create a skin based on the image or drawing, and the software would generate a high-tech office building or a beautiful wooden structure mimicking those shapes. It was an incredibly enjoying tool for creative work at the very beginning of a conceptual design phase.

Based on our continuous usage data analysis, we determined changes were necessary to retain long-term interest in the AI Visualizer – prioritizing enhancements that advanced open standards and seamless collaboration, rather than focusing too heavily on flashy UI additions. The biggest frustration they face is a lack of multidirectional collaboration capabilities and the tedious manual work required to transfer data between closed systems. So, in response, our team homed in on an open, cloud-agnostic environment where our users never feel trapped or dependent on a single provider.

Openness isn’t a flashy UI button, but allowing users to seamlessly connect their dots, export to any format and integrate with any technology is a massive differentiator for user satisfaction.

As a developer, you want users to choose your software every day because it is excellent – not because you have them locked into a closed ecosystem.

The future of intent-based software

I believe we are currently experiencing a paradigm shift away from traditional, click-heavy interfaces and toward what we call “intent-based design” that allows architects and engineers to specify a destination and letting the software itself figure out how to get there.

Across most vertical industries, R&D teams are building toward an AI-native nervous system that digitalizes common knowledge, allowing software to continuously learn and execute tasks based on a massive internal knowledge graph. This trend will contribute to increased intent-based design – and I believe that even in the near future, the user manual will become obsolete.

Rather than having to manually execute against each step in the engineering process, intent-based workflows allow a user to convey a vision and prompt the software to bring it to life based on the low-level functions and knowledge already built into its system. In architecture, for example, that means prompting your BIM modeling software to design a house within the specific parameters of Frank Lloyd Wright’s architectural style, rather than manually guiding it through each of those individual parameters yourself.

An argument for “boring” R&D

My ultimate goal is for our software to act as a quiet partner to great work. I think about it the same way as working with a great human colleague who you don’t have to over-explain every tiny detail to; instead, they understand where you’re headed as soon as you’re halfway there, understanding you in half the words and getting to work in half the time.

I want our software to behave the same way with, for example, intuitively predicting a user’s next step, seamlessly guiding them through new features without requiring any training. Our goal is to handle boring, repetitive tasks so users can remain fully immersed in their creative flow. With that we can provide immense value while demanding minimal attention, prioritizing what’s functional over what’s flashy.

When it comes to R&D, the sexy new features might get people in the door, but it is the invisible strength, the relentless reliability and the quiet partnership of the software that will keep them loyal.

Open the history tab of any epic that has been alive for more than two quarters. Go ahead, pick one. Count the edits. Somewhere around edit 11, the description was rewritten to satisfy a stakeholder who has since changed roles. Around edit 19, the scope was trimmed to protect a date that, in the end, moved anyway. By edit 26 someone renamed the whole thing, and the sentence that explained why the work existed in the first place didn’t survive the paste. 26 edits, several hundred hours of delivery behind them, and nobody left who can say what the money was for.

Nobody deleted that reason on purpose. That’s what makes this so hard to see.

I’ve been shuttling between the people who fund technology work and the teams who deliver it for a couple of decades now, and something has always struck me as odd: the backlog is probably the only important document in the enterprise that gets edited every day and remembers nothing. Contracts have version control and signatures. Financial statements have audit trails. Even architecture, in mature shops, has decision records. But the artifact that actually steers what hundreds of people build week after week? It has a title, a status and a description that mutates until the original intent becomes archaeology.

The most expensive failures I’ve seen were all fast. The teams shipped and shipped, and somewhere along the way the work stopped meaning what everyone assumed it still meant. Nobody slowed down long enough to notice.

One problem, two lenses

Strategy and delivery look at the same work through very different mental models. On one side, leaders talk in outcomes, intent and value; they worry about whether the original justification for the investment still holds months later. On the other side, teams think in iterations, flow and momentum, and they worry about keeping complex programs moving in small, manageable steps. Both lenses are legitimate, and in my experience both sides generally believe they’re the ones doing everything right.

The disagreement between them is never loud. Strategy quietly assumes the logic will remain constant across every sprint and every decision. Delivery quietly assumes the strategic reasoning will naturally update itself based on what gets learned along the way. There’s nothing wrong with either assumption on its own. But in the absence of a structural bridge between them, every program gradually accumulates small half-measures and shifted meanings that nobody registers until it’s too late.

The evidence on how badly intent travels is humbling. Donald Sull and his colleagues, in a multi-year study of strategy execution, found that only half of middle managers can name any of their company’s top five priorities. Those are the managers. Now imagine the epic, eleven edits later.

Let me be fair to agile here, because agile is not the villain. It does exactly what it says on the tin: it helps teams learn quickly and adjust to what they discover, and that speed is a genuine strength. The problem is that organizations blur the line between two kinds of change. Some of it is genuine learning: teams discover real behaviors, markets shift, leaders sharpen their thinking. And some of it is erosion, the slow loss of rationale that nobody actually decided and nobody can trace back to a witting choice. From the outside, the two are indistinguishable. They show up the same way in the tooling: movement in the backlog, shifting priorities, even working software. Only one of them stays anchored to the reason the money was spent.

Most organizations have no instrument for telling these two apart. Which means they’re flying at full speed without knowing whether they’re navigating or just moving.

The pattern we keep seeing

Agile in style, not in substance

The board gets moved every day, stand-ups start on time and retrospectives produce long lists of things to improve. Then you ask why a specific feature exists, what it’s actually meant to change, and the room gets quiet. The rituals persist while the substance underneath them slowly thins out. Teams keep closing tasks, and somewhere along the way they shed the shared sense of purpose that made the tasks worth doing.

Velocity becomes a proxy for value

A smooth sprint demo can hide a deeper problem, because progress toward delivery and progress toward outcomes are two different measurements, and only one of them is on the wall. I’ve seen features that were stable, polished and warmly received in the demo, and that contributed absolutely nothing to the decision they were supposed to improve. The pace was real enough; whether any of it mattered took months to find out. And your delivery metrics can be excellent, genuinely excellent, while every one of these patterns is running underneath them.

This is not a niche affliction, by the way. Pendo analyzed feature usage across hundreds of software products and found that 80% of features are rarely or never used. Built at full velocity, shipped into silence.

Product owners absorb pressure instead of defending logic

The PO is supposed to hold the thread, to protect the reasoning behind the work when everyone else is pushing on it. In practice, many find themselves wedged between demand and delivery, forced into a permanent state of reactive prioritization. Over time they stop challenging requests. Then they stop defending the logic behind decisions. Eventually they stop framing choices around outcomes at all, and the backlog, which should be a strategic instrument, turns into the place where everything gets dumped because nobody has the space left to ask what actually belongs there.

Backlog churn masks strategic drift

Items get revisited, split, recast and reprioritized as everyone works to keep momentum going, and from a distance it can all look like reasonable adaptation. But when the connection to intent is severed, all that motion begins to dissolve into static. Work keeps getting passed around, the board stays busy and the program veers off course without producing a single alarming signal, because busy is what everyone was looking for.

Every quarter is a reset

New OKRs arrive. A fresh wave of leadership messaging follows. Sometimes the team gets reshuffled too. With each round, a little of the shared context that held everything together quietly slips away. Epics get new names, stories get rewritten, priorities rearrange themselves almost by accident. The organization keeps rebooting itself without ever asking what it left behind in the reset.

Taken one at a time, each of these patterns is understandable, even forgivable. Together they produce a program that looks healthy from every angle while it quietly hollows out the meaning behind the work.

Why this keeps happening, and why it’s about to get worse

Big programs tend to assume that intent will simply carry itself forward as the work passes through teams, decisions and iterations. It won’t. Intent doesn’t carry itself. If nobody actively preserves and updates the reasoning, it starts to loosen and fray, quietly and almost politely, one story, one trade-off, one shift in priority at a time.

The structural cause is a speed mismatch that most governance was never designed for. The delivery system evolves in hours; the organization’s memory of why updates in quarters, if at all. In between those two clocks, thousands of micro-decisions reshape what the work means, far faster than anyone captures the reasoning behind them.

Now add what’s happening in 2026. AI agents inside the delivery tooling can already organize, create and edit backlog items on a team’s behalf. Atlassian’s own customers describe agents that generate requirements, break them into epics and stories and take delegated work like a teammate, and these capabilities now ship inside the standard Jira plans that most enterprises already pay for. I’m not against any of this; some of it is genuinely useful. But notice what it means for our problem. Every one of those operations is an edit to a document that has no memory. Backlog amnesia at human speed was survivable. Painful, but survivable, because humans forget slowly. Amnesia at machine speed is a different animal altogether. The ratio of motion to memory, already unhealthy in most organizations, is about to go vertical.

If your backlog can’t remember why an item exists after a human rewrote it a few times, think about what happens when an agent grooms it continuously.

What to do about it

The countermeasures I use are deliberately small. None of them adds a ceremony, a tool, or a governance layer. They simply orient the practices teams already run toward one job: keeping the reasoning alive while the work moves. Together, they form the discipline I call Structural Agile.

• Start with the outcome. Before an epic or major story enters the backlog, three questions, every time: What behavior are we trying to shift? How will we know if that behavior changes? What signals will confirm success after release? If the room can’t answer, the work waits, because items that lack outcome clarity tend to drift first and drift fastest.
• Elevate the PO. Position the product owner as the carrier of outcome logic, with an explicit mandate to preserve rationale, flag trade-offs that erode intent and track deferred items together with the reasoning behind them. And be realistic about the limits, because many POs inherit chaotic backlogs, rotate mid-stream, or simply lack the authority to push back on stakeholders. The rule I give teams is simple: if the PO can’t carry the logic, someone must: a coach prompting context checks, an architect recording the reasoning behind technical trade-offs, an analyst keeping the outcome picture current. Build logic stewardship into the structure. Left to personality, it leaves with the person.
• Anchor epics to why. Every epic carries its rationale as metadata, inside the tool where the work actually lives. Slide decks from last spring don’t count. When a decision reshapes the epic, the rationale gets updated in the same motion; waivers and scope cuts get recorded next to the item they changed. Do this consistently and the backlog stops being a queue of tasks and becomes a living map of intent, one that a new joiner can read on day one, and that survives a challenge from leadership without anyone having to reconstruct history from memory. It cuts both ways, too: the same rationale that protects the team from whiplash protects the business from a backlog that has drifted away from what they actually asked for. Prioritization turns into a conversation about evidence rather than a contest of opinions.
• Rehearse erosion. This is the practice I’d start with, and the one that surprises teams most. Every two or three sprints, run a short, structured session that is not a retrospective and not a risk review. Its purpose is to test the continuity of intent itself: Does the assumed user behavior still make sense? Where might adoption fail even though delivery is technically correct? Which parts of the outcome logic feel fragile, outdated, or untested? A retro examines how the team worked; an erosion rehearsal examines whether the reasoning still holds. You rehearse erosion the same way pilots rehearse emergencies: you hope the drill is wasted, and you run it anyway, because catching drift early is what makes fixing it cheap. In my experience, a single one of these sessions surfaces more strategic risk than a quarter’s worth of status reporting, and it costs the team about half an hour.
• Keep the logic alive. Capture only what prevents strategic amnesia and nothing more: why a feature was removed or reshaped, who approved it and which assumptions should be revisited, and when. Keep it visible where teams already work. If logic lives in Confluence but dies in conversation, it’s already gone.

Start Monday

You don’t need a reorganization or a new framework to begin, and frankly you shouldn’t want one. Three entry points, close to zero overhead. Assign a critical reviewer: one team member whose standing job is to periodically ask whether stories still connect to the intended outcome. Add a one-minute outcome check before major refinements: the behavior targeted, the indicator watched, the signal expected. And run a single erosion rehearsal on your most important program; teams usually surface something real in the first session, long before it would have shown up in any metric.

For readers keeping score: yes, neighboring practices exist, and they’re good ones. Architecture decision records preserve the why behind technical choices, and impact mapping connects deliverables to goals at planning time. I use both. Neither operates continuously, inside the backlog, at the level of the individual item, which happens to be exactly where the forgetting occurs. OKRs don’t solve it either; objectives at altitude are necessary, but teams still need the rationale embedded in the work itself, so they don’t have to keep a separate decoder.

The history tab, revisited

Go back to that epic with the twenty-six edits, and imagine the same history with one difference: each consequential edit carries a line of reasoning, current and human-readable, and every few sprints someone deliberately tested whether that reasoning still held. Same team, same velocity, same tool and a completely different answer when someone finally asks why the work exists.

Velocity tells you how fast the work is moving. Only memory can tell you whether anyone still knows where it’s going.

I’ve published the full discipline behind this approach (the five principles, the roles, the facilitation guides and the objections seasoned practitioners will raise, along with my answers) as a featured paper in PM World Journal. The mechanics are free to steal. The forgetting, at this point, is optional.