Chief Technology Officer, Amazon
The Renaissance Builder | DLD26 (Werner Vogels)
In his lively DLD Munich 2026 talk, Amazon’s Chief Technology Officer Werner Vogels describes why we’re entering a new era of “Renaissance builders” – innovators and developers who blend curiosity, breadth, and depth to design for scale.
He argues that today’s tech landscape demands more than specialist expertise; engineers must be T‑shaped, meaning they have deep knowledge in one area but are also comfortable with others, like AI, cloud infrastructure, UI, and the business side of reliability.
Using vivid analogies – from the Renaissance printing press to Yellowstone’s wolf reintroduction...
About Werner Vogels
In a recent podcast marking the 20th anniversary of Amazon Web Services, Werner Vogels, Chief Technology Officer at Amazon, discussed the origins of the cloud computing platform and his early skepticism about the company. Vogels recounted initially ignoring a phone call from Amazon because he thought it was "just an online bookstore." He described his frustration with the traditional enterprise software model, stating that vendors were "always in charge" and that he "hated" the prepaid model. Vogels said AWS was created to "radically change the economic model" to a pay-as-you-go system, which he compared to paying for gas or electricity based on usage. Vogels also discussed AWS's approach to technology and sustainability. He stated that the predecessor to DynamoDB was driven by a desire to avoid using a "relational database for a problem that it was absolutely not built for." Regarding energy use, Vogels said that AWS matches 100% of its energy consumption with investments in renewable energy, adding that the company does this "because it's better for the world" rather than purely for shareholders. He emphasized that while AI can help write code, it cannot replace human qualities such as curiosity and the ability to understand the bigger picture.
Transcript (73 segments)
W
Werner Vogels0:00
So, if it needs to be wild, let's start off with some fun.
End of the developer. I've heard that before.
Heat. Heat.
Hi there, Lorraine.
L
Lorraine1:26
What you doing?
W
Werner Vogels1:27
Oh, you know, organizing yesterday's program cards, which got dropped, figuring out why the machine keeps stopping on card 4042, logging this really awkward bug at the Bow Gall compiler, and talking to you.
L
Lorraine1:42
Anything new at head office?
W
Werner Vogels1:47
I've been reading about this uh coal.
L
Lorraine1:53
Yes, it's the new high-level language.
W
Werner Vogels1:55
It's amazing. Now, anyone can write code.
L
Lorraine1:59
I don't know about anyone. Writing software is pretty tricky.
W
Werner Vogels2:04
Soft what?
L
Lorraine2:09
Software.
W
Werner Vogels2:11
Where?
Hey, Marty. What you reading?
M
Marty2:44
Just learning some VB.
W
Werner Vogels2:47
Visual programming, huh? Coding's history, Marty. Drag and drop is the future.
M
Marty2:54
Drag and drop is still code. It still has bugs and it still needs an engineer.
W
Werner Vogels3:06
Everything fails all the time.
Is this for real? Could cloud mean there will be less engineers?
Less engineers. Time for an airdrop.
Huh? Servers in minutes. Scale on demand. Pay as you go. Wow. You learn something new every day.
You build it. You win it.
Mom.
M
Mom4:18
Hi, sweetie. Don't forget to call mom.
W
Werner Vogels4:23
Hey there, Marty. It's a nice wormhole, isn't it? Mind if I join you?
M
Marty4:32
Oh, you can skip this one.
W
Werner Vogels4:44
Is this the end of development as we know it?
Or is it just another new beginning?
So, let's talk a bit about the elephant in the room. Is all this AI stuff. Did it take your job? Yeah, maybe. But will it make you obsolete? I don't think so. No, absolutely not. Actually, if you evolve, because I think there are some things that we really need to change in the way that we are running our jobs that you will need to evolve to. And I've called that the Renaissance developer or the Renaissance builder because I think that's really what we're thinking about.
Think about our tools that we've been using over time. IDEs, integrated development environments. If you look at the first ones, if you go all the way over here, amazing improvement in efficiency and the way that we build code and things like that, every step all the way. But no matter what tools you use, the work is still yours.
Imagine you work for maybe a financial services company and you're subject to all sorts of regulatory requirements. You have all this AI generating this code for you and imagine there's something in there that makes you no longer compliant and the regulator will point at you. You can't say oh yeah no doesn't work like that. All of the work is still yours. It's not the tools that actually own the work.
So I think we are really at an amazing point in time. I mean think there's a number of things coming together. I won't say space travel but you know space, AI, robotics, all of these things are coming together at a particular moment. And if we go back in history, there was a moment where there was also the case where all of these things came together and it was the Renaissance.
Yeah. Fortunately, the all Europeans here and they all know what the Renaissance is. You know, now actually you know for more than a thousand years the church had control over exactly what happened. The reason why there was no anatomy until the beginning of the Renaissance, nobody knew anything about anatomy because the church had forbidden to cut open dead bodies. And so there were tons of things that suddenly happened at the beginning of the Renaissance that drove tremendous innovation.
Suddenly, all the dark ages were behind and you know the black plague and if you know Monty Python then you know what happens during the black plague. Look at all of these amazing artists as philosophers. All of those came to life during this period and the tools they built they were amazing for those days.
This one I didn't know about this one myself. So the thing about the vanishing point in your drawings so that you can actually create depth in your drawing. If you look at the pictures and the paintings after the Renaissance, they all have light in them and they have depth in them. All of those were actually developed during the Renaissance.
The printing press was not just one innovation. Gutenberg needed to innovate a lot of things because actually he started off with a wine press. But he also had to invent what was called movable type, you know, little metal letters that you could put together. And then he had to invent ink that he could actually put on those letters and then printed on paper. Without actually ruining everything. So there's a ton of development things that were never done before.
Two Dutch inventions by the way. We're always good in looking into the distance. So the Renaissance man in those days is really I think has a number of attributes that we now also need to start to think about.
If I think about the first thing that you need to be and this is something that we've always had, Renaissance people were curious. They wanted to know things. And that was a joke of actually the little video up front to demonstrate that things continue to change over time because we are curious and curiosity leads to learning and to invention.
So being curious is one of the most important attributes. And it means that if you're curious you're going to experiment and something's not an experiment if you already know the outcome. So you must be willing to fail if you do these kind of experiments. And really it's actually crucial.
I think in quite a few companies if you run a project and it's not going the customers don't like it whatever and you want to stop that project but it hurts your career you won't or you will wait a long time before you pull the plug. If failing becomes a sort of a badge of honor, because you've learned all this because you failed and you share this learning, it actually allows you to experiment much more freely.
Actually, one of our customers, Enel, very large energy company in Italy, they have an internal TV station and they now have a program that is called my biggest failure on which program managers and developers come on to talk about the things that didn't go right, that didn't work. And I think that kind of drives experimentation.
There must be a willingness to fail if you want to be curious and if you want to experiment. It is a and I urge you to look up given that I only have 25 minutes I won't explain you what is this law is but it means that there is a certain amount of pressure that you need to actually be able to be successful as a builder.
And there's a great story on my blog by Andy Warfield about sort of that, you know, you need to be a little bit scared if you do these experiments. It needs to push you a little bit.
So, I think the curiosity and the improving skills continuously will really change. They will continue to change. So, the Renaissance builder is a curious person. And I love this old writ. Not what we know, but what we willing to learn. And learning is crucial.
And I don't know how many of you are or have been software developers at some time in your life, but software developers always need to learn. This is a job where you never stop. And that was what you saw in the little video up front. Every time there is something new and believe me now we have Gen AI there will be something else in two years three years from now and we're all thinking oh this is the next new thing. Remember we started off with LLMs and now we have reasoning LLMs and whatever the next Lab is and so these things will continue to go on.
There's Donna Tel Meadows described systems and I think her book was in the 70s more or less that you can't look at the system in parts. You need to look at the system both in parts but also as a whole because there's impact everywhere. And it's how all of these things work together. If you are a developer or a builder, it is no longer sufficient just to know your part. You actually have to know your part in the bigger picture.
This is a really absolutely amazing story. So at some moment, in the Yellowstone National Park, the elks are disappearing and so what do they decide to remove the wolves from the park? And the impact of that is actually a complete cascade because it turns out yes, the elk come back, but the vegetation changes and rivers are actually pushed to different directions. And all of these things are happening by removing one little part of the total ecosystem. Bringing the wolves back in actually restored the balance.
And so it is important to see your work not as just in as an isolated work but you're part of a bigger picture a bigger system and it is really important to realize what impact changes to your part has to the overall system. That's systems thinking. There is an amazing paper by her it's called the 12 intervention points in systems that actually really lays out these small little changes feedback loops positive negative feedback loops and things like that.
More and more communication will be important how to talk to your colleagues. But also remember that not only to your colleagues, it's also important to be able to talk to your colleagues, to your stakeholders, and to your customers.
When I went to school, I went to a very particular computer science school, and there was a class in there that was called interviewing. Why do we need to learn to talk to journalists and things like that. No, no, no. It's how to talk to customers because often customers come to you with really a sort of technology in mind. They already have a solution. But really diving into what is actually the problem that the customer wants to solve instead of the technology that he thought or she thinks you should be using.
Now, one of those communication things is, for example, this is supposed to be one of the Amazon screenshots. There's a few things at Amazon that always need to work. What is it? Search, browse, shopping cart, checkout, and reviews. Reviews don't work, people don't buy. And then there's a whole bunch of things that actually very useful for customers. Recommendations, personalization, things like that. And then there was the nice to have. Best seller lists or things like that.
So, we've put things into tiers. And then you go talk to the business and you ask the business, you know, how reliable does that need to be? Was that four 9s reliable? Three 9s? Two 9s? Because all of that a four 9s costs a lot more than three 9s and two 9s. So it is for engineers for example important to learn to communicate to the business and allow the business to make decisions about how reliable certain parts of the application needs to be instead of that the engineer decides that. Engineers shouldn't be making business decisions. Not in that way.
Now, this is how it used to be. I mean, we have as humans an amazing capability to deal with ambiguous conversations. We have context. We have non-verbal communication. And after all, this is not a Slack channel. You're sitting here listening to me. So, communication in that way, but it is ambiguous. Human to machine used to be precise. Programming languages exactly tell the machine what to do. And that's changing.
And yeah, this is one of those ambiguous. In this particular case, grandma goes on the grill and that's a nice family dinner. So, we know humans which one of those two we mean. Machines don't they don't have that context.
So what is happening now is that this is changing because now suddenly the building of the next level of applications with using AI technologies is also with ambiguous language and that actually has a lot of consequences.
And we're working really hard on trying to build things that sort of control the ambiguity of common language. I won't go into all of that. Spec development is where you basically up front you give a lot of sort of constraints basically context. Automatic reasoning is absolutely one of those areas that I think will play an important role into proving that the outcome of an LLM actually is true or not.
But more importantly, so you need to be a communicator in that world and you own it. You build it, you own it.
And I know all these tools, the famous philosophers of the early of this century, Daft Punk already said, you know, we can do it harder, better, faster, and stronger using all of these AI technologies. Yeah, I think and we call this VIP programming is like gambling.
Yeah, because these machines make mistakes. Who's going to check them for the mistakes? And yes, we can do that. And again, the work is yours. It's not the tools. You are the one responsible for the outcome of what these tools generate.
And the problem is that we can generate code so much faster. In the past, we would actually have a lot of reviews, but code is being generated so much faster that time to review runs behind it. You almost need more time to review the code than that you can actually create the code.
And this leads to two things at least. One of them is verification debt. And verification debt basically means that we've not verified what these machines have generated for us. It is absolutely crucial that we continue to do that. And of course, hallucinations is the other side. Remember LLMs are statistical words generators. They have no conscious. They just put the next word next to each other when it statistically looks good. They're not lying. They just don't know to say I don't know. And so those are the two things that we are building a lot of mechanisms around.
There's a great story. I think mechanisms. Oh, this January. How many of you have decided to lose weight? Okay. How many of you will still be doing that in February? Good intentions is what we all have. But we need mechanisms to actually if a personal trainer is appearing on your doorstep every Thursday morning, you're going that's a mechanism. And so for many of these things, mechanisms are crucial. Because we all have good intention, but we need to build mechanisms.
This is and I'm running a little bit out of time so sorry about that. Cool story. In the beginning of Amazon we were required every year two days to spend in customer service. Basically picking up the telephone listening to customers so that you would know what your customers were really experiencing. Jeff also had to do that. So he says that next to this customer service agent phone goes and before the customer has said anything the customer service agent already says she's going to return the table and then afterwards indeed and after Jeff says how did you know that well you know 70% of these tables are coming back and Jeff goes and why not we not doing anything about it well we have no mechanism to actually how to actually make this work.
And so, taking a step from Toyota, we built an andon cord. And that meant that the customer service agents now had a button to make a product unviable. That makes all sorts of alarms go off. That then fix it. It could be something like the disc is scratched, but it might also be the description says USB cable included and it's not the case. Boom. Push the button, somebody else goes to work. So mechanisms fix these things. Good intentions eventually. No.
So important in all of this is code reviews. There's things that these machines now generate for us. We still need to review that code. There's a lot of code to review. And I think human to human, if you put senior and junior engineers in the room of a code review, the junior engineers will learn things really quickly. Because there's this going back and forth in there. So, it is an important part of that.
As an owner, you build it, you own it. And you need to actually be polymath and has nothing to do with mouth by the way. Just being sure. It has to do with learning it. Basically, this is the prince of polymath Leonardo da Vinci.
And so what all of this is about is not I think that you should become a dilettante. However, you need to become broader. You have I-shaped people. That means I'm a database expert and that's all I am. Or I'm an accountant. And you're a deep specialist. You're really, really, really, really good at that.
But what's crucial in a modern society is that you go to T-shaped model. And T means that you need more breadth. Yes, you can still be that very specialized database expert, but you also need to know a little bit about the AI, little bit about what is it UIs and things like that. Really T-shaped is actually crucial.
And there's many different skills in all of that. But to survive in a modern world, we'll need to go from highly specialized, remember there is still this part in the team, but you also need to be broader. You need to understand the bigger picture.
So broaden your team.
So these things I think are crucial for anyone that is actually in a new world that is driven by AI. Curious because you need to learn. By the way we've been always been doing that. That was the importance of the video up front. This is something we've been doing forever. Going from one programming language to another one to from one IDE to the next IDE. And all these technologies happens all the time. Don't think in parts. Clear communication between not only you but not the people next to you but to many different stakeholders. And no matter what, the work is yours not that of the tools.
So we can talk about AI all we want but it's our responsibility what comes out of that. So sorry for running over time a little bit but just keep calm and go build.