AWS Summit Los Angeles 2026: Why Am I Always Learning the Hard Way?

I walked into the Kiro lab thinking I had my wits about me. I'd been building a web app with Kiro for weeks. Next.js on Vercel, API routes talking to DynamoDB, Bedrock handling the AI layer. An H0 hackathon submission with 15 days left on the clock. By then Kiro and I had a rhythm, so the lab wasn't a rescue but a resource. I signed up the way you check under the hood of a car you already drive. Curious, excited to learn. But one saying I keep close is you don't know what you don't know. I went for the structure, to sharpen how I build, not to confirm I already had it. Clayton Markos was running it, an AWS Senior Technical Instructor. The session had one goal: spec-driven development. And this was new ground. I'd never had Kiro start a project. I scaffold it myself, then bring it in. Letting Kiro generate the structure first was something I hadn't done. The task was a weather app. Ninety minutes, build it, deploy it. I was confident I could get it done. Nervous but confident. Building under pressure like this is new to me. 90 minutes? Let's go. Then I watched how the build was supposed to go. Spec first. Not a vague prompt and a prayer, an actual spec. The what, the constraints, the boundaries, written down before Kiro touched a line. Then Kiro works inside that. I'd been doing the upfront work. Just not in the shape Kiro wants it. I build with Claude as my architecture and build assistant, so I had docs. Plenty of them. But they were Claude docs. Reasoning and notes written for me to read, not specs written for Kiro to build from. Kiro's strength is spec-driven. I'd been handing it Claude-shaped prose and asking it to infer the spec. In some places that worked. In others it drifted, because I'd given it room and no edges. I built the weather app. Deployed it by the end of the lab. It shipped, same as my builds always ship. Thankfully. But I didn't come to ship a weather app. I came to learn. And the lab handed me the question underneath all of it. Am I using these tools to their full capability? Do I understand how they work? Am I building so my builds can succeed? The spec is a tension, not a setting The lab reframed how I get the most out of Kiro. It isn't tighter control or looser reins. It's the spec, and how I develop it. That's one of the levers that decides how well the project holds up. Too rigid, and Kiro has no room to make a good call. You've pre-decided everything, including the parts you shouldn't have, and now it's a very expensive autocomplete. Too loose, and it drifts. It fills the gaps with its own guesses and you spend your time pulling it back. The sweet spot is narrow. The spec defines the what and the constraints. Kiro decides the how. I already had a version of this in my steering doc, a rule that says propose before you build, ask before you assume. I just hadn't connected it to the spec the way the lab did. The learning curve tax I'm self-taught. My first prototype was a jury eligibility chatbot, and I started it before I knew what an API was. The whole time, one question. Can I make this work? Turns out I could. I demoed it to my boss at the time. Not much has changed. I still pick up a tool by using it, usually with AI in the loop, usually inside something I've already shipped or am racing to ship. The understanding of how to guide the build shows up late, a beat after I needed it. Filed under my lessons learned doc for the next projects, the June Game Jam and Hack the Kitty . That's the tax. You don't know what you don't know, so you can't plan around it. You build, and you let the gaps introduce themselves, one expensive and time-consuming surprise at a time. And so far, I keep paying it. I haven't found a way to skip the tax or leap the learning curve, at least not one that's mine. Hence, the lab. The rest of the day kept pointing at the same thing The Anthropic talk, "Effective Context Engineering for AI Agents," was standing room only. Every seat gone, people on the floor along the walls because