Amazon’s IDE for Spec-Driven Development with David Yanacek

AI assisted coding tools have made it easier than ever to spin up prototypes, but turning those prototypes into reliable, production grade systems remains a major challenge. Large language models are non deterministic, prone to drift, and often lose track of intent over long development sessions. Kiro is an AI powered IDE that's built around a spec driven development workflow. It's focused on helping developers capture intent upfront, translate it into concrete requirements and designs, and systematically validate implementations through tasks, testing, and guardrails. It aims to preserve the creativity of AI assisted development while producing software that is ready for real world use. David Janacek is a senior principal engineer and a lead advisor on the Agentic AI team at AWS. Today, his work focuses on Kiro, Frontier agents, Amazon Bedrock Agent Corps, and AWS's Operational Agents. He joins the show with Kevin Ball to discuss the design of Kero, how spec driven development changes the way teams work with AI coding agents, and what the next generation of agentic software development might look like. Kevin Ball or Kate Ball is the vice president of engineering at Mento and an independent coach for engineers and engineering leaders. He cofounded and served as CTO for two companies, founded the San Diego JavaScript meetup, and organizes the AI in action discussion group through Latent Space. Check out the show notes to follow Kay Ball on Twitter or LinkedIn, or visit his website, kball.llc. David, welcome to the show. Oh, thanks. Great to be here. Very excited to chat today. Yeah. So let's start out with a little bit about you. Can you give me the quick rundown of who you are and how you got to where you are today working on Cura? Sure. I'm a senior principal engineer who has spent my coming up on twenty year career exclusively at Amazon with a singular purpose in mind, and that is to make developers' lives easier. I've been just focused on that. It all comes from, I guess, how we build and operate software here. We do DevOps. And so to us, DevOps means, of course, takes different meanings depending on where you are and how you use the term. That's how language evolves, of course. But to us, that means developers do the ops. There is no DevOps separate thing. It's just a state of how to do dev more than it is to be a separate thing. Anyway, so because of that, that obviously puts a lot of work responsibility on the shoulders of me, the developer. And so I've been moving from team to team over the years at Amazon a mostly AWS, trying to build the next thing that's going to help life as a developer be easier. So that means I found it tedious on the first team I I was on to operate databases, especially when they scale and when you need to be highly available. And on one hand, I didn't like doing database …