NoOps: How AI Agents Are Reinventing DevOps and Software

You ever feel like software development is just this relentless treadmill, you know, new releases, features, patches, It just never stops. Yeah, absolutely, And for so many teams it feels less like build ship learn and more like build ship burnout.

That burnout is real.

But what if there was like a shortcut, a way to make things smoother, faster, more reliable.

That's the million dollar question, isn't it.

Well, today we're diving deep into Roman Verrel's book New Ops. How AI agents are reinventing DevOps and software. It's pretty insightful stuff. Our mission here is to sort of unpack that journey. How do we get from these you know, fragmented systems we have today to a future where software almost runs.

Itself, freeing up people for the really interesting.

Work, exactly, freeing you up to focus on what only humans can do, which is innovate. So we'll explore why traditional DevOps well sometimes it just isn't enough, how standardization kind of leads the groundwork, and then crucially, how generative AI steps in to revolutionize pretty much everything, coding, infrastructure, the works. It's a big shift, it really is. So Okay, let's unpack this. How can we actually get there. How does the drudgery melt away?

The foundation from DevOps evolution to standardization.

Okay, before we jump into like reinventing the future, let's glance back for a second. Remember the old days, the rigid walls between devs and ops.

Oh yeah, that thrown over the wall, mentality.

Role nightmare, right, Yeah, long release cycles, constant finger pointing.

It really was. Now Agile started breaking down those silos within development, which was a good start.

But OPS was still often the bottleneck, definitely.

And then you know, DevOps as a term started gaining traction. Patrick de Bois, the DevOps Days conferences.

And that flicker talk ten plus deployees per day back in two thousand and nine, right.

All spaw and Hammond. That was like a real light bulb moment for a lot of people.

And then the Phoenix project came along in boom. It really brought CICD, shared responsibility, all that stuff into the mainstream.

Yeah, collaboration, automation, measurement, learning, those became the core ideas.

And the results. I mean, look at the door reports, elite teams deploying hundreds of times a day.

It's incredible. Think Amazon, Netflix, It's.

Not just faster. It's a whole different way of operating, adapting almost in real time exactly.

But here's the catch. Despite all that promise, so many organizations are still struggling to get there.

Yeah, why is that? If the path is clear, why are people stuck?

Well, the book points to a few things, new pressures and emerging challenges, like cultural resistance. That's a big one. Up to forty five percent of initiative stalled just on culture.

Wow, nearly half.

Yeah, and then skill gaps and kind of ironically, this thing called tool sprawl.

Okay, tool sprawl, let's dig into that. So if you've adopted DevOps but you still feel stuck, this sounds like a big part of the.

Why it often is. It's this sort of ironic outcome of DevOps. You want the best tool for each makes sense, So you get get for version control, Jenkins for CI, maybe Terraform for your infrastructure, Splunk for monitoring, all good tools on their own, all great tools. But suddenly you've got twenty thirty maybe even more, different tools you're trying to juggle.

Okay, I can see how that gets messy.

Fast, And the book cites this figure. Over fifty percent of enterprises using more than twenty DevOps tools. That creates what VORL calls.

A tool tax cool tax, meaning.

Meaning significant license costs. Yeah, but also constant integration headaches and developers just burning time context switching between all these different interfaces.

Right, jumping from one UI to another, trying to remember how this.

One works exactly. And then there are the data.

Silos, so each tool keeps its own data separately pretty much.

Build logs are over here, test results are there, deployment record somewhere else.

Entirely, which leads to that visibility gap you mentioned precisely.

The book says seventy four percent of teams lack that end to end visibility. So when something breaks, good luck figuring out what happened quickly.

Ouch, So incident response times just go through the roof they.

Do, and it creates these DevOps ironies. Like you tried to break down silos between devnops, but now you've got new silos based on who knows which specific tool.

So more friction, duplicate effort.

Yeah, that whole choose your own tool culture sounds great for innovation initially, but it often just spirals into fragmentation and hidden costs slower time to market, more errors.

The book had that example, right, the financial services firm.

Oh yeah, that was a painful one to read about.

Yeah.

Eight different CI pipelines, three.

Code repositories, different logging systems.

Imagine being an engineer there just trying to track down which version of a micro service was deployed when something went wrong. Hours wasted, and.

It wasn't just the pipelines, right, It went down to the developers machine.

Absolutely, multiple IDEs vs. Code intelliga eclipse. It fragments the whole developer experience, harder to enforce, standards, harder to collapse.

And ultimately, you said, it hurts AI.

Readiness critically, that's the connection to the future. Why does all this fragmentation matter so much for AI? Okay, why because AI, especially generative AI, thrives on data consistent, complete, high quality.

Data right, garbage in garbage.

App Exactly If your logs, metrics test results are scattered everywhere in different formats, any AI trying to find anomalies or generate code is basically working with blind.

Spots, so it just can't see the whole picture.

It can't. Fragmentation is like the number one enemy of advanced AI. And DevOps.

Okay, so the path forward becomes well obvious. I guess standardization, standardization.

But it's not about stifling innovation, right, It's about creating a unified, repeatable, and data friendly framework like.

A golden pipeline, a curated set of tools that work together.

Exactly that streamline collaboration, less operational overhead. The book calls it the anti tool tag. Stronger security, better compliance.

And crucially getting ready for AI.

That's the big payoff. You provide that uniform structured data that these autonomous AI agents need to function effectively. Vorrel puts it bluntly. Without standardization, AI driven automation will never reach its full potential.

So standardization is the blueprint. What about the foundation? The book talks a lot about Cloud Native. Why is that so important here?

Because Cloud native architecture is basically designed for this kind of dynamic, automated world from the get go. Ah, Well, you're using things like micro services, containers think Docker, dynamic orchestration like Kubernetes, infrastructure as code with tools like Terraform.

Okay.

All that enables systems to scale automatically, to self heal when things go wrong, to spin up temporary environments easily. It's the technical underpinning you need for AI agents to really manage things effectively.

Got it. So it provides the flexibility and resilience AI.

Needs exactly, and that connects directly to needing data centric architectures and observes.

Meaning getting all that data in one place, logs, metrics, traces.

Yes, and tagging it consistently so you actually have deep visibility, real time feedback loops. That's the fuel for the AI, and tools.

Like OPS are come in here helping aggregate all that right.

The book mentions ops A specifically because it provides platform agnostic analytics. It integrates with like over eighty different nosec ops tools, wow, eighty plus Yeah, pulling all that data into unified dashboards so leaders can actually see things like deployment frequency, MTTR lead time, regardless of the specific tools.

Underneath, seeing the whole forest, not just the trees. Like you said, precisely, that Retail Giant case study really showed the impact, didn't it. Monthly to daily deploys outages way down.

And their observability shot up. That immediately paved the way for them to start piloting AI for anomaly detection lay the foundation see the benefits quickly.

So if we're aiming for this autonomous future, what does GOOD have actually look like? Is there a reference architecture?

Yeah, the book outlines what GOOD looks like. It's a unified architecture covering everything from requirements all the way to monitoring and production.

And key features are.

Self service for developers, self healing capabilities, security embedded right from the start, not bolted on later, and.

The practical way to get there. That paved road concept exactly.

Part I offers this practical paved road. It's about deliberately choosing a lean stack, often centered around something like gethub Enterprise Cloud maybe with actions for the pipelines, get Hub, Advanced Security gaks for shifting security left okay, OPS area for the analytics and visibility layer we just talked about, and then standardizing the developer workspace, maybe on something like vs.

Code, so collapsing maybe dozens of tools down to a core, cohesive.

Set right, creating that clean telemetry foundation that you need for autonomous new OPS. It's about intentional simplicity driving complex automation.

Okay, sounds good rate in theory, but how do you actually do it? People listening might be thinking, my setup is chaos. Where do I even start?

Yeah, it can feel overwhelming. The book provides an implementation guidance playbook which is pretty helpful.

What are the steps.

It starts with forming an AI gild Tiger team, a dedicated group to lead this. Then baseline your current tool sprawl. You need to know how bad it.

Is first, Okay, measure the mess.

Measure the mess. Then importantly freeze new tool purchases for a while. Stop adding to the problem makes sense. Publish clear standards for co depositories, tagging things like that. Then you systematically migrate teams and projects onto the paved road and track progress absolutely, track ey KPIs, lead time, MTTR, toolcount reduction, even licensed cost savings, and surface all of that in a tool like opserra so everyone can see the progress. It's methodical.

Generative AI transforms the software development life cycle.

Okay, so we've built this solid, standardized runaway. The foundation is there. Now the book really takes off into the revolutionary part generative AI, not just helping operations but actually changing how we write the code itself.

Right, This is where it gets really exciting the rise of AI coding assistance like Gethub. Copilot is just a massive game changer.

More than just autocomplete right, oh, way more.

The book calls it going from autocomplete to intelligent pair programming. It works directly inside VS code, deeply integrated with GitHub.

And the productivity james are real.

They seem to be. We're talking ten to thirty percent boosts generally, but some studies show developers finishing tasks thirty even up to forty seven percent faster. Wow, that's significant, it really is. Think about the example of adding that O off to middleware.

Yeah, thirty three percent faster with copilot. Yeah, because it suggested code helped with unit.

Tests exactly, instant code suggestions, scaffolding for tests. It saves a ton of time, especially on repetitive or boilerplate tasks.

But it's not perfect, right, There must be pitfalls.

Oh definitely. The book is clear about the challenges AI hallucinations where it just makes stuff up. Uh, security risks if it suggests vulnerable code, and just the danger of developers becoming overreliant not thinking critically.

So how do you manage that? You can't just let the AI run wild?

No way, Yeah, best practices are crucial, always human the loop reviews. People need to check the AI's work. Okay, you need to write clear prompts to guide the AI, and you absolutely integrate the AI generated code and tests into your existing CI pipelines. Security tools still need to.

Scan everything, so it's augmentation not replacement.

Augmentation not application that's the key.

Okay, so unit tests. But let's talk about the really thorny stuff, functional and integration testing, especially with micro services, that's always been a huge bottleneck.

Huge, and this is where AI gets really interesting again. Tools like functionize are mentioned.

Functionize what do they do differently?

They use AI to automatically generate functional and integration tests just by watching how users actually interact with the application.

Okay, observing user flows.

But here's the really critical part. They can also self.

Heal the tests self heal, meaning.

Meaning if a minor UI element changes or a button moves slightly, things that would normally break a traditional test script, the AI adapts the test script automatically.

WHOA Okay, that tackles the massive test maintenance burden exactly.

That's often where teams spend most of their testing effort just fixing broken tests.

The e commerce case study nailed this right. Sixty percent reduction in test maintenance.

Yeah, a sixty percent drop, and they got better coverage on critical paths like checkout. That directly speeds up feature delivery because testing isn't such a drag anymore.

And looking even further ahead, the book mentions open AI operator.

Yeah, that's more experimental, but fascinating. It's an AI agent that interacts with an app like a human would, literally using a built in browser, so it looks at the page, It interprets the page, visually, understands high level concepts. It doesn't rely on fragile things like HTMs locators or specific API end points, so it can adapt to changes much more like a person would.

That's kind of mind blowing. It really feels like a step towards true intelligent automation.

It does. It's early days, but the potential is huge.

Okay, so AI is helping write code, helping test code. What about the infrastructure it all runs on? Can AI manage that too?

Yes? Absolutely, generative AI is moving into infrastructure as code iac and also data.

Provisioning, so it can write my terraform for me.

Pretty much. You give it a high level description. I need a standard web server. Setup with these specs, and it can generate the terraform or claudformation scripts. The book suggests this can cut INFRA provisioning time by over sixty percent.

Sixty percent that's huge for standing up new environments.

It is, but it's not just about the initial setup, right.

What about keeping things running smoothly preventing those annoying configured drifts or scaling issues.

That's the next level. AI enables predictive scaling. It analyzes past usage pa terns and scales resources before the spy kits, not after.

Proactive not reactive.

Nice and drift remediation. The AI constantly watches the live environment, compares it to the IEC definition.

And if something's changed someone tweaked a setting manually.

It can either flag it for review or even automatically correct it to bring it back in line with the code definition. Viral highlights how this ensures compliance without constant manual checks. It's like having an automated compliance officer.

That fintech startup example sounded great. Faster environment spin up and better PCI compliance through automated data masking.

Right. It freeze up the ops team from that reactive firefighting to think more strategically.

Which brings us to this stay in the flow idea. What's that about.

It's about bringing these capabilities directly into the developers or operator's main workspace, usually their ide like vs code.

So instead of switching tools, you just talk to the AI essentially.

Yeah. Using natural language processing and LP, you could type something like create a masked copy of production data for this staging environment, okay, or generate terraform for a new micro service based on our standard template. The AI figures it out, proposes the scripts or actions, and.

You review it right there, maybe in a pool request.

Exactly, all without leaving your development context. It removes that friction, keeps you focused. Okay.

That sounds incredibly powerful. So finally, the CICD pipeline itself the heart of DevOps. How does AI make the pipeline smarter?

Several ways? One big one is optimizing the pipeline run itself. AI can do intelligent test.

Selection, meaning it doesn't just run all the tests every single time, right.

It analyzes the specific code changes in a commit and figures out which subset of tests are actually relevant to run.

That could save a lot of time, especially on big test suites.

Huge amounts that e commerce company, example, they cut their forty minute pipeline runs down to twenty minutes just with this.

Wow half the time. That massively speeds up the feedback loop for developopers.

Instantly they know much faster if their change broke something. And when feedback is that fast, developers feel more confident making smaller, more frequent changes.

It changes the whole dynamic.

It really does. And it goes further with predictive failure analysis and remediation.

Okay, what's that.

The AI is watching the pipeline run in real time logs metrics. It can spot anomalies that suggest a test might be flaky or a build environment is misconfigured, and then it might automatically retry a step or even apply a known fix. It can also get smarter about deployments.

And it watches the deployment, watches.

The real time telemetry. If it sees aerror rate spike or performance tank. It can trigger an automatic rollback.

So the pipeline becomes truly adaptive, not just the dumb script runner.

Exactly intelligent, adaptive self healing.

And this also ties into stay in the flow.

Yes, a developer could be in their ID and type deploy this branch to Canary with ten percent traffic, watch for anomalies.

And AI just handles it, triggers the right pipeline monitors, it gives feedback.

That's the vision. The AI interprets the intent, orchestrates the actions and reports back, maybe even suggesting a rollback if needed. It's this frictionless pipeline guided by human intent but executed largely by AI. That's the core of NUOPS. According to the book.

Wow, that final section in part two, Catalyst to Autonomy, really paints a picture of it all coming together.

It does an AI first paved road, copilot and VS code helping write the code functionize I as creating and healing the tests, AI agents managing the infrastructure via.

IAC and all the data feeding back.

Every suggestion, every healed test, every drift correction, tagged and streamed into that unified analytics platform like opsrac iktives get real time visibility into velocity, quality.

Cost savings, and security gets pushed even further left.

Right to the keyboard. Essentially, issues blocked by copilot or caught by automated security in the pipeline ideally never even make it close to production. That's a massive security posture improvement outro.

What an incredible journey really from that fragmented, often frustrating world of traditional DevOps to this potential future driven by standardization, cloud, native thinking, and wow, generative AI creating real autonomy.

It really feels like we're on the cusp of transforming all that repetitive toil and software delivery into something much more intelligent, almost self managing.

Yeah. But the key takeaway, it seems, isn't that humans become obsolete?

Right, Not at all. The book really emphasizes this as AI takes on the drudgery the human role shifts. It elevates to what to higher level design, to strategy, to focusing on the next innovation, not just the current lights on. It's about freeing up human potential, and of course there's always more to learn as this tech.

Of all so fast, absolutely so for everyone listening, what does this all mean for your role? How can you start thinking about embedding AI, making it like muscle memory in your team or org.

How do you get from that burnout cycle to maybe build chip and wonder, wonder what's next exactly.

We really encourage you to explore these ideas, maybe pick up Vorl's book and just identify one or two places where AI could start elevating your daily work.

Start small, build momentum.

Yeah, well, thank you so much for joining us on this deep dive into the future of software development.

My pleasure.

We hope this exploration empowers you, gives you some ideas, and helps you pave your own road towards a more autonomous, efficient, and ultimately more innovative future.