DevOpsCon Amsterdam 2026: five themes that defined the week

We were at DevOpsCon Amsterdam 2026 last week and wanted to share what caught our attention.

A few years ago, a conference like this would have been dominated by observability deep-dives and language debates. This year, the bigger questions were about whether teams are building the right things, shipping them safely, and controlling what happens afterward.

AI is accelerating everything: code, the surface area for attacks, team dynamics, and model proliferation. The overwhelming conclusion was that our processes and controls haven’t quite caught up with what AI is making possible.

Here are five themes that we noticed.

1. AI adoption is a workflow design problem, not a speed problem

The most common narrative around AI in development goes something like: adopt tools, write code faster, ship more. Mads Thines Coello from dash0 dismantles that narrative in his talk, How to Use AI Without Burning Out.

As we know from DORA, the numbers tell a strange story. Over 90% of developers are using AI coding tools, but trust in AI output remains strikingly low. AI-generated code introduces more security vulnerabilities and significantly increases code duplication. The tools are everywhere, but our trust and confidence aren’t.

Mads argued that the gap comes from how teams adopt AI, not whether they do. Simply plugging AI into existing workflows yields limited benefits, maybe a 10–15% improvement. The teams seeing roughly three times the impact are redesigning their workflows around AI: planning before building, providing scoped rules and references to agents, defining repeatable skills, and building fast feedback loops with self-validation.

AI doesn’t fix a team, it amplifies what’s already there.

This maps closely to something we’ve seen with our own customers. The teams getting the most value from AI-assisted development aren’t just generating code faster. They’re wrapping that speed in runtime controls. We wrote about this recently in Designing for Failure: when code is written at AI speed, the goal shifts from pure correctness to reversibility. AI writes the code, but the rollout still follows a defined release template: internal users first, then 1%, then 10%, with automated safeguards watching production signals at every stage. When AI amplifies what’s already there, you want what’s already there to include progressive rollouts, kill switches, and automated rollback. Not just a CI/CD pipeline that ships whatever gets committed.

Mads’ cultural point landed hard, too. Psychological safety is the single biggest predictor of whether a team will adopt AI effectively. Teams where developers feel safe to experiment adopt AI tools naturally. Teams where people feel judged resist. Tooling doesn’t fix culture. But tooling designed to make experimentation safe: scoped rollouts, instant rollback, audit trails that answer “who changed what, when”. This lowers the stakes enough that experimentation becomes normal rather than scary.

2. The developer’s role is changing, and there are a million LLMs accelerating the shift

Over on the MLcon side of the event, John Davies from Incept5 opened The LLM Smörgåsbord with a number that’s hard to fully absorb: there are now over a million large language models available on Hugging Face alone. Add the public-facing models everyone knows: ChatGPT, Claude, Gemini, Grok, Mistral, Qwen, DeepSeek, plus the specialized coding tools like Devin, CoPilot, Cursor, Aider, Cline, and Replit, and the landscape is genuinely overwhelming.

His talk walked through the taxonomy: instruction-following models, tool-calling models, chat models, coding models, chain-of-thought and reasoning models, multi-modal models, text-to-speech and speech-to-text models. Code examples and live demos throughout. But the real provocation came in his framing of what this abundance means for the people building software.

It’s not AI that is replacing people. It’s people using AI who are replacing people who are not.

His argument wasn’t that programming is dead in some dramatic sense. It was more nuanced and, honestly, more unsettling. The developer’s role is shifting from author to orchestrator: guiding, supervising, and integrating AI-generated solutions rather than writing every function from scratch. The craft isn’t disappearing. It’s mutating.

More code, faster, from a million available models, written by developers whose role is shifting underneath them. If AI is generating code at a pace that humans can’t fully review, the safety net has to move downstream. Built into runtime, where you can control what that code does after it’s deployed, scope its exposure, and reverse it in seconds if something breaks. That’s not a theoretical argument. It’s the operational reality that every talk at this conference was circling.

3. Agentic AI needs enforced guardrails, not suggested ones

If theme two was about the proliferation of models, theme three was about what happens when you actually try to put them to work. Pieter van der Meer from dataworkz gave what might have been the most technically honest session of the week: Agentic AI: From the Trenches — What Most Talks Skip.

Yes, LLMs can reason, plan, and use tools autonomously. That’s the demo. The production reality is hallucinations, unreliability, and error handling. Peter argued that we need a crucial orchestration layer that makes the difference between an impressive prototype and a dependable system.

His focus was the Model Context Protocol (MCP) as that orchestration engine: a structured interface that standardizes communication between the LLM and tools, routes reasoning, triggers tool calls, handles errors, and enforces guardrails. The most important distinction he drew was between guardrails that are suggested (via prompt context) and guardrails that are enforced (in code, by the orchestration layer). In production, suggested guardrails fail. The LLM will eventually ignore them. Deterministic behavior requires explicit enforcement. The kind that prevents infinite loops, context explosion, and the silent failures that come from overtrusting the model.

His list of engineering trade-offs read like a design manifesto: autonomy versus control, reliability versus complexity, capability versus latency and cost, flexibility versus predictability, safety versus user experience.

This resonates deeply with how we think about AI-native workflows at Unleash. When an AI coding assistant generates a code change, the question isn’t just “is the code correct?” It’s “what happens when this code runs in production, and can we control it?” That’s why our MCP server integration exists, so AI tools don’t just write code but automatically evaluate whether a change needs a feature flag, create the flag with correct metadata, wrap the code in runtime controls, and clean up stale flags after rollout. The guardrails aren’t suggested to the AI via a prompt. They’re enforced by the platform through policy-driven automation.

This is something we’ve been thinking about beyond just code changes. When AI agents start calling tools autonomously: making API requests, triggering workflows, modifying data, the same principle applies. Prompt-based defenses against rogue agent behavior fail over 90% of the time against adaptive attacks. The security boundary has to sit on the execution layer, not the input layer. We wrote about this in Runtime Control for AI Agents, and Pieter’s talk reinforced the core argument: you need hard stops in the execution path, not polite suggestions in the system prompt.

Pieter’s talk was about building reliable orchestration layers for agentic AI. The same principle applies to the code that agentic AI produces: you need an orchestration layer between “AI wrote this” and “users see this.” That layer is runtime control.

Melinda Fekete made a related point in her talk about semantic failures in AI-assisted systems. The kind of failures where a request succeeds technically, but the behavior is wrong. A hallucinated tool call that returns 200 OK. A prompt injection that produces valid-looking but malicious actions. Your circuit breaker won’t trip. Your error rate won’t spike. But your users will notice. Those are exactly the scenarios where automated thresholds aren’t enough and where a feature flag system with human-operated runtime mechanisms matters more than ever.

4. The attack surface is growing faster than our defenses

Every theme so far has been about speed: faster code, more models, autonomous agents. Soroosh Khodami from Rabobank brought the necessary counterpoint in Are We Ready For The Next Cyber Security Crisis Like Log4Shell?

His talk started with a live demonstration of a supply chain attack. Starting from a simple SQL injection vulnerability, he showed how an attacker can escalate through lateral movement to eventually achieve root-level control over a Kubernetes cluster. Humble beginnings, catastrophic endings. It was a vivid illustration of why securing every layer matters, especially in complex cloud-native environments where one overlooked vulnerability can cascade into full compromise.

Soroosh argues that AI is a double-edged sword for security: it automates and enhances attacks just as readily as it accelerates development. More AI-generated code, shipped faster, with more dependencies pulled in automatically, means a proportionally larger attack surface.

His practical recommendations centered on two areas. First, securing CI/CD pipelines as a first-class concern. That means integrating security checks, automating vulnerability scanning, enforcing strict access controls, and ensuring build integrity. Second, adopting Software Bills of Materials (SBOMs) as standard practice. An SBOM is essentially an ingredient list for your software: when the next Log4Shell hits, knowing exactly what’s inside your dependencies is the difference between a rapid, targeted response and a panicked scramble.

This connects to an often-overlooked dimension of runtime control. When a critical vulnerability like Log4Shell drops, the question isn’t just “where is this dependency in our codebase?” It’s “can we disable the affected functionality right now, before a patch is ready?” That’s what kill switches are for. Not just for your own bugs, but for the moment when a shared dependency you rely on becomes the vulnerability. If the affected code path is wrapped in a kill switch, you can bypass it in seconds, buying time to patch without taking down the service.

Melinda’s talk walked through exactly this pattern using the Google Cloud outage as an example. Google’s own postmortem said the issue would have been caught in staging if the change had been wrapped in a feature flag. Cloudflare committed to enabling more global kill switches. GitHub’s immediate remediation after a caching failure that took down 40% of request handling was adding a kill switch to the caching mechanism. The engineering teams who literally wrote the books on reliability are arriving at the same conclusion: the missing layer was a runtime control that could disable a component without a redeploy.

If AI is generating more code faster, and that code pulls in more dependencies, and those dependencies are increasingly targeted by sophisticated attackers, then runtime control isn’t just a release management tool. It’s a security response mechanism. This is where FeatureOps practices come into the picture. The ability to surgically disable a code path without waiting for a deployment pipeline to complete is the difference between a five-minute mitigation and a five-hour outage. Of course, a kill switch isn’t a substitute for a security patch. But in the high-velocity world of 2026, it is the tool that buys your team the hours needed to ship a permanent fix without leaving the door wide open.

5. At the end of the day, it’s all about people

The first four themes were about technology: AI workflows, model proliferation, agentic orchestration, attack surfaces. Stephan Mousset from ING brought the conversation back to culture.

His talk, Building DevOps Culture: From Advocacy to Impact, traced a five-year journey from a grassroots group of 10 passionate engineers to a recognized reliability advocacy community influencing over 15,000 engineers at one of Europe’s largest banks. The community now runs an annual Reliability Event attended by more than 300 participants and supports onboarding new hires through dedicated reliability training. It started with people who cared, not with a mandate from leadership.

Mousset described building this movement in an environment that’s regulated, risk-averse, and historically resistant to change. The kind of environment where suggesting a new tool gets met with six months of security review and a compliance questionnaire. His approach was grounded in the CALMS principles: Culture, Automation, Lean, Measurement, and Sharing. The through-line is simpler than any framework: success isn’t just about writing great code. It’s about building resilient, collaborative systems where people and technology thrive together.

That message echoed what Mads Coello had argued from a completely different angle. Culture and process quality have a greater impact on outcomes than tooling. You can adopt the best AI tools, the most sophisticated CI/CD pipelines, the most elegant infrastructure. If the underlying culture doesn’t support trust, autonomy, and shared responsibility, the technology won’t save you.

This is something we think about a lot at Unleash. We build a runtime control platform, and we’ve been doing it for years, but the best deployments we see aren’t the ones with the most flags or the fanciest automation. They’re the ones where teams trust the system enough to use it under pressure. Where an on-call engineer at 2 am reaches for the kill switch instead of trying to remember which repo owns which config map. Where a junior developer feels safe shipping a feature behind a flag because they know it can be rolled back in seconds without blame.

The technical capabilities matter: progressive rollouts, automated safeguards, audit trails, self-regulating rollouts. But those capabilities only deliver value when the culture supports using them. When experimentation is safe; when rollback isn’t failure, it’s discipline; when the question after an incident isn’t “who broke it?” but “what control were we missing?”

Every talk at DevOpsCon Amsterdam was, in its own way, a talk about people. Mads Coello talked about psychological safety. John Davies talked about professional identity. Pieter van der Meer talked about the engineering judgment that no orchestration layer can automate. Soroosh Khodami talked about the human decisions that determine whether an attack succeeds or gets contained. And Melinda talked about giving engineers the controls they need to make good decisions under pressure.

If you’d like to watch any of the full-length talks, they’re available in the devmio app along with an endless library of past conference talk recordings.

Ultimately, DevOpsCon 2026 proved that while the models are getting smarter, the responsibility stays with us. The future of the industry is about building the human trust and technical guardrails necessary to handle that speed safely. If you want to see what those guardrails look like in practice, try Unleash for free.

FAQs

What were the main themes at DevOpsCon Amsterdam 2026?

The five dominant themes were: AI adoption as a workflow design challenge rather than a speed race, the shifting role of the developer in an era of over a million available LLMs, the engineering discipline required to build production-grade agentic AI, the expanding attack surface that comes with AI-accelerated development, and the foundational role of culture and people in making any of this work.

How does AI adoption affect delivery stability according to DORA research?

DORA research shows that a 25% increase in AI adoption correlates with improvements at the individual level: 7.5% better documentation, 3.4% better code quality, and 3.1% faster code reviews. However, that same increase correlates with a 7.2% drop in delivery stability at the organizational level, because developers pack more changes into each release, increasing complexity and the surface area for failures.

What is the difference between DevOps and FeatureOps?

DevOps is the discipline of getting code to production reliably: CI/CD, infrastructure as code, automated testing, and observability. FeatureOps extends those same principles beyond the CI/CD pipeline into runtime, adding control over what deployed code actually does once it’s running. Where DevOps manages deployments, FeatureOps manages behavior: who sees what, when, and under what conditions, with the ability to change, scope, and roll back in seconds without redeploying.