devopsy.kinsta.cloud

Category: Video Interviews

  • Keeping Humans Accountable as AI Agents Take On the SDLC

    Keeping Humans Accountable as AI Agents Take On the SDLC

    Who is responsible when an AI agent finishes a development task? Ming Wu, head of engineering for Dev AI at Atlassian, puts that responsibility with people. In her interview with Alan Shimel, she separates the ability to automate work from the obligation to understand and control the result. That distinction matters as teams move beyond individual coding prompts and start assigning agents larger portions of the software development lifecycle.

    Wu describes governed agent loops as two related capabilities. Governance supplies visibility, guardrails and enforcement; loops allow agents to process batches of jobs under defined conditions instead of waiting for someone to trigger each task. The scope can include taking on an issue, carrying out the work and reviewing a pull request. Automation may handle more steps, but teams still need a way to trace activity and judge whether the output meets their expectations.

    Existing work-tracking systems offer a place to organize that activity. Wu explains why Jira is an initial interface for the approach: it already records work across teams and organizational boards. She also describes support for third-party coding agents and a shared context layer intended to give agents a consistent understanding of team priorities, organizational requirements and business intent. Coordinating those inputs is part of the engineering problem, particularly when several agents contribute to the same body of work.

    Customers are asking how to scale these workflows and demonstrate real improvements in delivery speed, according to Wu. Some software teams are already experimenting, while organizations in more traditional industries are at different stages of adoption. Her examples put visibility into work alongside automation itself: teams need to see what agents are doing, where people remain accountable and whether the investment is producing useful gains. Completing more automated tasks is only part of that assessment; understanding their contribution to the software lifecycle is the harder question.

  • Headless DevOps Gives AI Agents Access to Delivery Workflows

    Headless DevOps Gives AI Agents Access to Delivery Workflows

    A delivery platform built around screens and mouse clicks assumes a person is doing the work. That becomes a constraint when developers delegate tasks to coding agents from inside their development environments. Exposing the same capabilities through APIs, command-line tools and agent interfaces changes how work reaches the platform, but it does not remove the need to test changes, enforce security checks or decide which actions still require a human.

    Federico Larsen, co-founder and CTO of Copado, joins Alan Shimel to explain that shift through the lens of Salesforce development. Larsen describes three access layers: APIs, CLI commands and packaged agent skills or MCP servers. Developers using tools such as Cursor and Claude Code can delegate work without having to move every step back into a graphical interface. The design accommodates autonomous execution as well as workflows that keep people involved in decisions.

    Giving an agent more access also expands what teams must validate. Larsen points to connected applications, IP ranges and agent behavior as areas that need security scrutiny, alongside quality gates earlier in the delivery process. Testing an agent adds another complication: its responses are not necessarily identical from one run to the next. Teams need to assess whether it stays on task and follows corporate language requirements, rather than relying only on a fixed expected answer. He also describes generating regression tests from user-story acceptance criteria.

    The distinction between making a platform accessible and making it safe to automate runs through Larsen’s examples. An API can expose an operation, but the surrounding workflow still needs checks on the changes an agent produces. His account connects headless access with testing and compliance, not simply the removal of a user interface. As agents take on more delivery tasks, those controls need to remain part of the path from a developer’s request to an accepted change.

  • GitHub Workflows Strain Under AI Agent Development

    GitHub Workflows Strain Under AI Agent Development

    GitHub was built around human workflows. That assumption held for a long time, and it worked — repositories, pull requests, code review and CI/CD pipelines all evolved around the pace at which people ship code. AI agents break that assumption in a hurry. Commits, pull requests, issues and branch changes now arrive at machine speed, and the systems that scaled fine for teams of engineers are showing strain when a swarm of agents is generating activity around the clock.

    Mike Vizard sits down with Rob Whiteley, CEO of Coder, to work through what that strain actually looks like in practice and why repositories, pipelines and developer platforms are hitting limits that were not visible a year ago. Whiteley’s argument is that the core idea of Git is still useful — distributed version control is not the problem — but the platforms wrapped around it were designed for a slower, more deliberate cadence than agentic development produces. Volume and velocity are the pressure points, and the operational side of GitHub is where they show up first.

    They get into the security and supply chain angle. Malware and risky code can move through repositories quickly, and AI raises the ceiling on both attacker automation and accidental mistakes from legitimate teams. Actions, webhooks and CI/CD integrations turned code repositories into operational control points, which made development faster but also made GitHub a critical dependency for a large slice of the industry. As agents take on more coding work, teams need real boundaries around what agents can access, how they trigger workflows and how their activity is audited — the permissions and execution environments that were adequate for human contributors are not obviously adequate for the agent equivalent.

    Whiteley’s read is that agentic development calls for more distributed, policy-aware and resilient systems, with stronger controls around context and execution. Rethinking developer infrastructure before scale, security and reliability turn into blockers is where the organizations getting ready for this next phase are already putting their attention.

  • Trusted Open Source Catalogs for AI and Developers

    Trusted Open Source Catalogs for AI and Developers

    Open source supply chain security has been a scanner-and-CVE game for years — pull the package, run the scan, cross-reference known vulnerabilities, hope the metadata is current. That model always had gaps, and AI agents are widening them fast. Agents pull open source components from wherever they can find them, at machine speed, and the after-the-fact scan is not a control that keeps up. What developers and platform teams actually need is a curated catalog that vets components before they enter the environment, not after they cause a problem.

    Alan Shimel sits down with Leslie Pascual, Field Engineering Manager for AI and Security Solutions at ActiveState, to work through what a trusted open source catalog looks like in practice and why it becomes table stakes as soon as AI agents join the software supply chain. Pascual brings more than 20 years across engineering, architecture and leadership, with a stint hardening enterprise healthcare applications that pushed her into cybersecurity. Her point is direct — scanners compare packages to CVE metadata after the fact, which is fundamentally different from vetting a component before it ships.

    They get into the mechanics. Packages go through a cool-down period, secure build, attestation and strong provenance before landing in the catalog, which now spans the top nine open source ecosystems and is expanding to twelve — Python, Java, JavaScript, R and more. Continuous monitoring keeps catalogs current with patches and fixes, and SBOMs and attestations ship with every component. The integration side matters just as much: catalogs plug into JFrog Artifactory, Sonatype and Cloudsmith so developers see no extra friction, and mirrored repositories let each customer expose the catalog inside their own Artifactory instance.

    The forward-looking piece is where AI agents plug in directly. Tools like Claude and Cursor need a source of truth for open source components, and Pascual argues that the trusted catalog becomes exactly that — the place agents pull from instead of grabbing whatever the internet returns. An MCP server is on the roadmap to extend that intelligence directly into the CI/CD pipeline. The broader read is that shifting security all the way left, past the scanner and into the catalog itself, is what actually makes AI-assisted development safe enough for enterprise teams to scale.

  • AI Raises the Stakes for Observability Engineering

    AI Raises the Stakes for Observability Engineering

    AI-assisted development has quietly changed which part of the software lifecycle is hardest. Writing code is no longer the bottleneck. Understanding what the resulting system is actually doing in production is. When agents and assistants can generate whole services in an afternoon, the ability to validate change, investigate incidents and reduce risk becomes the constraint that actually decides how fast a team can ship — and that puts observability engineering squarely at the center of the conversation.

    Alan Shimel talks with Liz Fong-Jones, Technical Fellow at Honeycomb, about what that shift looks like from the ground. Fong-Jones draws a sharp line between telemetry and observability that most teams still blur. Telemetry is the raw material: logs, metrics, traces describing what is happening inside a system. Observability is the broader property of being able to combine that data with human knowledge and process to actually understand the system and make better decisions. Her framing is that observability is a living quality of software — like testability or accessibility — and a team is never done with it.

    They get into how AI reshapes the observability loop itself. Fong-Jones sees real leverage in agent-assisted workflows that generate instrumentation code, sift through mountains of telemetry and help engineers move through investigations faster. The point is not that AI removes human judgment from the loop. It changes where humans spend their time, pulling them off toil and toward the interpretation and decision-making that only a person can do. The second edition of the O’Reilly book Fong-Jones co-authored reflects that shift — the field has moved past arguing whether observability differs from monitoring and into how it supports AI-driven software delivery.

    The bigger arc is that cloud native has become the default substrate for modern software, containers and Kubernetes are now assumed rather than debated, and OpenTelemetry sits underneath the whole picture as the standard everyone builds on. In that world, observability engineering is not a nice-to-have added on top of production. It is the thing that lets teams move faster with AI while keeping the risk of moving faster inside acceptable bounds — and the organizations that treat it as a first-class engineering discipline are the ones that get to keep shipping when everyone else is chasing incidents.

  • The Verification Gap Behind Every AI-Generated Release

    The Verification Gap Behind Every AI-Generated Release

    Code creation has never been faster, but the machinery around it has not sped up in step. AI coding tools can now produce more lines in a morning than a team used to ship in a sprint, while testing pipelines, review processes and device coverage still move at the pace they did two years ago. The result is a widening gap between how much software is being written and how much of it anyone can actually verify — and that gap is where production incidents live.

    Mike Vizard sits down with Prince Kohli, CEO of Sauce Labs, to work through what that imbalance is doing to release quality. Kohli’s framing is that leaders keep mistaking code velocity for product velocity. Generating an application in an afternoon is not the same thing as shipping one. Reviews still need to happen, tests still need to be authored, device coverage still needs to be real, user journeys still need production-like validation. Skip those layers and the AI advantage evaporates the first time a subtle defect makes it to customers.

    Kohli lays out a specific failure pattern engineering leaders should look for: using the same AI model to write the code and verify the code, which he compares to letting a student grade their own homework. Mature teams are moving to independent verification systems that evaluate application intent, author their own tests, run them in the right environments and troubleshoot the failures they surface. Human reviewers also carry a heavier cognitive load in this world, because developers now read a lot more code than they write and often lack the context behind the AI-generated architecture in front of them.

    Sauce Labs research puts numbers on the risk. Kohli says 80 percent of organizations have traced a production incident or outage back to AI-generated code, 90 percent reported serious business impact from those incidents, and 66 percent admit they compromised quality or testing standards to hit faster release deadlines. His pitch is not to slow AI down. It is to invest in verification at the same rate as generation, because the teams that treat testing as a second-class citizen in an AI-first pipeline are the ones already writing incident post-mortems they did not need to write.

  • AI Code Generation Raises New Quality Risks

    AI Code Generation Raises New Quality Risks

    AI coding tools are producing more code, faster, than teams have ever had to absorb before. That productivity story is real, but it comes with a bill that most engineering leaders have not fully paid yet. Technical debt piles up faster. Repetition slips in. Security gaps and quality issues show up in places where nobody was watching, because nobody wrote the code that put them there. Speed alone is not the win it appears to be if the review layer never scales to match.

    Mike Vizard sits down with Mladen Lazic, CTO of Scopic, to work through what it actually takes to keep AI-assisted development from turning into a debt engine. Lazic’s core point is that reviewing AI-generated code is genuinely harder when engineers were not part of how it was created — context is missing, intent is unclear, and the usual mental shortcuts a reviewer relies on stop working. His answer is to keep developers in the loop from the start and treat AI tools as junior developers who need direction, not autonomous builders who ship features alone.

    They get into the mechanics of independent validation. Lazic warns against a common failure pattern where the same AI agent writes the code, generates the tests and reviews the output — effectively grading its own work. Scopic is moving toward separate agents for coding, pull request review and test creation, with some testing agents deliberately blind to the source code so they validate against requirements rather than against whatever the coding agent happened to produce. That separation is what turns AI QA into a real check instead of a rubber stamp.

    Looking further out, Lazic expects the engineer’s job to shift toward instruction, monitoring, verification and improvement rather than raw production. That reframes AI code quality as a durable concern for DevOps, security and application leaders — not a phase to get through. The teams that build better gates, sharper observability and independent QA now will be the ones shipping better software sooner, without eating the debt everyone else is quietly accumulating.

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