Is AI-native Engineering Really DevOps 2.0 (or even Agile 3.0)?

A brief history of DevOps

DevOps didn't start with a plan – it started with one guy showing up to an empty session.

At Agile 2008 in Toronto, Andrew Clay Shafer pitched a talk called "Agile Infrastructure", with the idea being IT operations deserved to have the same iterative, collaborative treatment and approach that development teams had implemented from Agile. But nobody cared – nobody showed up. Except for a Belgian consultant, Patrick Debois, who had spent years working both sides of the developer and operations fence and was sick of watching work fly over the walls and further split the divide, when they should all be working together. Two people, one empty room and a shared complaint: Agile "fixed" development and left operations exactly where it found it.

That shared complaint sat, and percolated for almost a year, until in June 2009 when John Allspaw and Paul Hammond got on stage at Velocity and gave "10+ Deploys Per Day: Dev and Ops Cooperation at Flickr." At the time, the very thought of deploying that many times per day, much less per week, seemed outrageous. Yet Flickr was actually shipping to production dozens of times a day and had stopped working as separate teams with a handoff between them and started working as one team. 

Debois saw a recording of the talk and posted his thoughts on Twitter using the hashtag  #devops, then did what seemed obvious to him: build an event around that idea instead of waiting for someone else's conference to make room for the discussion. What came out of that was DevOpsDays Ghent in 2009, and what started as "two guys in a hallway" became an industry.

The state of the DevOps movement today

While DevOps revolutionized how a lot of people thought about technical work, it was never a universal win. Here we are, seventeen years on from Debois' first inklings, and we still have siloed teams, conferences proselytizing the need to "adopt DevOps," and enterprises just beginning their DevOps journey while simultaneously trying to leap into the AI-native world. In other words, adoption isn't following a consistent sequence.

It's not as 100% as you'd think

The skepticism isn't just vibes - DORA backs it up. In 2024, only 20% of engineering teams qualified as elite performers, while the low-performance tier swelled from 17% to 25%. By 2025, DORA quietly dropped the old performance tiers altogether in favor of "team profiles" that weigh cultural and human signals alongside delivery metrics - which is a diplomatic way of admitting the old scorecard had become measurement theater. Even under the new, more forgiving framework, the top two profiles (Pragmatic Performers and Harmonious High-Achievers) account for only 40% of the industry. Most organizations are stuck in the middle, running DevOps as ceremony without substance.

Often waterfall with scrum, not even truly agile

Organizations bolted on a Scrum Master and a daily standup and called themselves Agile - ceremony over substance - then slapped a DevOps label on whatever CI/CD tooling they already had, regardless of whether the underlying culture ever changed. You can usually spot the pattern: change approval boards that still exist under a friendlier name, quarterly release trains wearing a sprint costume and changes that Ops still discovers for the first time at deploy. The org chart didn't move. Only the vocabulary did.

AI's arrival has made the siloing worse, not better

GitLab's Global DevSecOps report coined it the "AI Paradox": AI accelerates coding, but fragmented toolchains and compliance complexity turn that speed into a bottleneck somewhere else. Sixty percent of teams are now running more than five tools, and 49% are running more than five AI tools specifically - which is less a tech stack than a tech stack's tech stack. MuleSoft found that half of AI agents operate in isolated silos, and only 54% of organizations have anything resembling a centralized governance framework for them.

CircleCI's data tells the same story from a different angle: AI is massively accelerating code creation while creating a severe delivery and validation bottleneck, rather than actually increasing shipping velocity. Average daily workflow runs jumped 59% year over year - but that gain was overwhelmingly concentrated in the top 5% of teams. The median team improved 4%. The bottom quarter improved by exactly zero. Feature-branch throughput rose for nearly everyone, which sounds encouraging until you look at the main branch, where median throughput actually fell 7%, the majority sat flat and only the top 5% managed real growth. Main branch success rate hit its lowest point in five years at 70% against a 90% benchmark; a March follow-up showed it climbing back to 76%, still nowhere near the mid-80s teams were hitting as recently as 2023 and 2024.

Developers across the industry are writing more code than they ever have. Almost none of it is reaching production. Activity is up. Delivery isn't.The old bottleneck was how fast someone could type. That bottleneck is gone. What's replaced it is integration, review and recovery - the verification tax - and it's showing up in raw pipeline data with no survey required to find it.

How AINE should help moving forward

Every movement gets a honeymoon phase where it's still allowed to be a fantasy. DevOps had it. Agile had it. AI-native Engineering (AINE) is currently enjoying its own, and like the honeymoons before it, the marketing deck is a lot more coherent than the org chart underneath it. Still, a fantasy worth having is a fantasy worth being specific about, so here are the steps that AINE needs to take if it wants to earn the "2.0" it keeps getting handed for free.

Adjusting workflow for the "modern developer"

Typing was never really the constraint; it just felt like one because it was the visible part. Every workflow we've built over the last two decades, PR sizing conventions, sprint tickets, code review cadences, even the daily standup, was quietly optimized around the assumption that a human generating code is the slow part of the pipeline. That assumption is now false, and most orgs haven't updated a single process to reflect it. They've just handed the same workflow to something that produces ten times the volume and are surprised the pipes are backing up.

A "modern developer" workflow built for the AI-native era stops treating review and validation as a toll booth stapled onto the end of the highway and starts treating them as the road itself. That means generation and verification happening in the same breath - agents that ship a test alongside the change, a rollback plan alongside the deploy, a rationale alongside the diff instead of a human being handed a firehose of code and asked to "just review it like you used to." If AINE just makes the fast part faster without touching the slow part, it's not a new era. It's a faster typewriter.

Building understanding of the full SDLC

Here's the opinion part: most of what's currently being sold as "AI-native" is a copilot bolted onto a tool silo. It writes better code inside the IDE, or triages tickets inside the backlog tool, or drafts a PR description, each one a genuinely useful trick, and each one blind to everything happening one system over. That's exactly the wall Debois complained about in 2008, just rebuilt one layer higher. We spent almost two decades tearing down the wall between Dev and Ops; it would be a special kind of irony to spend the next one building a new wall between "the agent that writes the code" and "the agent, or human, (and ultimately the customer) that has to live with what it wrote."

The actual promise of AINE isn't a smarter autocomplete. It's an understanding of the entire lifecycle: requirements, design, code, test, deploy, observability and incident response living in one continuous context instead of five disconnected tools each with their own AI feature checkbox. An agent that can write a change but has no idea what the on-call rotation looks like, or what compliance sign-off is required, or what broke the last three times this service deployed, isn't AI-native. It's just AI, native to whichever tool sold it to you.

Executing that understanding beyond the developer team

DevOps didn't fail in the places it failed because the tooling was bad. It failed because it stayed a developer initiative that operations were expected to tolerate, rather than a shared responsibility both sides actually owned. AINE is currently sprinting toward the exact same failure mode, just with a wider cast: if "AI-native" stays contained inside engineering - a few agents wired into the IDE, a chatbot in the ticketing tool - while security, compliance, legal and product stay exactly as siloed as they were before, then AINE isn't a transformation. It's a job title change and a new Slack channel, which is precisely the ceremony-over-substance pattern that turned Agile into "waterfall with standups" and DevOps into "CI/CD with a compliance meeting bolted on."

Doing it right means the same people who had to get uncomfortable and share ownership in 2009 (dev and ops, and now security, legal and product) have to get uncomfortable again, this time around agents that touch code review, deployment approval and governance at a scale no single team owns end to end. If the understanding AINE builds never leaves engineering, the verification tax doesn't go away. It just changes which department pays it.

So...is AI-native Engineering DevOps 2.0? Mostly, yes, and not in the flattering way. It's the same fight, dressed in new weapons: a culture problem that keeps getting sold as a tooling problem, in an industry that would very much prefer to buy its way out of organizational change. DevOps proved the tooling was never the hard part. AINE is about to prove it again, unless somebody actually reads the history this time.

To provide your teams with a starting framework and to help think about this shift in software development, we put together a 5-part series which offers a playbook for AI-Native Engineering. Let us know how we can help you on this journey.