Software and security teams have never had to patch so much code so quickly. AI agents can generate vulnerability fixes in seconds, but pushing unverified, machine-authored code to production has led to trading a CVE for a production outage. To solve this problem, SRE principles are now gaining new traction in application security and development teams that realize mitigating one risk shouldn't create another. To benefit at all from agents in SSDLC, we need operational cultures that recognize reliability as a combined social and technical measure, rather than just another tooling challenge. In this talk, we’ll walk through the practical mechanics of safely remediating vulnerabilities with agents. We’ll cover how TDD provides the baseline contract to keep patches from breaking existing features, why symptom-based test coverage catches regressions traditional tests miss, and how sandboxed runtimes isolate untrusted agent execution. Finally, we’ll look at closing the loop with automated canary analysis and SLO-driven rollbacks so fixes can deploy without risking production. We'll stick to real scenarios that helped us patch hundreds of repositories without breaking any relying applications (at least as far as users could tell).

Aron Eidelman is a Senior Developer Relations Engineer and Security Advocate at Google. He works on AI software security, leading developer enablement for Google's AI Threat Defense program, CodeMender, and Antigravity security skills. He co-authored Kaggle's "5 Days of AI Agents" curriculum, which trained over 350,000 developers globally in secure coding. Aron is a frequent speaker on secure software development, with recent talks at Google Cloud Next '26 and the Zenity AI Agent Security Summit. Outside of Google, Aron serves as the Chairman of Azure Printed Homes. The company 3D prints modular housing from recycled plastic, repurposing 150,000 plastic bottles per unit for wildfire recovery projects in LA and a new 62-unit housing village in San Luis Obispo.

We know how to observe conventional software: requests, traces, errors, latency, resource utilization. But an AI system can return 200 OK, stay within its latency budget, and still make the wrong decision. That creates a different reliability problem. What instructions and policies governed an execution? What did the model actually receive? Which decisions were probabilistic and which were deterministic? What changed between two runs? Can we replay an execution, test a proposed change against historical cases, and produce evidence of exactly what happened? This talk explores the architecture that emerged while building AI for real operational workflows: shrinking the responsibility of the model, moving policy and authority into deterministic software, and treating execution itself as a governed, replayable artifact. The goal isn’t to make probabilistic models deterministic. It’s to make the systems around them controllable, testable, and accountable.

Joel Lipton is the founder of FoxCommand and a former Product Designer at Amazon, where he worked on Agent AI integration into customer facing and operations products. His background spans product design, AI systems, and complex operational workflows. He is currently building FoxCommand, an execution and governance layer for AI systems that lets teams define deterministic contracts and policies around probabilistic models, then replay, compare, simulate, and audit how those systems behave. His work focuses on a practical engineering problem: how do we get the flexibility of probabilistic models without giving up the control, testability, and accountability we expect from production software?

How AI agents fail differently than traditional software—silently, non-deterministically, and in ways that drift as models update—and practical patterns for incident classification, observability, and postmortems built for probabilistic systems.

Edward Borukhov is the Fractional Head of Reliability & Operations at Beyond Uptime, where he helps organizations build incident response and operational maturity for both traditional and AI-driven systems. He spent 15 years in enterprise SRE and technical operations at Walmart Labs, Symantec, Harmonic, and Apple, and now works as a fractional reliability lead for companies navigating the shift from reactive incident response to proactive, AI-enabled operations.

The career ladder most teams still hire into does not really describe the people joining them now, and on-call is where that gap shows up first. I started shipping production code at fourteen. I never got the version of this job where someone walks you through syntax and then slowly widens your scope, because by the time I started, that was not how anyone around me was learning. We went from tutorials straight to orchestrating systems with agents. That produces engineers who move unusually fast and who have real gaps in unusual places, and most runbooks and escalation paths assume neither of those things. In fifteen minutes I want to be specific about what that looks like from the inside. Where we are genuinely faster, where we are genuinely worse, and the two things I would change about code review and on-call rotation if you are hiring people like me. You would probably rather hear it from someone currently living it than from a report about us.

Artemis Leonardou is a software engineer and DevRel at NOFire AI. She has been building since she was 14 and now ships AI-generated code to production as a matter of routine, which is where most of what she talks about comes from. She was selected among the top 2000 global CS talents for Y Combinator's AI Startup School, has won first place in three hackathons, and her technical content has crossed 2 million views as Artemis Codes. She has spoken at React Summit and TechBiz, speaks at DevConf.US in September 2026, and leads a hands-on workshop at Open Conf in November. She is 19 and still a full-time student.

Multi-agent AI systems are distributed systems, but many still pass data through prompts. This loses information, wastes tokens, and makes failures hard to manage. This talk presents a shared data bus where agents exchange a database ID. Using a real three-agent pipeline, I’ll cover retries, conflicting writes, access control, monitoring, and cleanup. I will also provide a guide for choosing between prompts, queues, files, and databases.

Eddie Tejeda is co-founder and CTO of Hotdata.dev , which helps AI agents create databases in milliseconds. He is a two-time founder and previously led engineering at Mode Analytics and ThoughtSpot.

Site Reliability Engineering was never meant to be about firefighting, yet too many teams find themselves stuck in an endless cycle of pages, postmortems, and quick fixes. Why? Because SRE is full of hidden traps — patterns that look like best practices on the surface but slowly erode reliability, burn out engineers, and stall progress. In this talk, we’ll expose the 7 Deadly Traps of SRE, from the obsession with chasing “five nines,” to the cult of on-call heroism, to the false comfort of tooling and checklists. For each trap, we’ll unpack why it’s so seductive, how it quietly sabotages your team, and what to do instead. You’ll walk away with a clearer lens on the pitfalls holding SRE organizations back, and a practical playbook to help your team escape firefighting mode and reclaim the true purpose of SRE: building systems - and cultures - that are resilient, scalable, and human-friendly.

Miko Pawlikowski is an SRE Author and a platform engineer at Quadrature. He has led large-scale infrastructure and SRE initiatives at Citadel and Bloomberg, with deep expertise in Kubernetes, cloud computing, and chaos engineering. Passionate about building resilient systems and communities, he brings together engineers worldwide through conferences and media projects.