AWS re:Invent 2025 - Keynote with Dr. Werner Vogels

🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.

Overview

📖 AWS re:Invent 2025 - Keynote with Dr. Werner Vogels

In this video, Dr. Werner Vogels delivers his final re:Invent keynote, introducing the "Renaissance Developer" framework with five key qualities: curiosity, systems thinking, communication, ownership, and becoming a polymath. He addresses AI's impact on development, emphasizing that while AI will automate tasks, developers remain essential by evolving their skills. Vogels shares examples from his travels to Africa and Latin America, highlighting developers solving real-world problems. Clare Liguori demonstrates spec-driven development in the Kiro IDE, showing how specifications reduce ambiguity in AI-assisted coding. The keynote stresses the importance of code reviews, mechanisms over good intentions (illustrated by Amazon's Andon Cord story), and taking ownership of software quality despite AI generation. Vogels encourages developers to build T-shaped expertise—deep domain knowledge with broad understanding—and maintain professional pride in their work.

; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.

Main Part

A Journey Through Generations of Developers: Werner Vogels' Final re:Invent Keynote

And of the developer. I've heard that before. Hi there Lorraine. What are you doing? Oh, you know, organizing yesterday's program cards, which got dropped. Figuring out why the machine keeps stopping on card 442. Logging this really awkward bug in the compiler and talking to you. Anything new at head office? I've been reading about this. Bubble. Yes, that's the new high level language. It's amazing. Now anyone can write code. I don't know about anyone. Writing software is pretty tricky.

What software? Where? You. Marty? What you reading? Learning some VB. Visual programming. Code history. Marty. Drag and drop is the future. Drag and drop is still code. It still has bugs and it still needs an engineer. Everything feels all the time. Is this for real? Could Claude mean there will be less engineers? Less engineers? Time for an airdrop. Servers in minutes. Scale on demand. Pay as you go. Wow. You learn something new every day. You build it, you run it. WAN.

Don't forget to call mom. Why there. Marty? Nice wormhole, isn't it? Mind if I join you? Boy? You can skip this one. Is this the end of development as we know it? Or is it just another new beginning? Please welcome the Vice President and CTO of Amazon.com, Dr. Werner Vogels.

Trust. I seek and I find in you something new for us every day, an open mind for a different view. And nothing else matters. Good morning. Hello, everyone. The video showed you every generation of developers that face the new wave of change. Tools evolve, architectures evolve, expectations evolve. And so do we. But before we talk about that, let's talk about the elephant in the room. I've been giving this keynote since 2012 and I've done all of them. That's a lot of t-shirts, by the way. But today this streak ends. This is my final re:Invent keynote. I've still things to do. I'm not leaving Amazon or anything like that. But I think that after 14 re:Invents, you guys deserve young, fresh, new voices. There are so many amazing engineers at Amazon that have great stories to tell, to teach, to help you, to educate you. I think it's time for those younger, different voices of AWS to be in front of you. But nobody forced me to do this. I'm not leaving Amazon or anything like this. This is my decision to make sure that you get to hear different voices than just mine.

Will AI Take My Job? The Evolution of Developer Tools and Skills

Now let's talk about the other elephant in the room. I visited AWS customers all over the world, and there is one question that keeps coming up in every country and in every city: Will AI take my job? Maybe. Some tasks will be automated. Some skills will become obsolete. New ones will emerge. So maybe we should rephrase and reframe this question. Will AI make me obsolete? Absolutely not. If you evolve, there are ways forward. If I look at the past years at Amazon where we've been using all these new tools, we've seen how you can evolve over time and still be a great engineer. You just have a new set of tools in your hands because we evolve as developers. And so must the tools. Change is constant. This has always been the case. It's nothing new. Let's go back in time a little bit. When I went to school, I was taught 68,000 assembler, COBOL, and Pascal. None of these languages are being used anymore. In the 1960s, we suddenly got compilers, and it didn't really matter anymore what kind of assembly those compilers spit out. However, by learning assembly, I knew how that loop in Pascal actually translated.

into machine code, and that was important to me. Over time, comparison became the highest level of abstractions that most developers needed in the 1950s. Suddenly, structured programming became popular in the 1970s. We were moving towards that, and compilers from Bell Labs and Berkeley supported this shift. They gave developers clearer control over flow and helped them escape the chaos of unstructured code.

A few years later, Bjarne Stroustrup started exploring how to model real-world concepts directly into code through objects and classes, which became C++ and helped shape object-oriented programming. In the late 1990s, Amazon was still running as a monolith in 1998, and this is a famous moment. The growth accelerated to such a point that the team began breaking off pieces of the monolith into services. Each service had ownership, had their own interface, and it completely changed how developers worked. They moved faster and became independent of other teams. They owned their systems end to end.

Over time, the industry at large began adopting these practices as a practical model for building and operating large-scale distributed systems . In the 2000s, most developers were still building and deploying things on-premises . Writing code meant wrestling with hardware, capacity planning, and long procurement cycles. When cloud services arrived, they changed the expectation of the role again. Developers suddenly had on-demand infrastructure and freedom to experiment without waiting for hardware. This required new skills, and developers everywhere adopted the world where cloud infrastructure just became the normal way to build and operate software.

IDEs evolved with us . Remember when Microsoft had that moment where you could actually draw boxes on the screen? That was the first real IDE. Later, we got Visual Studio, and Visual Studio Code became the default because of all the amazing plugins. Today's environments are Cursor and Kiro, and that is the new workflow . Is there a new workflow next year, five years from now, ten years from now? Of course there is. Our tools today are extraordinary.

At AWS, we already saw examples of developers becoming dramatically more productive with AI-assisted workflows . But none of this removes the work that only you can do. Remember, the work is yours, not that of the tools. It is your work that matters. Our tools have changed so many times over the course of my career, and they will continue to change. We are still builders. We are still important. Nothing has changed. There has never been a better time to be excited about being a developer.

The Renaissance: When Art, Science, and Technology Evolved Together

Bezos talked about this not that long ago in an interview. He said we are living at the epicenter of multiple simultaneous golden ages coming together: space travel, artificial intelligence, robotics . Each is advancing at an incredible pace. But what makes this moment different is how these breakthroughs actually reinforce each other.

Progress in one field accelerates progress in other fields. This actually made me think back in history at a time that was kind of similar: the Renaissance, the rebirth. It came after a period of darkness, the Dark Ages, the Middle Ages, the death plague. Anyone who knows Monty Python knows about how that looked. The Renaissance was a period where everything changed because people became curious. Curiosity was absolutely exploding. The result of that is amazing: scientists and philosophers. If you look at this, the Medici is probably the first version of a venture capitalist or philanthropist. Galileo and Copernicus were amazing scientists. Petrarch was one of the first philosophers. Da Vinci, we'll come back to him. But also evolved at the same time were their tools. It's not just them because of curiosity. A pencil was invented. That seems nothing to be invented today, but it was a major thing. The fact that they started thinking about something called a vanishing point meant that if you compare paintings and drawings before the Renaissance, they were all flat. In the Renaissance, suddenly depth appeared and different lighting appeared in paintings and drawings.

Then these tools, like the microscope and the telescope, were invented by Dutch people. And then, of course, the printing press, which we all see as sort of the pinnacle of invention in the Renaissance. But that was not just one invention. Gutenberg actually used a wine press as his first step. But that was not the only thing he needed to invent. He needed to invent movable type, basically characters that you can put together. You had to invent an ink that actually could be put on those characters. And then paper went to press on imaginary, almost imaginary in those days. It was a time where art and science were part of the same conversation. Creativity and technology evolved together.

Spend some time to think about what made people so effective in that world. They were curious. They questioned assumptions. They learned broadly and applied that learning deeply. They didn't see boundaries between fields. They built bridges between them. They were also bold experimenters. They sketched, they measured. They failed. They tried again. They learned by doing.

The First Quality: Curiosity, Experimentation, and the Power of Learning by Doing

If I take all of that in, I think we are again in a time of Renaissance. You are the new Renaissance Developer. Those qualities of those scientists in the Renaissance are just as relevant today. I've brought them together into a framework that I call the Renaissance Developer. I want to show you today this framework, hopefully to help you evolve and be successful in this new era as well. What is crucial in all of this is the first quality that you need to nurture: you need to be curious. Curiosity is critical. As developers, you always have to continuously learn because everything changes all the time.

Every developer I've met has this instinct to take something apart and look at how it works. There's also a drive here—the desire to understand, to improve, to build. You have to protect that instinct. Stay curious because curiosity leads to learning and invention.

Equally important for learning are two things. For all new inventions, you need to experiment. To experiment well, you need to be willing to fail. After all, da Vinci modeled an airplane that never flew, but we're flying now. An experiment is not an experiment if you already know the outcome. This willingness to fail drives experimentation and drives learning, and it's crucial.

I learned a new language, whether that is Dutch, English, Portuguese, or German. I find that the same principles apply. The best way to learn is to fail and be gently corrected. You can study grammar all you like, but real learning begins when you stumble into a conversation and someone helps you get it right. Software works the same way. You can read documentation endlessly, but it is the failed builds and the broken assumptions that really teach you how a system behaves. Anyone who has recently used the Rust compiler knows how much feedback you can really get.

There are some things that you can only learn by doing. Reading, watching, and listening only take you so far. Real learning happens when you engage. When there is some pressure, when the outcome matters, there is a relationship between stress and performance called the Yerkes-Dodson law. The picture is a bell curve. With too little pressure, you disengage. With too much pressure, you're overwhelmed. The sweet spot is somewhere on that rising slope where curiosity meets challenge. That's when your brain is fully alert, focused, and ready to grow.

You can't reach that point by sitting comfortably. You have to put yourself in positions that test you. There's a whole story behind this and the newspaper that you all found on your seats today, the Kernel. There's an article in there by Andy Warfield who writes about this. I urge you all to read that article if you really want to understand more about it.

Learning has another side to it. Learning is social. We're not here only to sit in a room and listen to one person telling you exactly what to do. The thing you really learn is by talking to each other. Learning isn't just cognitive; it is social. You have to touch the glass occasionally. By that I mean you have to get out of your usual environment, go to a user group, attend a conference like re:Invent, or have coffee with a friend and talk about systems. One of the best ways to stay sharp is to be around other people who are building things.

Learning from the World: Developers Solving Real Human Challenges

For me, that often happens when I'm on the road. I travel a lot for work, and those trips keep me connected to how people are actually using technology, not just how we imagine they might. This year I was very fortunate. I took two month-long trips, one to sub-Saharan Africa and the other to Latin America. In both regions I gave some talks, but mostly I met with customers, and the real thing I do is learning from those.

Here are a few examples. It took me 21 years to actually end up on the Amazon. Grupo AJE is a beverage company that supports communities along the Amazon River in a way that gives young people an economic future so they don't leave their villages to go to the big towns. It is a brilliant experience and a great example of how doing good can be profitable.

The Amazon River was beautiful. I saw pink dolphins. But it reminded me of something else that I learned—that not all of this is so great. Early in the year, I spoke with Boyan Slat from the Ocean Cleanup Project during an episode of the podcast, and he told me that 80% of the plastic found in the ocean originates from just a thousandth of the world's 3 million rivers. They need not only to clean up what is already out there, but also to stop new plastics from entering the ocean via these rivers.

They've created a River Model using drones, AI, camera analysis, and even GPS-tagged dummy plastic. When we went to the Amazon, they actually took plastics and put them in the river to see where they ended up. It turns out the Amazon is not a big polluter at all. But this computational model that they've built, with AI cameras on bridges and on the back of ships, creates a computational model that predicts how and where this plastic will travel, helping them position their cleanup systems for maximum impact.

Another thing that totally blew me away on this trip was actually in Rwanda. This is the headquarters of the Ministry of Health and their health intelligence center. In their operation center, huge screens display near real-time data from four different tiers of healthcare facilities across the country. They've built an impressive system that ingests and processes vast amounts of healthcare data, visualizing everything from disease outbreaks to maternal health outcomes, and they use it to create new policies.

They've created this model which shows which parts of the country are more than a 30-minute walk away from a healthcare provider, and they use this data to strategically place new maternal health facilities in underserved areas. They use data to drive policy and to actually implement that policy. Most of these trips, I get blown away every time, especially about how young companies are attacking some of the world's hardest problems.

In this case, we're in Nairobi. I learned that in many places there, people will borrow a dollar or two in the morning, buy some goods, go and sell them in the market or on the street, and in the evening they will give these dollars back and hopefully have 40 or 50 cents, which they made that day. That's enough to go buy some food. It is not enough, though, to also buy the gas to cook your food. So in those poorer parts, it's all burned on carbon, which is massively polluting. So this young company called KOKO Networks came up with a completely different solution. They basically built ATM machines with ethanol in them and small canisters that people can carry.

They can walk up to the machine, plug in their canister, and ask for $0.05 of gas, which will be enough to cook their food that night. This is what happens when developers apply their skills to real human challenges.

Developers have always driven progress. You have built the foundations of the digital world, and today you are the ones turning AI from possibility into something useful, safe, and scalable. Developers like you were essential in the past, are essential today, and will be essential in the future. The United Nations expects that by 2050, we will have 2 billion more people on this planet. How are we going to feed them? How are we going to make sure they have an economic future? How can we make sure they have healthcare? That is on us to develop technologies so that we can help solve some of the world's biggest problems.

As technologists, you have the ability to do this. I have met some of you who spent so much of your time not just building things in the corner of your room, but actually helping others. The AWS Heroes deserve an applause. We now have 265 heroes across 58 countries. What constantly amazes me is how much we can learn from them. These are people solving hard problems in their own corners of the world.

This year, the Now Go Build award goes to Rafael Vincent Wang. Rafi absolutely embodies the Renaissance Developer. He does not just write code; he builds communities, he mentors others, and he co-leads the AWS user group in the Philippines since 2013.

The Second Quality: Thinking in Systems and Understanding Feedback Loops

The first quality I think a Renaissance Developer needs to have is to be curious. I like this quote from Walt Whitman: "We are not what we know, but what we are willing to learn." Another quality that I think the Renaissance Developer has is that he thinks in systems. Let me come with me for a moment. If you do not really understand it, I do not mean the computer system in this case, but in a big system.

In the 1970s, an ecologist called Donella Meadows started studying how complex systems behave. She was a computer scientist, but her insights described our world of software perfectly. She wrote: "A system is a set of things—people, cells, or whatever—interconnected in such a way that they produce their own patterns of behavior over time." This was an extraordinary definition because it captures what every engineer eventually learns: that our systems have lives of their own.

Let me give you an example that is not computer related. One of the most striking examples of systems comes from ecology. In the early twentieth century, the wolves were removed from Yellowstone National Park. It seems logical. Fewer predators meant more elk, meant more life. But the opposite happens. The valleys were overgrazed.

The trees disappeared, and the rivers began to erode. This phenomenon is called the Trophic Cascade. When we reintroduced wolves back into the park in 2010, slowly the park started to heal. Vegetation returned, beavers came back, and even rivers changed course. The wolves didn't move the rivers. They changed the behavior of the overall system. That single feedback loop between predator and prey reshaped the balance of the entire system.

When structure changes, behavior changes. When feedback changes, outcome changes. That's what's called systems thinking. When thinking in systems, we think in complete systems, not just in isolated parts. Every service, every API, every queue is part of a larger system. You can't change one part in isolation. Alter a retry policy and you affect load. Add a cache and you change traffic load and traffic flow. Shift team ownership and you change the pace of delivery.

Each change creates new patterns, some stable and some not. Every dynamic system is shaped by feedback loops. Reinforcing loops, sometimes called positive loops, amplify change. Balancing loops, or negative loops, counteract the change and push the system back into equilibrium. Once you see patterns like this, you start to see where small, well-placed changes might shift the overall system's behavior.

Donella Meadows wrote a paper called Leverage Points: Places to Intervene in a System where she puts all of these things together. There are some words that we know from computer science on a daily basis: positive and negative feedback loops. But you really should read this paper. I'm calling this your homework. Come up and take a picture of the QR code, and that's your homework for the coming week.

The Third Quality: Communication and the Return of Specifications

The Renaissance Developer thinks in systems, and to build resilient systems you need to understand the bigger picture. A third quality of the Renaissance Developer is communication. When you step into this broader view, you realize that the ability to express your thinking clearly is just as critical as the thinking itself. This is why I believe that one of the most important things that an engineer or a technical leader can do for their career is to practice and develop strong communication skills.

Let me give you an example. Let's go back two years when we did The Frugal Architect. I don't know if you remember this picture, but this is the Amazon homepage. I explained to you how we divided that homepage and the overall Amazon system into three different tiers. Tier one is something that is absolutely necessary to make the system work: search, browse, shopping cart, checkout, and reviews. Without those five things, the site doesn't work.

Tier two are things that are important to our customers, such as personalization and recommendations. Tier three might be nice-to-have parts. This is important not just for us as engineers, but as communication tools towards the business. You go and sit around the table with the business and talk about how many nines of availability one needs. For tier one, four nines will cost you that much. For tier two, maybe three nines. For tier three, maybe you don't care at all—two nines, we think.

Well, you know, we'll do a manual failover if the data center goes offline. But it's a communication that you need to have. You need to be able to clearly describe your system and the capabilities and the opportunities to the business. Communication is crucial.

Now, human languages present a bit of a challenge, isn't it? Natural language is ambiguous. But we have so many different senses at the same time that we can turn this natural language into something less ambiguous. Do we put grammar on the grill or are we having dinner tonight? Even without a comma, you probably already have figured this one out.

Now, we've always communicated to machines through programming languages because they were precise. We could precisely indicate to the machine what we wanted it to do. But in today's world of AI-assisted coding, we increasingly communicate with the machine in natural language, which is ambiguous. So we need to develop mechanisms to reduce the ambiguity of that language and reduce ambiguity of the human, such that the machine can create logic.

Specifications reduce ambiguity, and our history is rife with stories of spec-driven development. Dijkstra's structured programming environment was based on formal specifications that proved program correctness before you even implemented it. The Apollo Guidance System relied on meticulous specifications that guided its 145,000 lines of code, a blueprint so precise that it helped land people on the moon. And to talk more to you about specifications, I'd like to welcome Clare Liguori, Senior Principal Developer on the Kiro team.

Spec-Driven Development: Building Kiro IDE Through Rapid Prototyping and Precise Communication

Thank you, Werner. Sometime last year I started noticing that as I was doing AI-assisted coding more and more, I had a communication problem. I was spending more and more time trying to describe to the AI what I wanted. The code that the AI generated was good, but the end software didn't do what I wanted it to do. I would often try to start over with a new prompt and try again.

I noticed that over time I wrote longer and longer, more detailed prompts trying to define what the software should do. I would write these long, detailed prompts in Obsidian and Markdown, and then I would copy and paste it over to my coding assistant. I was essentially creating a specification to better communicate with the AI what I wanted.

Software specifications can clearly communicate how a system should behave, what it should and shouldn't do. Like Werner said, many systems in history have been based on specifications like Apollo missions. It felt like specifications were exactly what was missing from my interactions with my coding assistant. But then I thought, how could we use this idea of specs as prompts? What would spec-driven development look like? This spark of an idea led us to start work on the Kiro IDE.

With this idea, though, we now had a new communication challenge. How can we communicate and validate this idea with potential users? We didn't know what it would look like and we didn't know what users wanted. It was also difficult to describe what spec-driven development was. They hadn't seen it before and we hadn't built it yet. One of the best ways to get your ideas across is to quickly build a prototype, something that your users can see and touch. Rapid prototyping is, of course, not a new idea. Let's go back to the 60s to the time of punch cards.

In 1964, Doug Engelbart at SRI had a rough idea for a device that had wheels on the bottom, and you would slide it across the tabletop to point to something on a computer screen. We can probably all picture this device in our head. But can you imagine going back to the 60s and trying to describe what a mouse is to someone? Engelbart's team rapidly built a prototype out of a block of wood. It was a wooden shell with wheels on the bottom and a button on top. This rough prototype communicated what a mouse was better than any drawing or description could have. It let people put their hands on it and get the concept immediately. It had great ergonomics and felt great in their hands.

Like the mouse, rapid prototyping was crucial for Kiro. We knew that the ergonomics of spectrum and development was going to be important—how it felt in the hands of a developer. We rapidly built prototypes of how we thought spectrum and development could work, and we put those prototypes in the hands of some internal users. We asked them to use Kiro every day. That was going to be the best way for us to understand what felt good and what didn't feel good.

This is a great example of what AI can do for us now. AI has fundamentally enabled rapid prototyping for software. In the past, we've all spent months manually coding a single idea, and now we can give our users real working prototypes in minutes to get feedback about what feels right. Rapid prototyping Kiro even let us use Kiro to build Kiro. Our very first prototype of the Kiro IDE could only do coding, but from that moment on, we were able to use the Kiro IDE to generate the code for the Kiro IDE.

By using the Kiro IDE to build out the product, we were able to iterate through many ideas of how spectrum and development could work. One idea was test-driven development specs. Taking inspiration from TDD techniques, you would describe a change that you wanted, and Kiro would generate tests to validate the behavior that you described. Kiro would then generate application code and make sure that it passed those tests. However, we found that developers couldn't always capture the nuance of what they wanted their software to do or look like with tests only.

We tried out traditional technical specifications similar to those that Werner described for the Apollo Guidance System. They described the system as a whole and each component in detail. With this, you'd add a new feature to the overall spec, and Kiro would kick off coding tasks based on the changes that you described. These specs were great context for the AI and even for developers who weren't very familiar with the code base. But for real world projects, they sometimes became overwhelmingly long, so it was difficult to figure out where in this long spec you should put your changes for your new feature.

We took a step back and looked at how we already worked as a team. We had a new feature idea. We would describe it, work through product requirements, review a design doc, and create sprint tasks. We thought that perhaps specs could follow the same pattern, and that became feature-driven specs. We separated the flow into three documents: requirements, designs, and tasks. We found that this gave developers more control over the AI and let them better communicate what they wanted.

All of these rapid prototypes gave us critical user feedback that led to today's spec-driven development workflow in the Kiro IDE. With a spec workflow now in place in Kiro, we could use it more effectively to keep building out the product because we could communicate more precisely with the AI what we wanted. Often with free coding, I find that we give these very ambiguous tasks to the AI. We might say build me a web trivia game, and out of this very short prompt, there's probably a million possible different final outcomes. But probably only one of those is what you have in your head.

With free coding, the AI is going to take its best guess as to what you meant. It'll generate code, but that leaves you to iterate on the code with the AI instead of on what you originally meant. With spec-driven development, you have an opportunity to refine what you mean more precisely through specs. You can give the Kiro IDE that same ambiguous task, but instead of jumping into the code right away, it's going to first

generate requirements, designs, and tasks. If those don't match what's in your head, you have the opportunity to ask Kiro to change it and refine it. Let's walk through a real example of a production feature that we built in the Kiro IDE using Spectrum in development system notifications.

We started here with a little annoyance that we ourselves experienced with an early version of the Kiro IDE. Agents can take a while to complete their coding work, and meanwhile we would switch away to a different app. But then the agent would need user input, or it would complete its work and we would have no idea that it was sitting there idle while we were away doing other work.

So we set out to build a feature that would notify the user when the agent needed its attention. We started by having Kiro generate a spec, and the generator requirements actually helped us think through some details, like which agent actions should trigger notifications to the user. When we got to the design phase, we expected this to be a pretty simple integration into the Kiro agent code, but instead Kiro generated this very complex design that would build an entirely new notification system directly in our agent code.

Now, if we had just coded this, we would have ended up with a lot of code that we didn't actually want. But instead, the spec process helped us quickly realize this was a much bigger project than we originally thought. We iterated on the spec to first focus on building a notification system directly outside of the agent code and directly in the underlying IDE code.

This needed to be built on top of Electron's native notification API. Kiro IDE is based on VS Code, which is a code base that spans ten years of development and two million lines of code. It can be difficult for any developer to figure out where they need to make changes in this code base, but Kiro spec workflow actually helped us explore and understand where these changes needed to be made.

Once these changes were in place, we were again able to use spec-driven development to integrate it into our agent code. Throughout this project, we were able to quickly iterate on our specs until we got exactly what we wanted from the AI. With spec-driven development, we shipped this agent in roughly half the time compared to if we had coded it.

In our experience building Kiro, we realized that AI has changed how we communicate and how fast we can iterate. We can iterate on the software design by communicating with the AI through specs, and we can iterate on what the software does by putting real working applications fast into our users' hands and getting feedback. AI and spec-driven development helped us build a better Kiro IDE, and this was in large part due to more precise communication with our users through rapid prototypes and with AI through specs.

Natural language doesn't have to mean high ambiguity. Personally, this is what I think makes Kiro IDE so special. Kiro IDE brings precision to natural language, and with that, I'll hand it back over to Werner. Thanks, Claire. Communication is so important that Claire shows it leads to systems that have fewer mistakes.

The Fourth Quality: Ownership, Quality, and the Power of Mechanisms Over Good Intentions

Let me tell you a story from my own youth, when I went to computer science school. There was a class called Interview Technique. I thought, why interviews? Because you think about journalists and things like that. No, it was how to learn to talk to your customer, to really try to understand what he or she actually really wanted because they may come to you with a technology solution without knowing anything about technology.

Would it be the first time these days when I meet a customer who says, "What should I be doing with GenAI?" And then because you're really trained in trying to figure it out in depth, I apologize to answer your question with a question, but why are you asking me this? Most of this is fear of missing out. So really diving into it with the customer to understand what's the problem they want to solve, what's the opportunity that they see—all of that is communication.

Now let's move to the fourth quality of the Renaissance Developer: ownership. I've spoken about it before, but today I want to focus on one part of it—owning the quality of your software. AI will let us build bigger systems, explore more ideas, and move faster than ever before. These tools will help us build harder, better, faster, and stronger. And if we use these tools correctly, they can help us produce high-quality software. But there is a risk in how some developers are starting to use these tools.

AI-assisted coding is fine, but only if you pay close attention to what is being built. We can't just pull a lever on your IDE and hope that something good comes out. That's not software engineering—that's gambling. Remember what I said at the beginning: the work is yours, not the tools. If you're subject to regulatory requirements—say, healthcare or financial services—and I create code that suddenly violates a regulatory requirement, you can't go to the regulator and say you didn't know. It's still your responsibility. The work is yours, not that of the tools.

Now, the other side is changing. You will write less code because generation is so fast. You will review more code because understanding it takes time. When you write the code yourself, comprehension comes with the act of creation. When the machine writes it, you will have to rebuild that comprehension during review. That's what's called verification debt, and it's one of the two main challenges I hear when I speak with developers about this new style of work.

AI can generate code faster than you can understand it. Code arrives instantly, but comprehension does not. That gap allows software to move toward production before anyone has truly validated what it actually does. The second challenge, of course, is hallucination. The model produces designs that look confident but are completely wrong for the architecture. Some APIs change, and LLMs invent attributes that do not exist. Sometimes they propose solutions that are completely inappropriate, overengineered, or ignore your system's own patterns. These outputs look plausible but are not grounded in reality.

I think we're making progress. We're developing practices like spec-driven development, which can dramatically improve quality. Tools like Kiro can use automated reasoning with your specification to create code that is verified. We can also use automated reasoning to ensure that code generated against AWS APIs is correct. I also see many developers looking at their CI/CD pipelines and building more and more automated testing. These are all types of mechanisms. I want to make a distinction here. I want you to really understand these two things: there are mechanisms, and there are good intentions. They're not the same. Let me illustrate that by going back a little bit in the past and telling you a story about Jeff Bezos.

In the early days of Amazon, these executives were required each year to spend two days with customer service and take calls from customers so that we would truly understand what the customers were going through. Not just us lowly executives, but Jeff himself as well. So Jeff sits next to this customer service agent, the phone goes, and the automated system already pulls up the order histories of this customer. Before the customer says anything, the customer service agent says to Jeff that the customer is going to return the table. Indeed, the customer wants to return the table because it's damaged. The call is over. Jeff looks at the agent and asks, "How did you know that?" She says, "Well, 70% of those tables are coming back because there's some dropshipper that doesn't really know how to package them properly."

Of course, Jeff gets everybody in the room and starts to think about how everybody has good intentions. Of course, we don't want this to happen. But without a mechanism, nothing changed because everybody already has good intentions. So he introduced a new mechanism, Amazon's version of Toyota's famous Andon Cord. In Toyota, the principle was that no car should leave the production line with a known defect. Any engineer working on the line could pull this cord and bring the whole manufacturing line to a standstill until the defect was fixed. The Andon Cord that the customer service agents got was a button to make the product unavailable. That made alarms go off to the people responsible for the polish to go and fix it. But before this, everybody already had good intentions. Until we introduced the mechanism, nothing changed.

Now let's go back to our technology world. Mechanisms take many forms. Each team builds their own one that fits the scale and nature of their work. The S3 team, for example, uses something which they call durability reviews. When an engineer proposes a change that might touch durability, they pause and model the risks. They write down the changes. They list every threat imaginable and map out the guardrails to keep the data safe. It's a mechanism with a very powerful effect. It turns durability from a property of code into the habit of the organization. It makes engineers think in failure modes, not happy paths. And it shows why mechanisms matter. They convert good intentions into consistent outcomes.

Now, if you think about it, code reviews are also a mechanism, and I know we all hate code reviews. It's like being twelve years old and standing in front of the class. But they're a very important mechanism because they create a moment where intent and implementation meet. Another engineer can question assumptions and catch things that the author no longer sees. In an AI-driven world, they matter more than ever. In an AI-driven world, they are crucial. Models can generate code faster than we can understand it. So the review becomes the control point to restore balance. It is where we bring human judgment back into the loop and make sure that the software actually does what we expect it to do.

I encourage all of you to continue and increase your human-to-human code reviews. When senior engineers work through code together, it becomes one of the most effective learning mechanisms we have. Seniors bring pattern recognition and hard-earned judgment. Juniors bring fresh eyes and often spot details others overlook. This is how we transfer knowledge and how we grow the next generation of builders. AI will change many things, but the craft is still learned person to person.

The Fifth Quality: Becoming a Polymath—From I-Shaped to T-Shaped Developers

The fourth quality of the Renaissance Developer, in my eyes, is that you are an owner. You build it, you own it. The last quality I want to talk to you about is that I think you, the future Renaissance developers, need to become a polymath. Now, polymath has nothing to do with math, by the way. It's not mathematics or maths or whatever you want to call it. The word polymath actually comes from the Greek word "mathein," which means to learn. It's about having deep domain experience, but also having knowledge that spans many different subjects.

Da Vinci probably was the absolute best example of a polymath because he worked across so many different disciplines. He was a painter, an engineer, an anatomist, and an inventor. I do not expect you all to become a da Vinci, but you should expand your knowledge beyond deep domain expertise. This is what I would call an I-shaped developer. An I-shaped developer is someone who is really deep and really highly specialized in one area.

Let me tell you an interesting story from my own experience. This is my old mentor and friend Jim Gray, and Jim got the Turing Award because he's the inventor of transactions. Every transaction you do today, we have Jim to thank for this. But he also had this great mind and was interested in so many more things than just databases. One of his famous challenges was: give me twenty important questions that you want to ask of your data, and I will design the system for you.

One of the first projects he worked on was the Sloan Digital Sky Survey. This was one of the first massive datasets that were out there and groundbreaking work in developing the sky survey. Jim's in-depth knowledge as a database expert was transformative for computation in astronomy data. There's actually a really funny story about that. At some point, Jim goes to Baltimore, where the group is, and he walks into the server room. Thirty seconds later, he walks out and tells them that the database layout is wrong. Everybody looks at him and says, how do you know that? By just listening to the rattling of the disks, he knew that there was way too much random access. This intuition, built from decades of experience, had given him a sixth sense of how systems should behave. He advised them to redesign the architecture, and performance improved dramatically.

Jim wasn't what I would call an I-shaped developer at all. His curiosity reached far beyond databases. He understood people, he understood business, and he understood a wide range of technologies. Like great technologists, I would describe him as T-shaped: deep in one domain, but broad in understanding. The skills you need to be successful in your job are a unique mix of personal skills, functional depth, and industry knowledge. A database developer who understands front-end performance or cost where architectures can make better architectural choices because they see how their work shapes the overall system.

That breadth of knowledge gives you the perspective to improve what you build because you understand the trade-offs. T-shaped developers combine depth with breadth. They can dive deep into specific problems but will also understand how it fits into a larger system. That is my advice to all of you: build both. Develop depth in your domain, but cultivate a range to connect to multiple disciplines and ideas.

So the last takeaway from the Renaissance Developer is to become a polymath. I don't expect you all to become that, but you should broaden your team. Great developers are T-shaped. They're experts in their field who understand their work fits into a larger system. You must broaden your team. Throughout this talk, I've called the Renaissance Developer different ways. I think you need to be curious and keep learning. Think in systems and communicate with precision. Be an owner. If you build it, you own it. Finally, become a polymath and expand your knowledge. Then you'll have plenty of time next week to start putting all of this into practice.

Pride in the Unseen Work: A Final Message on Professional Excellence

But for tonight, join me at the Las Vegas Festival Grounds. There will be great food, some crazy games, and of course, live music headlined by Beck and Kaskade. It's a chance to celebrate with your teams and unwind after a week of serious learning and building.

Now there's one more thing I want to leave you with this year. When you build something like an app, do your customers ever think about all the work that goes underneath there? An Amazon customer will click a button and a package arrives. Do they think about the people that actually maintain the catalog, that manage the supply chain, all of that work? Nobody sees that. Your customers are never going to tell you that. Your database engineers are doing amazing work and they love what they've done. Only you understand the work that goes into it.

I believe it is important for all of us to have pride in our work, in the unseen systems that stay up through the night, in clean deployments, the rollbacks that nobody notices. Most of what we build, nobody will ever see. The only reason we do this well is our own professional pride in operational excellence. That is what defines the best builders. They do things properly even when nobody is watching. When I look at the work that you deliver every day, I see that commitment everywhere. So for that, I am immensely proud of you. Thank you for all that you do.

---

; This article is entirely auto-generated using Amazon Bedrock.