The 3 Ways of Agentic Software Development

The 2026 CircleCI State of Software Delivery report confirmed what many of us had suspected: AI-driven code generation is real and measurable, but most teams are not converting it into shipped software.

• Average throughput is up 59% YoY across 28M+ workflows.
• For the median team, feature branch throughput is up 15%.
• For the median team, main branch (production) throughput is down 7%.
• Main branch success rate is at its lowest in 5 years.
• When there is a failure, time to recover is up 10% on main over last year.

More code is being written than ever, and less of it is reaching production. When it does reach production, it fails more often and takes longer to recover. Unfortunately, there is no revenue on feature branches. That’s inventory. Earnings happen when software is in production if it runs well and customers want to buy it.

Boards all over the world want to see more AI. But unless your company is in the top 5% of the CircleCI report, AI adoption is hurting EBITDA. Is this the great AI future we were promised?

We’ve gone through technology revolutions before where the elite performers jumped out ahead. How do we close the gap?

The 3 Ways

Delivering software is a sociotechnical system. There are no complex systems on the planet that are not.

• Aircraft carrier operations are sociotechnical systems
• Hospital operating rooms are sociotechnical systems
• Nuclear power plant operations are sociotechnical systems
• Airplane cockpits are sociotechnical systems

As much as we’re being promised that if we just feed the right Markdown files to our non-deterministic agents we won’t need humans involved anymore, that has never worked out well for any automation in history.

If companies are using automation to write code and most are worse off for it, how do we course correct? What can we learn from other sociotechnical systems? What’s missing?

In The Phoenix Project, a novel about how to deliver in a fictional software company, Gene Kim and his fellow authors describe the 3 Ways, which are based on long established high performing organization principles (cybernetics, Lean, etc.) Because the novel is about IT, this framework is well suited to examine the current patterns, and failures in agentic software delivery.

Regardless of how well they are doing it, most teams taking agentic AI seriously are executing on the 1st and 2nd Way. What almost all of the industry is missing, are the things that were the realm of the elite before (e.g. FAANG), which portcos used to skip and still get by. Now, by not doing the 3rd way, they are failing, as we can see clearly above.

The First Way — Systems Thinking

The First Way emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department…always seeking to increase flow, and always seeking to achieve profound understanding of the system (as per Deming).

The First Way is something that is currently actually fairly well practiced with agentic engineering, even as it is evolving. People are re-examining team structures, flows of work, and most importantly, Harness Engineering.

Because development time is collapsing rapidly, the bottlenecks are moving to other parts of the system. If a developer writes code 3x faster, but is still expecting the team in India to manually QA the code that was written, they are going to have a lot more trouble shipping to production. Sure, feature branch commits may rise (inventory), but our customers don’t pay for feature branches, they pay for code they can actually use.

Code generation is no longer the constraint. Validation and integration are. In fact, this is exactly what the data shows.

According to a Concordia University study: “the primary cost of agentic software engineering isn’t writing code — it’s refining it. Code Review and Code Completion together account for over 86% of token consumption in the tasks where both ran. This suggests that the real expense lies in the iterative verification and refinement loop, not in the initial generation.” (via RDEL)

Unshipped code is work in progress (WIP) inventory: it does not reduce COGS, nor does it improve Gross Margin. It does not show up in ARR. It sits in feature branches, depreciating, while the team that wrote it gets paid.

While there are definitely problems in agentic delivery, the 1st Way is the way that most teams understand, at least in principle. People are still working out the mechanisms to resolve their particular bottlenecks to be able to get the code all the way to production. AI amplifies both good and bad software delivery systems.

If a team was not shipping every day already, using AI will not make that happen any faster. There are too many other bottlenecks. I see (and help) these teams inside portcos regularly.

The Second Way — Feedback Loops

The Second Way is about creating the right to left feedback loops. The goal of almost any process improvement initiative is to shorten and amplify feedback loops so necessary corrections can be continually made.

The 2nd Way is also fairly well understood by software teams. They know that if there is manual QA, it will not fit into an agentic workflow. Supervisor agents need explicit, machine-readable acceptance criteria to know whether what they have developed does the job. That’s fast feedback. Waiting for a human to validate that in the middle of a process eliminates the agentic throughput gains.

Humans can still check the final output, but mid-stream, the feedback loops need to be short and meaningful. Right now we’re not seeing it. The data shows only about 70% of attempts to integrate changes into production succeed, well below the 90% benchmark for a healthy pipeline.

Teams recognize this is a problem, but as the CircleCI data shows, recognition and execution are different things. Ways 1 and 2 are diagnosable and fixable with the right structural work. This is the part of Harness Engineering that most people are working on.

The harder problem, and the one only the very best software people are even talking about, is the Third Way.

The Third Way — Continual Experimentation and Learning

The Third Way is about creating a culture that fosters two things: continual experimentation, taking risks and learning from failure; and understanding that repetition and practice is the prerequisite to mastery…The outcomes of the Third Way include allocating time for the improvement of daily work, creating rituals that reward the team for taking risks, and introducing faults into the system to increase resilience.

“We already learned this lesson once in infrastructure: you can automate yourself into a very resilient catastrophe machine. Systems can appear healthy by local metrics while globally becoming incomprehensible. Bug reports can go down while latent risk explodes. Test coverage can rise while semantic understanding falls. Changes happens (sic) so fast that nobody notices the underlying architecture decaying.” - Mitchell Hashimoto, Founder, Hashicorp (an IBM company)

“A very resilient catastrophe machine” is what the CircleCI data is telling us that software portcos are currently building. Metrics like lines of code might be going up, but they are on feature branches, not in production. When we do ship to production the software itself is “incomprehensible”, with low “semantic understanding”. This is why the time to recover (TTR) statistics are ballooning.

We’re writing more code that nobody understands and hoping that somehow, when things go wrong, that the agents who created the problem will also be the solution. That is a fool’s bet.

The way out is the 3rd Way.

Experimentation

The 3rd Way calls for more experimentation, and that’s exactly what should be happening. The cost of writing code has collapsed, so the cost of trying things has collapsed with it. That’s a feature, not a bug.

The problem is what experimentation is supposed to produce: more and higher-quality deliverables shipped to customers. The CircleCI data shows the opposite. Teams are experimenting more (feature branch throughput up 15% for the median team) and shipping less to main (down 7%), with main branch success rates at a five-year low. That’s experimentation without the outcome experimentation is supposed to generate. That’s capital invested without return.

The experimentation is supposed to be done safely (feature flags, dark launching), but instead, teams have not built robust methodologies for this. When I did an AI Readiness Assessment across dozens of portcos for a large European PE firm, this is exactly what almost every single portco got wrong. Things that the DORA elite software companies have been doing for years. With agentic AI, these methods are no longer optional.

The financial consequence is rework: code that gets written, shipped, breaks, gets reverted, gets rewritten. Rework is OpEx with no revenue attached. Enough of it, and it compresses EBITDA directly.

Understanding & Learning

Teams aren’t investing in understanding what the agent wrote. They aren’t building the muscle to figure out why it works, why it fails, or how it interacts with the rest of the system. Without that, they can’t improve their feedback loops, which feeds the Second Way failure mode and compounds. The same classes of failures recur because nobody learned from the last one. That shows up as elevated cloud spend, elevated on-call burden, and elevated incident volume reaching customers. All three are direct hits to Gross Margin in a SaaS P&L, and they don’t respond to the usual cost interventions because the underlying cause is structural.

I wrote a LinkedIn post calling for more architectural meetings inside software companies. This is to create more understanding about what we’re building, and how and why we’re building it, so that we can have a much better understanding of what we have. The response was to be shouted down by an “AI engineer” who explained that we don’t need to understand because the agents are so fast, they will just fix it. A perfect encapsulation of Mitchell’s “changes happen so fast that nobody notices the underlying architecture decaying”.

Noted software luminary and current AI proponent and historian John Willis puts it bluntly: “We need to define AI slop as something more damaging than low-quality output. It includes code that technically works but is hard to understand, and documents that sound polished but offer little substance. It manifests as decisions made faster than they can be reviewed, workflows that feel productive while quietly creating risk, and teams shipping more while learning less.”

The 3rd way calls for “learning from failure” and “and introducing faults into the system to increase resilience.” Why?

Chaos Engineering and Resilience Engineering exist for exactly this problem. Production systems interact with code the team did not write. That’s been true forever: third-party dependencies, legacy systems, other teams’ services. We’ve been on the microservices train for a long time and there is absolutely no way to predict all the possible interactions between your code and code you did not write in a complex distributed system. This is why Netflix invented the Chaos Monkey. To expose the latent bugs that exist in a system where hundreds or thousands of components are constantly changing.

Agentic development just makes it dramatically more pronounced but almost no one has adopted these elite techniques. Now not only do we not understand what others wrote, we might not have a great understanding of what our agents wrote. Resilience Engineering as a discipline (why things go wrong, why things go right) has been studying this for two decades. Almost no one applying agents to production systems is drawing on any of it.

The Results

The consequence in the data: the CircleCI report shows code is breaking more often when teams try to ship it, and recovery from those failures is taking longer and getting harder. That’s the 3rd Way failure mode showing up in the metrics. Teams that don’t experiment safely don’t learn. It’s all firefighting, or worse, handing off to more agents. Teams that don’t learn can’t improve their feedback loops. Teams with poor feedback loops produce more breakage. It’s a death spiral and the rework, the cloud spend, and the on-call burden, compound right along with it.

Ways 1 and 2 can be addressed with tooling, process, and structural investment. This is Harness Engineering. The Third Way is harder because it’s about how the engineering organization treats production, failure, and learning. It can’t be bought. It has to be built. Ways 1 and 2 have plenty of vendors who will sell tools to shorten processes through automation or have frameworks to sell like coaches used to sell Scrum.

Way 3 requires changing the way the organization functions to adopt methodologies that were only for the elites, until now. Now we can plainly see why those massively scaled organizations adopted or invented them in the first place.

This is not a curve that converges. AI-driven acceleration amplifies existing delivery strengths and weaknesses. The teams that have all three Ways working compound; the teams that only have Ways 1 and 2 don’t, because Way 3 is what helps them learn from each cycle. The remediation work is not optional, and it doesn’t get easier by waiting. The teams that recognize the Third Way is the missing piece will close the gap. The ones that keep buying tools and skipping the cultural and structural work around production, failure, and learning will keep producing the metrics CircleCI is now reporting at scale.

At exit, buyers are going to look at engineering systems the way they look at financial systems today. The diligence gap is going to be quantitative, not qualitative, and we already see the metrics above that will compress multiples.

Which future?

Harness Engineering is absolutely necessary, but not sufficient. It addresses Ways 1 and 2. The Third Way — experimentation, risk-taking, and learning from failure, is what separates the portcos that will compound from the ones that will plateau.

Most software teams have gotten by for decades focusing on Ways 1 and 2. If you had automated CI/CD you were considered a high performer. That’s Way number 2.

Elite software delivery organizations went beyond to really understand how their systems worked. They didn’t simply do post-mortems to generate action items, they did it to learn how their systems were truly constructed so they could push the limits safely. This is why Netflix built ML-backed deployments. This is why Google created error budgets.

Now people are writing code at blinding speed without the understanding, and with the simplified notion that automated tests are guardrails. They are not. They are bumpers.

The way out is to get good at delivering software.