Connect your Claude, Codex or OpenClaw for full transcripts on millions of podcasts. Two week free trial, cancel anytime.
Start free trial →The Stack Overflow Podcast · Hands-On Engineering Podcasts · November 2026
Asked whether faster AI-assisted code delivery has hurt quality or caused more outages at Airbnb, Ahmad Al-Dahle calls it his biggest fear and describes the processes the company uses to keep reliability at pre-AI levels.
…commiserate with the speed that AI gives you. Still improving. We still have a lot more work to do, but that's kind of the mentality you want to bring is like, are we moving at the pace that we should be? And is our human tax low enough that the cost is mostly associated to building and iterating?
I think there's a concern with the increased speed of delivering code to production that there's a reduction in quality too. So I wonder if you notice any sort of change in incidence, production outages.
I love that question. Not enough. People are asking this. This is like my biggest fear. Like I go to sleep at night wondering how many slop grenades have people put in today. So it's definitely something I worry about and I keep my eye on. I am like very on top of goals for reliability. We're very, we're very aggressive on making sure that that stays where it is pre-AI and we don't suffer as a result. So we have very strict guidelines on outages. If we trip too many of them too quickly, we actually do give like a concept for code yellow and then eventually code reds so that we maintain focus on testing, on testability, on observability, on remediation, and making sure we understand every outage. We have very strong culture around CEVs. When we have an outage or a defect, we have a pretty rigorous process that I attend to make sure like we prioritize remediation. I'm very proud of this. Our agentic coding usage has been very geometric, but our defect ratios or defects in production has been linear. So it has increased. We have not been able to hold it, but it's increased…
To go back to the productivity question, are things like Dora metrics still optical or do we need new ways to measure the velocity of a development team?
The process of building product and features and deploying things into production is an inherently multi-disciplinary problem. So in addition to like rethinking how software engineering velocity works, you kind of have to think about the whole software development lifecycle. And that's where I…
Are there many parts of a piece of business critical software that are just committed and quit it, like doesn't need anybody but an engineer on it?