Last week, we had the first Infrastructure and Ops superstream of 2026, Platform engineering in the age of AI. Our speakers explored a range of topics focused on supporting new AI workloads, each with unique infrastructure needs, unexpected costs, and new security concerns. Google Cloud’s Abdel Saghiour told the audience what a good platform for AI looks like, Cockroach Labs’ Jordan Lewis shared lessons learned about starting a corporate AI platform, Sintaso’s Daniel Bryant outlined a three-layer model for building a good platform, technology leader Sarah Wells discussed the importance of governance and how to make it more manageable, and ThoughtWorks’ Ben O’Mahony explains why evals should be part of your overview story. you can Watch the highlights here.
The event concluded with a fiery conversation between Sam and Nathan Harvey, who leads the DORA team at Google Cloud. Dora They’ve been tracking software delivery performance for over a decade, which means they’ve seen many technology trends coming. At their center of gravity there has always been a single question: How quickly and safely can a team make changes to a running production application?
AI hasn’t changed that question, although it has made it a little harder to answer. Dora recently released this ROI of AI-assisted software development report To show how AI is working for teams right now, and how it may or may not contribute to organizations’ bottom lines. Nathan used the findings as a starting point to explore how AI is changing platform engineering and software development as a whole.
productivity gap
Sam started by pointing out one of the biggest findings of DORA’s 2025 data: organizations saw nearly a 10% improvement in terms of actual code sent to production systems. Even if developers feel they were more productive, this does not automatically translate to production. DORA’s data shows high volatility as well as high throughput. In other words, teams are shipping more but they are rolling back changes or implementing fixes more frequently. The benefits at the individual level are real (and 10% is a pretty good number), but these benefits “aren’t the dramatic improvements you see in the headlines.”
AI enhances good processes (and bad processes)
Nathan explained that AI is an amplifier and mirror that reflects the good and the bad equally. In teams where shipping changes is already easy, AI keeps things running nicely. AI arises in teams where it is painful to make changes to production More Change and makes existing friction more intense. That said, his statement about this outcome is cautiously optimistic: “If the pain is more intense, we will probably invest in alleviating that pain.”
The problem is that the investment must actually take place. Nathen said that in low-performing organizations, AI tools often come with a reset of expectations rather than an invitation to fix the process: Here’s your new tool. Now we have even more expectations from you. Solving this problem means reframing the question as “Does AI make people more productive?” What we should really be asking is “Under what conditions will AI boost productivity, and who is responsible for creating them?” And it depends on the organization, not the technology.
validation no checkbox
Trust is a big challenge with generative AI. Nearly 30% of DORA survey respondents trust AI output little or not at all. About 46% trust it “somewhat” (and Nathan is one of them). Despite all the advances in generative AI, these tools still make mistakes, and if you have multiplied your ability to generate code without doing anything to increase your ability to verify it, you have made your situation worse, not better.
Nathan calls this the verification tax, and it is included in any honest accounting of the productivity impact of AI. Pipeline optimization also comes into play: is your delivery pipeline fit for purpose given the transformation you are now trying to achieve? These costs don’t show up in headlines about 10x developer productivity. They appear in your incident reports three months later.
Dora recently published a ROI Framework and Calculator For AI-assisted software development. Nathan was clear that there is no universal number to offer, and the calculator does not pretend otherwise. What this does is give teams a way to model the real costs, including learning investment, validation overhead, and required pipeline changes.
Context change and burnout
With increased productivity, AI-induced burnout is becoming a serious concern. (Steve Yegge calls it “oh vampire.”) Dora’s data for 2025 showed that AI adoption has no strong correlation to burnout, with the caveat that about 64% of Dora survey respondents said they had never worked in an agentic workflow. Both of those findings are likely to change significantly in 2026.
Nathan highlighted one source of burnout that he expects will increase as agents become the norm: context switching. As he points out, software developers spent years arguing for protected focus time for intensive work that requires them to maintain flow. Agent workflows are now encouraging those same developers to arbitrarily run a dozen or more agents simultaneously, forcing them to context-switch multiple times every hour. As he joked, “There’s a lot of research that supports the idea that we all think we’re great multitaskers and none of us are.” The results are coming, and we’re doing it ourselves.
cognitive debt questions
Sam Newman brought up the related notion of “cognitive debt”, and in particular, Margaret-Anne Storey discussed it. (Look “How generative and agentic AI shift concerns from technical debt to cognitive debt” And “From technical debt to cognitive and intent debt: Rethinking software health in the age of AI..”) Here’s how Storey explains the problem in his blog post:
The debt accrued from moving fast sticks in the minds of developers and affects their life experiences and abilities to “move up fast” or make change. Even if AI agents produce code that may be easy to understand, the humans involved may simply have lost the plot and not understand what the program is supposed to do, how its intentions were implemented, or possibly how to change it.
And as Sam said, it blends across teams and organizations. As developers are working in parallel with AI instead of each other, they lose the shared understanding that comes from people creating software together. Kent Beck once said that “Software design is an exercise in human relationships” Agent workflows are putting pressure on that in ways we’re just starting to see.
Nathan agreed that cognitive debt is where he is most concerned, and both your worker and your architecture will suffer for it. It takes years to understand the impact of an architectural decision you made eight months ago, and AI doesn’t help with that at all.
Invest in your platform now
Reflecting on what makes some AI-assisted teams high-performing, Nathan explained, “It’s not He You are using AI but How You are using AI.” This observation inspired Dora to develop seven abilities When this is combined with AI adoption, better results are achieved. Nathan briefly studied the list and finally landed on a quality internal platform. And here he made a claim about software engineering investing that was, in his words, “a little bit wild”:
Every product engineer you have in your organization, every engineer who is focused on building features right now, should probably stop building features and focus on the platform.
He argues that platforms matter more, not less, in an environment where AI makes it possible for almost anyone in an organization to create something. The people closest to customers and business problems can now produce working software. They cannot ensure that the software is durable, secure, and production ready.
Nathan suggested that the best return for software engineering investments today may be to build platforms that provide those guardrails, shifting the complexity of production-readiness into the infrastructure so that anyone building on top of it can have a safety net for free. He acknowledged that moving every product engineer to platform work might be excessive. But the direction of travel is real. As Newman pointed out, this is also the platform where you bring determinism back into a process that AI has made more non-deterministic.
This is something we’re hearing a lot here at O’Reilly. Expanding who can build does not diminish the need for deep engineering expertise. This changes where that expertise is most valuable, and where the platform is a good answer.
What does Dora’s research tell us
The teams that are performing well are experimenting, learning from them, and spreading those lessons. The measure that Nathan suggests is not how many tokens you have consumed, but how many experiments you have run and how well you are distributing what you have learned.
Devices are advancing so rapidly that any organization will be stuck in a fixed policy around specific devices. What you want is the ability to keep learning, which means creating a culture and processes that make learning visible and transferable.
All DORA research is available for free dora.devWhich includes the annual report and ROI outline to 2025. dora community Provides a space for practitioners to work together on these questions. If you’re trying to navigate any of these with your team, you might want to spend some time there.
And if you want to delve deeper into Nathan and Sam’s conversation or explore other sessions, you can do so View the complete Infrastructure & Ops Superstream On the O’Reilly teaching platform. Our next event, on September 9, will cover Agentic Observability. Register for free here, and check out all the other free live events on O’Reilly.
