devopsy.kinsta.cloud

Category: Video Interviews

  • AI Coding Agents Are Pulling CI Feedback Into the Inner Loop

    AI Coding Agents Are Pulling CI Feedback Into the Inner Loop

    The traditional shape of CI/CD assumed humans worked in the inner loop and pipelines policed the outer one. AI coding agents are tearing that geometry apart. When code can be generated in seconds, waiting until a pull request to run validation, tests, code review and standards checks turns the outer loop into a backlog of preventable rework. The pipeline itself becomes the bottleneck — and the bottleneck shows up not just as time lost but as wasted tokens, half-finished features and engineering controls that fall behind the rate of change.

    Rob Zuber, CTO of CircleCI, joined Mike Vizard to lay out how that pressure is reshaping CI/CD platform design. Zuber’s read is that CI quality work has to live where the work is actually happening — inside the developer and agent loop — so issues are surfaced and corrected before changes ever leave a working branch. That means pushing validation, testing, agentic review and deterministic guardrails right up against the moment code is generated, rather than catching problems hours or days later in a pipeline run.

    Zuber and Vizard dig into what shifting that feedback earlier actually requires under the hood. Agentic review needs deterministic checks it can trust, observability has to extend to agent behavior, and feature flags become a far more central tool when changes are landing at machine speed. DORA metrics still matter, but Zuber argues the leaders are layering token consumption and pipeline efficiency on top to see whether AI is actually compounding throughput or just compounding cost.

    The bigger shift is one of control surface. As AI amplifies how much software an organization can produce, the engineering controls around quality, security and release safety have to amplify in lockstep — or the gains evaporate.

  • 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.

  • CDEvents Simplifies AI-Ready Developer Platforms

    CDEvents Simplifies AI-Ready Developer Platforms

    Internal developer platforms have become a tangled web of orchestration tools, CI runners and deployment systems that rarely speak the same language. Every new integration adds another translation layer, and as AI-driven automation starts to plug into those pipelines, the lack of a shared vocabulary for what is actually happening across the software delivery lifecycle becomes a real bottleneck. Without a consistent way to describe build, test and deploy events, both humans and agents are left stitching together logs and webhooks from systems that were never designed to interoperate.

    Dadisi Sanyika of the Continuous Delivery Foundation sat down with Mike Vizard to walk through how CDEvents is tackling that fragmentation. CDEvents defines a common event specification — essentially a standardized set of receipts that tools like Jenkins, Tekton and other delivery systems can emit as work moves through the pipeline. That shared semantic layer gives platform teams a reliable way to wire heterogeneous tooling together without writing custom adapters for every combination.

    Sanyika digs into Conduit, a project aimed at reducing the integration burden that platform engineers carry when assembling internal developer platforms. Rather than forcing teams to bolt together pipelines, observability and policy tools piece by piece, Conduit leans on CDEvents to provide the connective tissue. He also lays out how natural language interfaces, semantic orchestration and open source interoperability come together to make those platforms more accessible — and more amenable to AI agents that can reason about what is moving through the pipeline.

    The bigger payoff is what becomes possible once delivery events are standardized. AI-enabled DevOps platforms can finally act on trustworthy, structured signals rather than improvised log scraping, which opens the door to smarter automation, better feedback loops and developer platforms that adapt instead of calcify. Standards work like this rarely makes headlines, but it is the kind of plumbing that determines whether the next wave of AI tooling in software delivery actually lands.

  • Why the Trust Layer Is the Next Thing Developers Will Commodify

    Why the Trust Layer Is the Next Thing Developers Will Commodify

    Engineering roadmaps inside enterprises that never planned to build AI products are now being eaten by AI work. Teams at hospitals, banks and government agencies are spending huge chunks of their sprint capacity wiring up models, UI components and accessibility plumbing for AI features that aren’t core to what their business actually does. The mismatch between where the work is going and where the value is created is starting to force a different conversation about what belongs in-house and what doesn’t.

    Mike Hideo, VP of Software Engineering at TinyMCE, joins Mike Vizard to argue that the next layer developers will commodify is the AI trust layer — the governance, control, provenance and UI components that wrap every LLM-driven feature. The case is straightforward: writing a prompt is cheap, but building reliable audit trails, permission models and accessible interfaces around AI output is the part teams keep rebuilding from scratch with every new model release.

    The conversation gets into the deeper structural shift underneath that. Agentic workflows don’t fit cleanly into the traditional SDLC — Hideo’s line is that “sprints are dead,” at least in their current form, because the unit of work is moving from “story” to “capability an agent can use safely.” Architectural review of AI-generated code, real budgeting around token spend, and risk dashboards that track AI usage the same way they track operational and security risk all start mattering more than ceremony around two-week increments.

    The regulatory layer is closing fast. Article 50 of the EU AI Act and emerging U.S. frameworks are about to make provenance and audit trails a hard requirement for any AI-touched workflow, not a nice-to-have. Hideo’s view is that the teams getting ahead are the ones designing their stack so the trust layer can be swapped in, governed centrally and updated independently of whichever foundation model happens to be in fashion that quarter.

  • OpenTelemetry Graduation Sets Stage for AI Observability

    OpenTelemetry Graduation Sets Stage for AI Observability

    OpenTelemetry just hit graduated status at the CNCF, and the timing matters more than the milestone itself. After years of consolidating what used to be OpenTracing and OpenCensus, the project has quietly become the default way modern applications emit traces, metrics and logs — right as the industry is staring down a new wave of workloads that will generate more telemetry than anything that came before.

    Mike Vizard sits down with Chris Aniszczyk of the CNCF to dig into why graduation is less of a finish line and more of a starting point. Aniszczyk’s argument is that OTel’s real value isn’t in any single feature — it’s in being the vendor-neutral plumbing that finally lets organizations modernize legacy monitoring stacks without locking themselves into the next generation of proprietary agents.

    They get into the practical mechanics of running OTel at scale: managing the firehose of telemetry data, the trade-offs around sampling and cost control, and how teams are using the spec’s extensibility to instrument environments that were never designed to be observable in the first place. The discussion also touches on how OTel’s collector model gives platform teams a single chokepoint to enforce schema standards, reduce duplicate tooling and route signals to wherever they’re most useful.

    The bigger thread is what observability looks like once AI agents become first-class citizens in production. Tracing an autonomous workflow means following decisions across model calls, tool invocations and downstream services — with token usage, prompt context and intermediate reasoning all worth capturing. Aniszczyk makes the case that open standards are the only realistic foundation for that kind of traceability, and that the work happening inside OTel right now is what will determine whether agentic workloads stay debuggable as they scale.

  • Software Weaponization Raises DevSecOps Stakes

    Software Weaponization Raises DevSecOps Stakes

    The threat model that DevSecOps teams have been working from for the last decade was built around accidental vulnerabilities — mistakes that needed to be found and fixed before someone exploited them. That assumption is breaking. Vulnerabilities are increasingly being treated as strategic assets, stockpiled by nation-states and threat actors and held back from disclosure until they’re useful as weapons. That shift changes what “good enough” security looks like across the software delivery lifecycle.

    Mike Vizard sits down with Kate Scarcella and Tracy Ragan to dig into what software weaponization actually means in practice for engineering and security teams. Their argument is that the industry has spent years investing in pre-deployment scanning and not nearly enough in knowing what’s actually running in production. The result is sprawling estates of deployed software where teams can’t answer the basic question of which versions, in which configurations, are exposed to a newly disclosed, or quietly hoarded, vulnerability.

    They also get into the mechanics of closing that gap. Stronger SBOM practices are the foundation, but only if SBOMs are continuously updated, queryable and tied to the running environment, not parked in a build artifact. From there the conversation moves into automation: using AI-assisted tooling to identify exposed assets fast, prioritize remediation against real exploitability, and push fixes downstream without manual triage at every step.

    The other thread is organizational. AI is now both a tool defenders rely on and a source of new risk — data poisoning, model misuse, autonomous agents acting on stale context. Scarcella and Ragan make the case that this is the moment to break down the wall between developers, security teams and data scientists, with shared visibility, shared accountability and a runtime view of the entire software estate as the connective tissue.

  • The Messy Reality of Vibe Coding

    The Messy Reality of Vibe Coding

    The default reaction to vibe coding has been alarm — a default assumption that letting AI write large chunks of an application is going to flood production with vulnerabilities and undocumented behavior. That fear is doing as much damage as the bad code people are afraid of. Teams that freeze, ban the tools or push the work into the shadows end up with less visibility into how AI is actually showing up in their codebase, not more.

    Tyler Merritt, CTO at UneeQ, joins Mike Vizard to push back on the panic and reframe the problem. Merritt’s argument is that AI-assisted development is a construction site, not a finished building — and construction sites are inherently messy. The job for engineering leaders isn’t to keep the site spotless, it’s to make sure the right safety systems, inspections and review steps are wrapped around the work that’s happening anyway.

    They get into the practical mechanics of doing that. Instead of trusting any single model, Merritt makes the case for using multiple AI assistants — Claude, Gemini and others — as a kind of cross-check, where one model reviews what another produced and pulls weaknesses to the surface before they hit a pull request. Pair that with the existing toolchain (SAST, dependency scanning, code review, tests) and the AI output starts to look more like any other developer’s output: imperfect, but reviewable.

    The longer-term view is more optimistic than the headlines suggest. Merritt points out that no developer wakes up wanting to ship insecure code, and as these assistants get better at understanding context, security and intent, they have a real shot at making the secure path the easy path — turning today’s messy reality into a faster, safer way of building software.

  • Embracing the MCP Suck: Taming the Wild West of AI Protocols

    Embracing the MCP Suck: Taming the Wild West of AI Protocols

    The Model Context Protocol (MCP) is moving faster than the developer community can keep up with, racing past its original design parameters and leaving teams scrambling to build clients that can match its pace. The result is an ecosystem where the protocol itself keeps shifting under everyone’s feet, and where the tooling, conventions and security thinking that should accompany a foundational standard are still being figured out on the fly.

    Joey Stout, solutions architect at Spacelift, joins Mike Vizard to make the case that this is the price of being early. Stout describes an environment that increasingly resembles a Wild West, where rogue MCP servers get spun up inside organizations without anyone in leadership knowing they exist, let alone whether they have basic guardrails wrapped around them. The convenience of standing one up in a few minutes has outrun the discipline needed to govern them.

    MCP servers can give AI agents broad reach into internal systems, data and APIs, and most of the early implementations were never designed with adversarial behavior in mind. Without authentication standards, scoped permissions and observability built in, every new server becomes another piece of shadow infrastructure that can be exploited, misconfigured or simply forgotten until it causes a problem.

    Stout’s advice for developers is blunt: embrace the suck. The protocol is going to keep changing, the security story is going to keep evolving, and waiting for a stable, fully governed version before getting hands-on isn’t a realistic option. The teams that learn to wrangle MCP now — messy edges and all — will be the ones positioned to set the patterns everyone else ends up following.

  • The Open Source Trap: Why Trust Isn’t a Security Strategy

    The Open Source Trap: Why Trust Isn’t a Security Strategy

    The XZ Utils backdoor was a wake-up call, but the underlying problem it exposed has not gone away. Sophisticated adversaries are playing the long game, spending months or years earning trust within open source projects before introducing malicious code into libraries that sit at the foundation of modern software infrastructure. Mike Vizard and Josh Bressers, VP of security at Anchore, dig into why the software supply chain remains dangerously vulnerable and what the industry is getting wrong in its response.

    Bressers points out that the vast majority of open source projects are maintained by a single person or a very small group of volunteers. These maintainers are often overworked and under-resourced, managing critical dependencies that thousands of organizations rely on in production. When an attacker targets one of these projects, the maintainer is the entire security perimeter. No amount of scanning or compliance tooling downstream can fully compensate for a compromise that happens at the source.

    The instinct for most organizations is to throw money or tooling at the problem, but Bressers argues that approach misses the point. Running vulnerability scanners is necessary but insufficient. The deeper issue is that companies consuming open source at scale are not contributing back in meaningful ways, whether through code review, maintenance support or funding that actually reaches the people doing the work. The supply chain cannot be secured from the outside alone.

    Trust has functioned as the default security model for open source adoption, and the XZ Utils incident demonstrated exactly how that model can be exploited. Moving to a “trust but verify” approach requires organizations to understand what is actually in their dependency trees and to take an active role in protecting the projects they depend on.

  • Why Code Validation is the Next Frontier

    Why Code Validation is the Next Frontier

    Shared staging environments were never designed for a world where dozens of changes land in a codebase every hour. Yet most engineering teams still depend on them as the primary checkpoint before production. Alan Shimel and Arjun Iyer, CEO of Signadot, dig into why that model is falling apart and what needs to replace it.

    The root of the issue is straightforward. In a microservices architecture, verifying a single change means understanding how it interacts with every other service it touches. Shared staging environments try to replicate that, but when multiple engineers and AI tools are pushing changes at the same time, those environments become noisy. A test failure might be caused by the code under review or by an unrelated change from someone else. That ambiguity erodes confidence in the entire release process.

    Iyer makes the case that validation needs to move out of shared environments and into isolated, on-demand setups that reflect real production behavior. The goal is to give every change its own context for testing, eliminating the crosstalk that makes shared staging unreliable. This becomes especially important as AI-generated code increases the volume of changes flowing through a pipeline, since the validation layer has to keep pace without becoming the new queue that everyone is waiting on.

    The conversation raises a question that teams are going to face more frequently: is the deployment pipeline built to handle the throughput that modern development tools are capable of producing? For many organizations, the answer is not yet, and closing that gap is where the next wave of engineering investment is likely to go.