Author: Alan Shimel

  • Why Agentic Coding Needs Governance at Scale

    Why Agentic Coding Needs Governance at Scale

    Most enterprises never fully finished the DevOps transformation they started a decade ago. Agentic coding is now surfacing every place that was left unfinished. Builds still take hours. Test suites are flaky. Releases are still gated by manual steps. An AI coding agent that has to sit idle for eight hours waiting on feedback is not just slow — it is an extremely expensive kind of slow, burning tokens and calendar time on the same pipeline gaps DevOps was supposed to close years ago.

    Moritz Plassnig, the newly returned CEO of CloudBees, joins Alan Shimel to explain what he saw during five years away at Immuta and why he came back. Watching large language models reshape how customers worked with data reignited his interest in the delivery side of the problem, and he argues agentic coding is DevOps’s second chance to actually deliver on the original promise. The gap is no longer that teams disagree that DevOps is real — it is that most companies never went all the way, and the shortcuts they took are now the ceiling on how fast agents can work.

    Plassnig’s recipe is direct. Take the rules an organization already lives by — two-human review on any code change, whatever the specific policies are — and encode them as versioned policy that a central governance engine can enforce across CloudBees, Jenkins, GitHub, GitLab or whatever coding tool a team picks. He shares a striking data point from a very large bank: technology planning horizons have compressed from five to ten years down to two to three, which means standardization is losing to a curated menu of approved tools that a governance layer holds together.

    If code generation is no longer the constraint, the next bottleneck is getting software into production safely — and Plassnig is blunt that AI-scale development needs AI-scale governance or the mismatch becomes catastrophic. Supply chain risk compounds with every automated step, and the organizations that pretend policy can stay manual are the ones that will discover the hard way that agents scale faster than any human review process ever could.

  • Mezmo Open Sources AI SRE Operations

    Mezmo Open Sources AI SRE Operations

    Site reliability engineering has been quietly buckling under its own success. The scope of what SRE teams are expected to own — observability, incident response, telemetry pipelines, capacity, cost, resilience — keeps growing while the tools underneath fragment further. AI is showing up as both the reason the workload keeps expanding and the most credible path to bringing it back under control, but only if agents get built on infrastructure that reliability engineers can actually reason about and trust.

    Tucker Callaway, CEO of Mezmo, sat down with Alan Shimel at PlatformCon 2026 to walk through how his team is trying to move that needle in public. Mezmo’s Aura project, released as an open source AI SRE harness, is meant to give teams an opinionated foundation for building agents that reduce toil, process telemetry and support reliability workflows without turning the ops function into a stack of proprietary black boxes. The bet is that reliability work is too high-stakes to be locked inside any single vendor’s agent runtime.

    Callaway and Shimel work through the practical pieces that decide whether an AI SRE agent is safe to run. Telemetry pipelines have to feed clean, structured signals rather than raw noise. Agent memory needs to persist and be inspectable so an agent’s prior actions can be audited. Trust and permissions become a first-class concern — an SRE agent with production access is only as good as the guardrails around what it can touch and when. Open source governance is what keeps all of that honest as more organizations adopt the harness.

    The bigger shift Callaway sketches is what happens to SREs themselves. Rather than shrinking the discipline, agentic operations pushes reliability engineers up a level — toward architecting how autonomous systems behave, defining the guardrails they operate inside, and owning the reliability contract for a stack that increasingly runs itself. Reliability architects for autonomous systems is the phrase that keeps coming up, and it looks like where the profession is heading.

  • Why Your Best People Can’t Save a Broken Delivery System

    Why Your Best People Can’t Save a Broken Delivery System

    When delivery falls apart, the reflex is to blame the team. Missed dates, quality slips, a burned-out squad — leadership tends to reach for a personnel fix and quietly move on. The uncomfortable pattern in most enterprise organizations is that the system itself is the failure mode. Decision latency, priority misalignment, and layers of governance that were designed for a slower era grind against the very people leaders keep asking to grind harder. Talented engineers cannot outrun a delivery pipeline that is structurally set up to stall.

    Marnus Marx, founder and Delivery Confidence Coach at Elanvia Consulting, joined Alan Shimel to unpack what that structural failure actually looks like from the inside. Marx came up through Unix and Linux systems before moving into DevOps and delivery coaching, which shapes how he diagnoses these breakdowns — as engineering problems in the socio-technical system, not character flaws in the humans stuck inside it. His frame of “delivery confidence” is a leadership discipline: the degree to which an organization can trust that what it promises externally will actually ship.

    Marx walks Shimel through the systemic issues that get mislabeled as execution failure. Decision latency is the biggest culprit — the days or weeks it takes to answer a simple question with real consequences, while everyone downstream burns cycles waiting or guessing. Priority misalignment is the second, where the work that gets pulled into a sprint has almost no relationship to the outcomes leadership actually cares about. Both wear down teams in ways that no amount of individual effort can compensate for.

    The bigger thread is how the shift to agentic AI is going to expose those cracks fast. Marx argues coaching has to run in two directions — pulling over-eager AI adopters back to the outcomes that actually matter, and pulling anxious resistors forward by redefining employee value around outcomes instead of tasks. The organizations that survive that transition will be the ones that stop protecting broken delivery systems and start rebuilding them around clarity, decision speed and alignment.

  • Platform Engineering vs. DevOps: Why This Is the Wrong Question

    Platform Engineering vs. DevOps: Why This Is the Wrong Question

    DevOps has done what it was supposed to do. It broke down the wall between development and operations, it made continuous delivery a normal expectation, it made shared ownership of production a cultural default, and it moved software delivery from a scheduled event to a continuous flow. The results reshaped how modern software gets built. They also created a new problem: at enterprise scale, every team ends up practicing DevOps a little differently, and the friction adds up.

    That is where platform engineering enters. It is often framed as the next movement replacing DevOps, but that framing misses what is actually happening. Platform engineering is the discipline of building an internal product — an internal developer platform — that gives every team a consistent, self-service path to production. Templates, golden paths, embedded security, provisioning, observability and compliance evidence stop being tribal knowledge and start being paved roads. Developers move faster because the platform absorbs the complexity. Security and operations get consistency because the platform enforces it by default.

    That is the argument at the heart of this paper: platform engineering is not a replacement for DevOps. It is how DevOps matures from a local practice into an enterprise delivery capability. The two disciplines are adjacent and complementary, and the organizations getting real leverage out of the last decade of DevOps investment are the ones giving it a product-grade platform to stand on.

    As internal developer platforms become the standard delivery layer inside enterprise engineering, the “versus” framing will fade. DevOps and platform engineering will simply be the two halves of how software gets delivered — the operating model and the product that scales it. That is why this moment matters for the platform engineering community. The next era of DevOps is not moving past it. It is being built on top of it.

    Download Whitepaper

    No registration required

  • AI Is Accelerating How Fast We Build the Wrong Thing

    AI Is Accelerating How Fast We Build the Wrong Thing

    AI coding assistants have made it trivially easy to ship software faster — and that is precisely the problem. Human developers used to absorb the gaps in a vague spec by asking questions, reading between the lines and quietly steering toward something useful. AI tools do not work that way. They take incomplete requirements at face value and build them literally, which means small ambiguities at the front of the process compound into expensive mistakes at the back. The result is shops moving at AI speed in directions they never meant to go.

    Jeff Keyes, Field CTO at Allstacks and a 30-year veteran of Microsoft, Atlassian and Planview, sat down with Alan Shimel to preview his Flowtopia 2026 talk on a new operating model for product management. His thesis is blunt: the smartest organizations he is working with have flipped the script and stopped treating AI transformation as an engineering problem. The real leverage sits upstream, in how product teams scope work and write requirements before a single line of code — human or machine — gets generated.

    Keyes and Shimel work through why more than 80% of companies still cannot point to meaningful ROI from their AI tooling investments. The pattern Keyes keeps seeing is faster output stacked on top of unclear intent, which produces velocity metrics that look impressive while value realization stalls. He argues requirements quality has quietly become the highest-leverage variable in AI-assisted development, and that PM craft — not prompt craft — is what separates the teams pulling ahead from the ones spinning.

    What that operating model actually looks like in practice is where the preview gets concrete. Keyes lays out how PM teams need to rebuild around clarity, traceability and feedback loops that hold up when an agent, not a junior dev, is doing the implementation. With AI accelerating both the right work and the wrong work in equal measure, the organizations that fix product management first will compound an advantage the rest of the field cannot catch.