If you’re plugged into the pulse of developer innovation — and if you’re reading devopsy.kinsta.cloud, I know you are — you’ve probably seen “vibe coding” floating to the top of the AI conversation. Sure, the term might raise eyebrows. But beneath the nomenclature is something real, something with the potential to change how professional developer teams and CI/CD pipelines operate at scale.
Let’s break down what vibe coding is, why it’s more than just another buzzword, and — most importantly — how it’s going to shake up the daily lives of modern DevOps teams.
Vibe coding is AI-powered, collaborative code creation, where the “vibe” — the team’s culture, coding style and collaborative preferences — is harnessed as an operational parameter. Imagine pairing human strengths with advanced generative AI, capturing not just code syntax and logic, but the subtle preferences, patterns and conventions that make YOUR team effective.
This isn’t about getting AI to write a few snippets. It’s about the AI learning your team’s DNA. The “vibe” is baked in from the get-go—think TDD, security policies, code linting standards, or even the wry humor in your commit messages. The result? Cleaner code, fewer handoffs lost in translation, and a faster path from ideation to deployment.
DevOps is about more than pipelines — it’s about bringing people, processes *and* technology into alignment. That’s where vibe coding comes in:
–Deep Team Alignment: Vibe coding ensures AI suggestions reflect your team’s unique culture, not a generic “best practice.” New team members or contractors? The onboarding curve just got easier.
–Streamlined CI/CD: Vibe coding-enabled tools can integrate directly with your CI/CD workflows. They “know” your pipeline’s quirks and policies, flagging likely issues and optimizing for what really matters to your team—speed, security, reliability.
–AI as a Team Player: Rather than a passive copilot, the AI actively recommends refactors, testing strategies, or deployment tactics that fit your team’s established rhythm.
–Enterprises Get “Vibable” Products: As these tools and approaches mature, expect to see “Vibable” as a quality mark—meaning platforms and tools designed specifically to blend with your team’s vibe, priorities, and infrastructure.
The potential of vibe coding isn’t just theoretical. The analysts at Futurum Research have weighed in on this trend, highlighting that the “next generation of AI-assisted coding won’t simply accelerate code production — it will fundamentally change how professional development teams operate and interact.” According to The Futurum Group, organizations adopting vibe coding can expect “reduced onboarding time, faster implementation of best practices, and more resilient, consistent code delivery across teams.”
The Futurum Group’s research aligns with what we’re seeing at the practitioner level: The more your AI tools can reflect your team’s true working style, the more valuable — and trusted — they become. For CI/CD teams, this means fewer interruptions, smoother rollouts, and a more predictable dev-to-deploy cycle.
Vibe coding isn’t just about feel-good collaboration. It’s about real business impact—accelerating feature delivery, reducing technical debt, and lowering time to value. As the DevOps landscape evolves, expect the “vibe” to become as important as the code itself.
The bottom line: If you want your CI/CD and DevOps teams to stay competitive — and maybe even have some fun along the way — it’s time to tune in to the vibe.
For further reading and a deeper dive into enterprise impacts, check out The Futurum Group’s analysis on AI and the evolution of vibe coding.
Kumar Chivukula, co-founder and CEO of Codeglide.ai (a subsidiary of Upsera), explains why the rise of the Model Context Protocol (MCP) is reshaping how enterprises connect APIs to large language models. For years, APIs have served as the backbone of data access, but they were never designed with AI in mind. They lack memory, context, and intent awareness—forcing developers to bolt on brittle glue code every time models change.
Anthropic’s introduction of MCP earlier this year marked a turning point, offering a standardized way to make APIs context-aware and AI-ready. But as Chivukula points out, adopting MCP isn’t just about creating a one-off server. Enterprises run tens of thousands of APIs—many undocumented, outdated, or internally facing—and keeping pace with rapid model changes demands a lifecycle approach. That’s where CodeGlide positions itself: a continuous MCP server platform that automates creation, updates and security scanning at scale.
The comparison to cloud migration is apt. Just as lift-and-shift approaches left organizations with bloated costs, treating MCP as a quick wrapper on existing APIs won’t cut it. Instead, enterprises need a sustainable framework that refactors APIs for AI interaction, enforces security, and manages change continuously. Chivukula highlights integration with GitHub’s vast ecosystem—home to tens of millions of API repositories—as a critical lever to reach both developers and enterprises.
With more than a billion APIs in existence and an emerging AI economy valued in the tens of billions, MCP adoption isn’t optional—it’s inevitable. The question is how organizations will navigate the transition without drowning in complexity. Platforms like CodeGlide hint at one possible path forward.
The resilience of DevOps platforms is being tested like never before. According to GitProtect.io’s just-released DevOps Threats Unwrapped: Mid-Year Report 2025, disruptions across the leading DevOps tools — GitHub, GitLab, Bitbucket, Jira and Azure DevOps — have grown not only in volume but in severity. The findings paint a stark picture: 330 incidents in the first half of 2025 alone, impacting developer velocity, business continuity, and cloud-native operations across the globe.
If there was any doubt about the fragility of the DevOps ecosystem’s backbone, this report lays it to rest. GitHub, the most widely used source code repository in the world, saw a 58% year-over-year increase in incidents. Azure DevOps suffered a 159-hour performance degradation in a single event. Jira, widely used for project and issue tracking, endured more than 2,390 hours of cumulative downtime—nearly 100 full days of disruption.
It’s clear: In 2025, the platforms we rely on to build software are showing signs of strain.
Azure DevOps topped the list in terms of the number of unique incidents, with 74 recorded from January through June. Some of these hit multiple components simultaneously, but one part of the platform stood out as the most unreliable: Pipelines, with 31 individual service disruptions — 21% of Azure’s total issues.
Other areas affected include:
The most severe event was a 159-hour global degradation that unfolded in January, significantly slowing down build and deployment processes for nearly a full week. Geographically, Europe absorbed the brunt of the fallout, accounting for 34% of incidents, while India and Australia saw fewer issues — just 4%.
GitHub’s status as the world’s go-to platform for open source and enterprise repositories makes its instability particularly alarming. In the first half of 2025, the platform logged 109 incidents, a 58% jump from H1 2024’s total of 69.
Breakdown of GitHub’s disruptions:
This is more than just an operations problem — it’s a developer experience issue that could impact everything from commit velocity to CI/CD reliability.
Though GitLab disclosed slightly fewer vulnerabilities than H1 2024 (65 vs. 70), it suffered 59 incidents totaling approximately 1,346 hours of service degradation.
Types of issues:
One particularly alarming incident wasn’t about downtime — but data loss. Attackers breached GitLab repositories belonging to Europcar Mobility Group, stealing Android and iOS source code along with personal information of up to 200,000 customers. It’s a reminder that in today’s threat landscape, service uptime and cybersecurity are inextricably linked.
Atlassian’s Jira suite faced 66 incidents in H1 2025 — a 24% increase over the same period last year. Combined, these incidents resulted in over 2,390 hours of disruption, equivalent to nearly 100 full days. The prolonged impact stemmed in part from an extended maintenance window that affected free-tier users in Singapore and Northern California, with some customers experiencing outages of up to 120 minutes each.
Breakdown of incidents by product:
Beyond technical failures, cyberattacks added a new dimension to Jira’s woes. The HellCat ransomware group leveraged stolen credentials to breach Jira instances at major companies, including:
These attacks weren’t just disruptive — they were damaging. They reveal how closely operational resilience and cybersecurity are converging in the DevOps age.
“We are witnessing a clear upward trend in outages and disruptions across DevOps platforms, but also in the frequency and sophistication of ransomware attacks and source code thefts, demonstrating that traditional perimeter security is no longer sufficient,” said Greg Bak, Head of Product Enablement at GitProtect.io.
“Anticipating failures before they happen, paired with self-healing infrastructure and recovery strategies that go beyond just technology, will redefine how organizations safeguard uptime, data integrity and business continuity,” Bak continued.
In short, the DevOps stack isn’t just suffering growing pains — it’s facing an evolution in risk profile. As CI/CD pipelines become attack surfaces, and developer tools become threat vectors, the idea of resilience must expand from “uptime” to include backup, observability and fast recovery.
For more granular data and methodology details, visit the full report here.
Over the last 14-plus years of my journey through DevOps, I’ve had the good fortune to meet some of the smartest, most generous, most forward-thinking people in our industry. It’s one of the things I’m most thankful for—the friendships and shared learning that come from being part of a community that is always pushing boundaries. And of all the brilliant people I’ve met, none has been more influential, inspiring, or personally meaningful to me than my friend John Willis.
My only regret is that I didn’t get the chance to meet John 30 or 35 years ago. Oh the things we would have explored. For those who’ve been around DevOps for a while, John needs no introduction. For those newer to the space, John is truly one of the OGs of the DevOps movement. He has co-authored multiple books on DevOps, spoken at countless DevOpsDays and other events worldwide, and served as one of the great ambassadors of this movement. His boundless curiosity and relentless pursuit of knowledge have taken him far beyond the world of DevOps into areas like artificial intelligence and even quantum computing. And yet, for me, John remains one of the truest reflections of what’s good about the DevOps community.
John recently published a flagship post on LinkedIn titled Security Is Behavior: DASP and DevOps. In it, he once again reminds us what lies at the heart of DevOps—and what too many have forgotten.
For far too many people, DevOps has become synonymous with CI/CD pipelines, automation, and speed. Don’t get me wrong—those things are important. But they are not the essence of DevOps. As John points out, the core of DevOps was never just tools or speed; it was about people, about culture, about how we work together. That’s a message we need to keep repeating, because it’s all too easy to lose sight of it in the rush of new tools and trends.
For me, reading John’s post took me back to one of the foundational ideas he helped introduce to our community years ago: CAMS. Alongside Damon Edwards, John gave us a simple but powerful framework that distilled the essence of DevOps into four letters: Culture, Automation, Measurement, Sharing.
CAMS was never meant to be a rigid doctrine; it was a compass. And just like then, it remains a compass today, pointing us toward what matters most when the allure of shiny new tools threatens to distract us.
John’s post is also a timely reminder that security cannot be bolted on as an afterthought. Developers, operators, and security professionals must all share responsibility. DevSecOps will never succeed unless developers feel true ownership for security, not just compliance.
John put it perfectly in his post:
“Security is not a tooling problem or a compliance checklist. It is a people problem, and solving it requires behavior change, cultural alignment, and leadership that actually cares.”
No words were ever truer. This isn’t just advice for practitioners—it’s a call to action for every person in the DevOps ecosystem. Every vendor, every security team, every developer should read that quote, internalize it, and then read it again. We talk endlessly about “shifting left,” but unless we are shifting culture and behavior left, we are just paying lip service.
Another important thread in John’s post is his emphasis on DASP—DevSecOps Automated Security Patterns. At its core, DASP is about codifying the recurring security challenges we face and creating reusable, automated patterns for solving them. It’s not about reinventing the wheel every time; it’s about learning from experience and embedding those lessons into the way we work.
What I find so valuable about John’s perspective here is that he doesn’t present DASP as something outside DevOps or bolted on top of it. Instead, he frames it as a reminder of what DevOps always was: people, behavior, culture, and shared responsibility. Tools may change, but those principles don’t.
By linking DASP back to the cultural heart of DevOps, John shows us that security can and must be part of the fabric of how we build software—not a separate layer applied afterward.
Over the years, movements evolve. Words get watered down. What started as a revolution can risk becoming a buzzword. DevOps has not been immune to that. But leaders like John Willis keep us grounded. They remind us where we came from, what the movement was really about, and why it still matters.
That’s why I call John Willis the True North of DevOps and DevSecOps. He’s the compass who brings us back when we risk drifting off course. He’s the voice reminding us that for all our pipelines, our YAML files, our AI copilots and quantum explorations, at the end of the day, DevOps is—and always will be—about people.
As John himself concludes:
“DevOps was always about: people, behavior, culture, and shared responsibility.”
I can’t think of a better way to end this piece than to echo those words. For me, for devopsy.kinsta.cloud, and for our entire community, John Willis is proof that those truths endure.
When I first read the recent article from CISA titled “Tackling the National Gap in Software Understanding,” I had the same reaction I imagine many of you did: Well, of course this is necessary. Who in their right mind doesn’t want better visibility into the software used in our most mission-critical systems?
But then I thought a bit more. It’s not just necessary—it’s overdue. And not only for national security systems. This gap in software understanding exists across nearly every enterprise and agency in the public and private sector. The real challenge is not recognizing the problem. It’s addressing it early, systemically and sustainably—especially in a DevSecOps context.
Let’s dig into what this really means, why it matters, and where we go from here.
The CISA article—and the reports it references from MITRE, NSA, ONCD, and others—highlights a fundamental issue: We don’t know enough about the software running inside our critical infrastructure. We lack the ability to fully understand what’s in our software, how it’s built, and where the risks lie.
This isn’t a new problem. But with the rise of supply chain attacks, component vulnerabilities and ever-expanding software dependencies, the risk is no longer theoretical. It’s existential.
Here’s the kicker: You can’t secure what you don’t understand. You can’t defend what you can’t see.
So yes, we need to close the gap in software understanding—urgently. But the gap isn’t just about national security. It’s a DevSecOps problem at its core.
The big idea in DevSecOps has always been this: shift security left, embed it early and often, and make it everyone’s responsibility.
This makes DevSecOps the perfect context for addressing the software understanding gap. Why? Because the best time to capture visibility into your software’s inner workings isn’t after it’s shipped—it’s while it’s being built.
Software Bill of Materials (SBOMs) are getting a lot of attention—and rightly so. They provide a machine-readable inventory of every component in a piece of software, down to the library level. SBOMs are a baseline requirement for software visibility, but they’re not the whole story.
What we need is end-to-end traceability—from code to artifact to runtime. That includes:
This kind of visibility is what lets you “understand” software in the true sense—not just scan it for CVEs.
And the only way to build this visibility in without slowing everything down is to integrate it directly into DevSecOps workflows.
I’ll give credit where credit is due: CISA and its federal partners are thinking bigger. They’re not trying to do this in a silo. They’re bringing in multiple agencies—ONCD, NSA, and others—and they’re inviting the cybersecurity and open source communities to the table.
That’s a smart move. Because this isn’t a compliance exercise. It’s a transformation effort.
Too often, the conversation around software security gets stuck on source code access. But as anyone in DevSecOps knows, access to source code alone doesn’t solve the visibility problem. You need insight into artifacts, pipelines, environment variables, configurations, and more. We’re talking about a whole-of-lifecycle approach—not a repo review.
The fact that this is now a coordinated, multi-agency initiative is encouraging. If done right, it could set the standard not only for how the federal government secures software, but how the private sector does too.
And yet… I’ve been around long enough to know how these things go. Big announcement, slick webpage, maybe even a press conference. And then?
Crickets.
We’ve seen this script before. Promising initiatives that fizzle out after leadership changes, priorities shift, or budgets get squeezed. Federal agencies—CISA included—have a revolving door problem. Continuity is hard when your champions keep leaving. You need people who aren’t afraid to speak the truth and do what is right.
So here’s the real question: Will we stick with it? Will the teams behind this initiative have the mandate—and the stamina—to drive this effort forward once the spotlight dims?
Because make no mistake: closing the software understanding gap is not a one-and-done project. It’s a multi-year slog. It requires rewriting procurement policies, updating build systems, retraining teams, and investing in open standards. It’s not glamorous, but it’s vital.
If we do see it through, this won’t just be a win for federal cybersecurity. It’ll be a win for the DevSecOps movement.
It will reinforce the idea that visibility, traceability, and accountability are not add-ons—they’re first principles. It will accelerate the adoption of SBOMs, secure build pipelines, artifact attestation, and zero trust architectures.
Most importantly, it will help us build software we can trust. And in today’s world, that’s not just a technical achievement. It’s a national imperative.
Let’s hope we have the will to match the ambition.
Last week, I told you it was coming. Today, I’m thrilled to say it’s here: Futurum Signal is live. And while “live” is one of the most overused words in tech, in this case it’s the real deal. Futurum Signal isn’t just another PDF report dressed up with a quadrant. It’s a continuously updated, AI-powered market intelligence platform designed to give DevOps and platform engineering leaders something we’ve all been chasing: clarity in the chaos.
Across the Techstrong network, the initial announcement lit up the communities. On devopsy.kinsta.cloud, readers immediately connected the dots to the endless tooling debates—CI/CD, observability, security, platform engineering, you name it. Futurum Signal offers something different: a way to see, in real time, how the market is actually performing instead of how vendors want you to think it’s performing.
So how does Futurum Signal look at the market? Think of it as a living dashboard that goes far beyond the old static quadrant model.
Take the Radar View. It maps vendors across five dimensions that really matter to practitioners and decision makers:
Instead of lumping everyone into one square, the radar places vendors into zones—Aspiring, Established, Leader, or Elite. That means you can instantly see the nuance: maybe a vendor has great innovation but lags in execution, or strong ecosystem alignment but a weaker vision. Futurum Signal surfaces that reality in a way a one-dimensional chart never could.
Then there’s the Vendor Comparison Zone. Picture concentric rings showing who’s breaking into the Elite zone, who’s holding steady as a Leader, and who’s still climbing from Established to Aspiring. For a DevOps leader sorting through dozens of vendor pitches, it’s a quick sanity check.
Finally, the Heat Map View provides a fingerprint for each vendor. Side-by-side boxes make it obvious who’s consistently strong across all five metrics and who is patchy—maybe great at innovation but weak on go-to-market, or strong in ecosystem but lagging in business value. For DevOps teams that have to place bets on vendors, this level of visibility is invaluable.
And that’s just what’s public-facing. The Futurum Signal platform also offers deep dives, drill-down dashboards, and customer sentiment overlays from millions of G2 reviews—giving practitioners the ability to see where the market is actually moving, not just where the marketing dollars are flowing.
With today’s launch, Futurum Signal’s first solution area—Data Intelligence Platforms—goes live. That’s not accidental. Data is the backbone of DevOps and platform engineering. It powers observability, AI, decision automation, and ultimately, velocity.
Over the coming weeks, Futurum Signal will expand into additional solution areas: Security Operations Platforms, Software Engineering Platforms, Agentic AI Platforms, AI Cloud Platforms, Sales/Service/Marketing Platforms, and Cloud Marketplace Platforms. Yes, the roadmap will evolve—but the direction is clear. Futurum Signal isn’t a one-off report; it’s a system that adapts as fast as the technology it tracks.
Since announcing Futurum Signal last week, I’ve had conversations with vendors and practitioners alike. The feedback has been positive, but naturally, some common questions keep coming up.
Q1: How do you collect the data?
Futurum Signal stands on a three-legged stool. First, our exclusive partnership with G2, which brings unmatched scale—millions of real-world user reviews, not just a few hundred survey responses. Second, agentic AI, which continuously ingests and verifies public data sources. Third, Futurum’s own analyst team, layering on human expertise, validation, and context. Together, this creates a sturdier foundation than any single source could provide.
Q2: How do people access the data?
There are multiple entry points. Subscribers get continuous access to the solution areas they care about. Vendors will license Futurum Signal data for their own internal and external use. And for the broader market, Futurum will publish snapshots and executive summaries—not real-time, but enough to give you directional insights.
Q3: Can vendors influence the findings?
Here’s the bad news for some—you can’t. Futurum Signal isn’t your grandfather’s analyst report where a steak dinner and a sponsorship might magically improve your placement. The data is the data. You can brief the analysts, but you can’t game millions of G2 reviews or AI-verified public data. If you want to move up, you have to actually perform in the market.
For years, DevOps practitioners have complained about the “vendor noise” drowning out real-world performance. Too many tools, too many claims, too much marketing spin. Futurum Signal cuts through that by letting the data—and the practitioners who actually use these tools—speak for themselves.
Is Futurum Signal perfect? No, and it won’t be. It will evolve as AI evolves, as markets shift, and as new solution areas open up. But it’s a step toward something the DevOps community has desperately needed: a continuously refreshed, transparent, and data-driven view of the tooling landscape.
At some point, you have to stop tinkering and let your creation fly. For Futurum Signal, that moment is today. And for DevOps, it couldn’t come soon enough.
Everywhere you turn these days, AI is reshaping how we build and deliver software. From GitHub Copilot writing code to autonomous testing frameworks finding bugs before developers even blink, the promise of faster, smarter, more efficient pipelines is undeniable. And now we’re entering the next frontier: Agentic AI — self-directed agents capable of not only generating code but also testing, deploying and monitoring it.
In other words, the machines aren’t just helping us anymore. They’re starting to run the show.
It’s a thrilling vision — software development at machine speed. But here’s the problem: Taking humans completely out of the loop in DevOps is not only reckless, it’s dangerous.
Let’s be clear: The allure is real. Agentic AI promises to do in minutes what used to take teams days or weeks. Imagine an AI agent that identifies a bug, writes the fix, tests it, pushes it to production and even monitors post-deployment health — all without human hands on the keyboard.
For enterprises under constant pressure to ship faster and cheaper, that’s intoxicating. Velocity becomes exponential. Releases are constant. The delivery pipeline hums along like an autonomous factory floor.
But there’s a catch.
Handing over the keys to the pipeline without human oversight is like letting a self-driving car speed down the highway with no steering wheel. Sure, it might make the ride smoother — until it doesn’t.
We’ve already seen what happens when automation goes wrong: Outages, cascading errors and misconfigurations that ripple across global systems. Now imagine those mistakes moving at machine speed.
Some risks we simply cannot ignore:
In short: Speed without oversight is a recipe for disaster.
Here’s the truth: the future of DevOps isn’t about replacing humans. It’s about redefining their role.
AI is fantastic at pattern recognition, execution and optimization. But humans still bring context, judgment and accountability. And in DevOps, that matters. A lot.
There are critical points in the pipeline where human oversight is non-negotiable:
We don’t need to slow down. We need to be smart about where humans fit into the system.
Think of it this way: there are three models for human-AI collaboration in DevOps.
The art is in deciding which model applies to which stage. Maybe AI can handle low-risk tasks like generating unit tests. But when it comes to production deployments? You want a human on the loop — if not directly in it.
If we want AI and agentic AI to fulfill their promise without introducing chaos, we need guardrails:
The companies that figure this out will have a huge advantage — faster pipelines, safer releases and the trust of both regulators and customers.
Agentic AI is coming to DevOps, and it’s coming fast. It will build, test, deploy, and monitor software with a speed and efficiency humans can’t match. But if we chase velocity at the expense of oversight, we risk losing the trust, safety and accountability that DevOps has fought so hard to earn.
Humans don’t need to run every step of the pipeline anymore — but they still need to steer it.
Because at the end of the day, no matter how “intelligent” our tools become, the responsibility for what ships — and the consequences it brings — will always rest with us.