Werner Vogels predicts the future | Amazon CTO on robot companionship, quantum-safe computing, more!

Coolish. Yeah, engineering has come a long way since. I think the first NoSQL tools were really the first tools. Now if you look at DynamoDB, if you look at these, they are super robust, highly scalable tools where everybody can build a business on. Come a long way.

So first of all, it's 21 years now, so that's a bit. And there is a predecessor to DynamoDB, it's Dynamo. One of the things when I joined Amazon, I joined as what was called a Director of Systems Research. The idea was to bring, let me go a little bit back. Think about 1994. When Jeff Bezos starts thinking about the internet and he starts a bookshop. He doesn't really want to start a bookshop. He's just fascinated by the internet. What are the things that you can do online that you will never be able to do in real life? And he just picks a bookshop. A good bookshop has 40,000 titles in stock. Yet there's millions of books out there. So he thinks you could do that online. But there is no software that you can buy. There is no book that says 'here is an e-commerce operation.' The word e-commerce doesn't exist yet. So everything that the Amazon engineers had to do to build Amazon was to invent everything themselves. Because the kind of technology that they could buy couldn't operate at their scale. We've had a number of blowups because of that. So when I joined Amazon, engineers at Amazon were brilliant at scaling but from a practical, lots of scars kind of approach. And Jeff hoped that by bringing a former academic in, you get some more robustness, a better fundamental approach to scale and reliability. And we did lots of large projects around removing all single points of failure or how to best measure. What does it mean to measure? If 50% latency on your web page means nothing. Well, it means that 50% of your customers are getting a worse experience. You need to know how much worse. So, I think if I think about CTOs, there's four or five different types and there's no real well-developed, well-described one. First of all, there's the data center manager who reports up to the CIO. You have the CTO that is the second person in the startup, often the co-founder, the first coder. And then you have the big thinker, the role that I got when I came into Amazon, sort of like look at the whole picture, what are the kind of things we need to do. But then when we started doing AWS, your world changes. You go from an internal focused CTO to an external focused CTO. Scott Dietzen, who was at BEA I think at that time, he called it really an external technologist. The ability to talk to your customers, look at how they are using my products, and what are the problems that I see with 10, 20 of my customers that they may not see as a single problem themselves, but where you can find if I can build a tool for that, I can really help my customers. So your role changes from being purely internal to being external and bringing back things. Then over time, I've become more and more interested in those organizations, both profit and nonprofit, that try to solve hard problems. With hard problems, I mean hard human problems. The United Nations expects that by 2050 we have two billion more people. How are we going to feed them? How are you going to make sure they have an economic future? How are you going to make sure they have health care? Those kind of problems are the ones that I mostly focus on today. On one hand, by the way that we build technology at Amazon, but also by looking for those often young businesses and how can we support them. Take for example the Ocean Cleanup project. It's a massive problem. The grand ocean garbage patch is full of fish nets and plastics. There's about 30 rivers that sort of contribute mostly to that. So these guys have built plastic with GPS in them, threw them in the river to see where they end up, or they have these AI cameras on boats to sort of first where do these boats go, but secondly also what are the things that they're seeing. Working with those kind of customers is extremely satisfying because we are solving actual real human problems. We're not building spam filters.

There's a long history by large technology companies, if you think about IBM, Oracle, or McKinsey, the consulting companies, of predicting the future. And always when I read them, I always felt that they were a bit self-serving. And the things that I saw in the real world were different. I see significant human problems, some of them are our own nature, but quite a few are caused by technology or the way that we use technology. There's a leadership principle at Amazon: with success and scale comes broad responsibility. That means you don't only have a responsibility towards your shareholders to make money. You also need to serve your customers. At AWS, of course, that is builders. How can we help builders best? Then I write these predictions about things I see around me. I have the fortune to travel the world. I was just in spring in Sub-Saharan Africa: Nigeria, Rwanda, Kenya. In Kenya, we were in Nairobi. Of course you stay in the center of Nairobi, beautiful buildings. You drive 15 minutes and you see how the real Kenyans live. Most of them are day laborers. They go to the bank, they get $2, they try to buy something, they try to sell it, they bring the $2 back and hope to have 40 cents left to buy food. They probably have that, but then they don't have money left to cook it. Why? Because these big butane canisters cost $10 and they don't have $10. There's a young company called Koko Networks that built a sort of ATM where you can go with a canister, plop it in, and get 15 cents of gas. Then you can take that home and cook your food. This is not a world-shocking problem, but it is solving really hard problems that people have. Those kind of companies and those kind of problems are often the things that I like to serve through the predictions. This year, I do think there are things every year. I could have done 10 predictions, but five works fairly well. Three is a magic number, five is better. Was it two years ago? A topic that has become more and more openly discussable is menopause for women. It's a major problem for them, but even mothers don't talk to their daughters about it. However, that is slowly changing. What kind of things do we see in the startup community that are trying to build technology products or medicine to solve those kind of problems? So I also try to talk a little bit about things that people normally find a bit harder to talk about.

Well, it's one of these problems. I did this documentary series called 'Now Go Build' TV series probably two or three years ago. I was in Japan for that, and that's where I first really dove deep in this particular topic. Japan is a society where kids take care of the elderly. The grandparents live with the grandkids and the kids, and that was normal. But the younger kids want to start making careers, and there is a clear shift in Japanese society happening where the elderly are no longer taken care of by the younger people. As such, that's a shocker not for the young kids, it's a shocker for the old people. They're really on their own. I think there are a lot of technology solutions possible to help these people. Loneliness is something we'll get to, but anything we can do as technologists to keep people longer out of hospitals or care homes, the better it is. If that means a company in Japan that I met called ZWorks, they try to do all these innovations around elderly people to help them. Make a sensitivity pad in your mattress, and maybe in the middle of the night you go to the toilet and you don't come back within 15 minutes, the alarm goes off. This doesn't seem like world-shocking revolutions, but it does mean that people can stay independent longer. They don't feel that old. More and more people becoming 100 years old is actually not that strange anymore. Many of these people may have lost their partner, or live far away from family. Especially in the US, after high school you probably move away from where you grew up. You go to college somewhere in upstate New York, you go to work in California, and people are not close anymore. That truly is a loneliness epidemic. So what can we do? I love the work that is happening around companion robots. Why? Because I always thought that people would treat a robot like a piece of metal mechanics. Turns out it's not at all the case. They treat them like pets. Kate Darling at MIT has done all the research around this. I can tell you absolutely amazing stories about how people get attached to their devices. The story I think is also in the predictions: 80% of the people that have a Roomba have given it a name. One of the stories that Roomba tells: someone sent an old Roomba back because it needed to be repaired, and they looked at it and told the customer, 'We'll just give you a new one.' And they said, 'No, no, no, we want Mur back.' They want the old one because they're attached to it. Or Kate tells this story where she divides two groups of people and each gets a baby dinosaur. They really fall in love with it, give it a name, play with it. Then she gives them a hammer and tells them, 'Kill the dinosaur.' Nobody in the group will take the hammer and kill the dinosaur. They have no problem going to the other group and killing their dinosaur. Why do I tell these stories? Because while these things are technology, we treat them as living beings. Especially, before I was in computer science I was in healthcare. The application of these kind of tools in hospitals is incredible. If you're a young kid, a doctor is someone that is tall and dangerous or whatever you want to think. But for example, there's the Huggable robot, a small green thing with a nice snout that talks to the kid. Kids with a Huggable have no problem talking to a doctor because they have their mate with them. Those kind of things are crucial for us as technologists to think about. We see a problem, not necessarily a problem that is going to make us a ton of money, but a problem that is really important for people's psyche, for people's feelings, for loneliness. Who wants to be lonely? Nobody. If we can't do this through pure social interaction, what's the next best thing? Amazon has Astro, but there are more robots like Astro that will go search for you through the house and ask you if you've taken your medicine. In families or people that have these kind of robots, their medicine taking goes up 80% because they're being continuously reminded. Early on when we launched Alexa, I got a story from a man who was suffering from early dementia. He knew what was coming. The only thing he had to do was put a post-it note on the device saying 'It's called Alexa.' Because one of the things he noticed was that during the day his caregivers were getting more and more irritated with him because he would ask the same thing over and over again: 'What day is it today?' Because he had completely forgotten. The thing with that voice assistant was that you could ask it the same thing over and over again and it would never get angry. It would always be happy and always give the same answer. So there are technologies that we can develop to help people have a good life. If you can do that, spam filters are fine.

Well, I don't think it's an end to loneliness. It is an assistant. That's an antidote. People are still lonely. I have seen elderly ladies with a fake cat next to them stroking the cat, and the cat meows, and the old elderly lady is extremely happy about that. So why not? The fact that we have had a phase in our existence where we think all relationships need to be human to human, well maybe not. Maybe there is more to that, especially because we are getting older. Look at all the baby boomers. Everybody over 65 or over 70. There's a very large group of people that is growing older and older. They come with a new set of problems. Can we solve those as technologists? Can we make a contribution to that? That would be great because building technology is cool, but helping people is much better than that.

Well, I do think the most important thing is that I don't necessarily want to put a timeline on it. I think in the past two years ago or three years ago, I think I said 5 to 10. I think five is now more realistic. But I've seen a number of problems arising that I think we need to be aware of and take action on before that. It's not about... We have the AWS Center for Quantum Computing together with Caltech, an institute about quantum. I see different institutions making massive progress in terms of error correction networks, things like that that actually make me believe that it's no longer a vision. It's an execution now. It becomes an iterative process in improving the technology that we have created step by step until it becomes workable. There is a ton of other problems to solve: how do you program these beasts? How do you do that with something that is not necessarily 100% reliable? There's a ton of things that still have to be solved before we have production quantum machinery. But one of the things these things will do is solve existing problems much faster. There are things that would now take a thousand years in compute that will then take a year or six months or two months. The one thing that they will be able to do really, really fast is decrypt. Anything that is elliptic or the usual RSA encrypted kind of things that are perfectly fine now because it will take way too long to decrypt, will then be decrypted with a snap of your fingers. The reason for the prediction is to put in people's minds that we need to start taking action now if we want to be protected five years from now from the ability to decrypt anything that we have now. All the hyperscalers—Google, Microsoft, Amazon—we have all been building post-quantum cryptography. We've been inserting that into our front end. Unfortunately, we're not the only players in this world. There are lots of people with their own data centers, with their colos, that will have a hard time protecting themselves. So really getting it into people's minds that they have to start taking action now if you want to be safe a number of years from now when these things become reality. The other thing is that you can't just lean back right now because a lot of the data stealing is basically data harvesting. Nobody is interested in encrypted data being retrieved; they'll wait till the machinery is there to be able to decrypt. Your medical data now will be decryptable in a few years from now. I don't necessarily mean script kiddies, it's really state actors or commercial actors who are interested in that kind of data even if it's five years old and might have all the relevant data for them to take action on. That's the scary part.

There are of course different types of encryption. You have lattice-based encryption, so there are types of encryption that you will be safe from this type of decryption, but you need to start installing that now. OpenSSL was 500, 600,000 lines of code. You can imagine that because it had all sorts of different types of encryption units. At some moment, we realized at Amazon that running all of our content with OpenSSL was a major vulnerability. So we reimplemented TLS with a limited set of encryption technologies and just put that in front of S3 for example. First of all, much cheaper, but we made it open source and we made sure that it is fast and inspectable and more importantly written in a way that we can use automatic reasoning to see whether or not we're protecting ourselves. The most important part: you hear more and more about automatic reasoning. People like Byron Cook have been working at Amazon for the past 15 years on these kind of problems, proving to ourselves that we are protecting our customers. That's not a press release that is going out, but there are technologies that you can use to prove to yourself now. The open source project originally called s2n was purely intended to get post-quantum encryption in the hands of everyone. Now I told you, you got scared about the data harvesting. Let me scare you a little bit more. Probably every one of your home devices hasn't been updated for a number of years. They were Linux whatever version, no automatic updates. Your automatic garage door might have a little bit of encryption in it between the key and you. Think about hotel rooms: your key is an encryption encoder. There are so many small parts. Coming back to these house devices, I recently looked at how many devices were on the network in my house, and it was something like 56. There's your Sonos, your garage, your light opener, the thing that keeps track of this. Are all these things up to date? Are all these things protected? Are all these things up to new standards? We have a number of years to get this done, but we do need to start now.

First of all, there are a number of areas. There is just using newer encryption technologies, but you can imagine that some piece of data that you encrypted 15 years ago, you're not going to go through all of your data and re-encrypt it again. But are there gateway possibilities that protect you from that? Are there other ways? Let's use our inventive brains and find solutions to this, because I believe we can, but only if we make it a focus. The focus is not that quantum is five years away. The most important part is that we need to keep ourselves and our businesses safe. If that happened to be quantum or if it happened to be an alien spaceship that lands and suddenly turns out to be able to decrypt all our data, that doesn't really matter. We need to start protecting ourselves.

Do the work. Do the work. The same goes for everything now. Let me take a whole different example. When at Amazon S3 we went from eventual consistency to strong consistency, that was a major change that impacted every piece of technology. How can you make sure that you touched every edge of this particular problem? Because it is either 100% or not. Automatic reasoning plays a role in that: annotations plus other technologies that you have to prove to yourself that what you've built actually does exactly what you want it to do. Definitely automatic reasoning will continue to play a more and more role in giving us a secure feeling that we are on the right path. The same is for example we recently launched Q Developer, the spec-driven IDE with an AI system. We use automatic reasoning there to limit the number of hallucinations that can happen. Not that automatic reasoning knows terribly much more, but it knows that a squared plus b squared equals c squared is probably a triangle, and as such it knows all the triangles in the world. If then this LLM says this is a triangle, automatic reasoning will say no that is not a triangle. That's just a simple example, but we start building more and more technologies to prove to ourselves that we are doing the right thing.

Yeah. Let me tell you what my first programming languages were at school: COBOL, 68000 assembler, and Pascal. None of these programming languages does anybody write anything anymore. Although maybe I could make money as a COBOL programmer, I'm not too sure I'm doing well in 68000 anymore. But things change over time and we as humans adapt. We're often ahead of the game. We went from things like Pascal, which was probably the first version of a little bit of structured programming, to C++ and Java and Python and this whole world, and none of us panicked there. We just learned a new programming language. It's not like we're suddenly frozen in our chair. Now we have AI tools to help us build the systems that we do. Why should we start to be scared suddenly? Why should we suddenly become... we just learn to use new tools. Because remember, it's you that builds, not the tools. It's also you that owns it, not the tools. If the tool has built something and you're in a financial company that suddenly no longer makes you compliant, it's pretty hard to say to the regulator, 'Oh that was the AI, that was the tool.' No, no, no, it's still your responsibility. As such, no matter how good tools we build, we still need to educate ourselves, we need to continue to keep ourselves on a path of education, learning, continuing to learn. Looking at you too, you're not the youngest. I'm pretty sure that before you wrote something in Python, you wrote something in C++ or in ABC. My favorite being Rust at the moment, but there will be something else after Rust. We won't panic suddenly thinking that the world will collapse and all our jobs are going to go away. No, we make sure that we educate ourselves. Crucial in all of that is curiosity. If you just want to lean back and write some code and don't want to learn the next language, then probably you've always been in trouble, that has nothing to do with AI. You have to because curiosity leads to learning, and those two things are... remain curious. Have you guys seen Ted Lasso? There is this brilliant darts scene where he throws 170 and he tells this story that he saw this quote by Walt Whitman painted on the wall: 'Be curious, not judgmental.' I like that. He said, 'I suddenly realized that nobody had been curious in who I was. They were just bullying me because they could.' Curiosity is such an important part. Being curious about AI, being curious about quantum, be curious about how defense technology actually transforms into civil technology. If you're curious, you'll find out. I think if you look at young kids, they're massively curious until we send them to school. Then we make them conform to one standard. They all need to become the same regardless of their mentality, regardless of their level of interest. I think everybody has the ability to become special. I think one of the tenants, given that we have the Renaissance developer as one of the points in there, the core of Renaissance humanism was the belief that humans are limitless in the capability of invention as long as they keep their curiosity alive. The moment they're no longer curious, they'll lean back and it's over. I believe that we are limited in the capability of inventing new things if we're not allowed to.

But also even just learning maths. I have two daughters, they're now close to their 40s. Don't tell them that. One of the things, I'm not American, I come from the Netherlands where high school has 10 different forms depending on what you go to school to become: a welder or to go to university, and there's a whole range in between. Then they come to the US and the kids have to go to the same high school, take the same classes, score good in the same classes. When one of my daughters first got into math class, there were four guys in the back of the room that were four years older than she was, still had failed maths every time, but had to still sit in that class. Disruptive. I've always been a real fan of Ken Robinson, a professor from the UK that moved to Los Angeles at some moment. He really looked at that instead of letting our kids bloom and explore and become what they can become, we turn them into factory workers all doing the same thing. That kills all the possibility in what these kids have in them.

I think there are enough companies working on them, but what I see more and more is that these kids are doing it themselves. Gen Alpha, the current kids that are in high school or going to high school, they really know how to use AI or AI assistants and they know how to make a curriculum for themselves. They know how to make something from which they can learn. That is really a tool for them to build something that they just want to do. It helps them build things without having to go through a complete textbook first. I still believe that you need to be able to do maths before you should be allowed to use a calculator. That seems like a reasonable kind of thing. But if you're really interested in how in the 1600s in Italy from small states this became one country for some reason, kids have immense curiosity in anything. You can build yourself a curriculum that you become not an expert but that you know everything about it. Suddenly you have control over that. There's always two sides to this. The other side is something from Ken Robinson again: he says there are no good schools, there are only good teachers. What do most teachers spend their time on? Grading homework, doing administration, all these kind of things that actually have nothing to do with education. That seems to me like a standard technology solution problem. Whether you solve that with AI or with some simple SQL, that doesn't really matter. I believe there should be a lot more support for teachers such that they can focus on things that are important: individual interaction between a teacher and a student has so much more impact than the teacher standing in front of the class. Ken Robinson tells this wonderful story: he's a teacher giving a drawing lesson, and there's always this one girl in the back of the class that is never interested in anything, but now in the drawing lesson she's fanatic. So he goes to the back of the class and looks at what she's doing. He says, 'What's she doing?' And she says, 'I'm drawing God.' He says, 'But nobody knows how God looks like.' And she looks at him and says, 'But in a minute they will.' That's fine. Here's a blank paper, why don't you draw God? This is a kid. There are no boundaries to your curiosity and to what you can do. All these things that these kids feel as constraints are put upon them.

This just-in-time learning is really fascinating. You must have been to some tech conference at some moment where someone describes something about a new cache algorithm. You look at that and think that shouldn't work. At Amazon we have something called the Builders Library that's available for everyone to look at. These are articles written by Amazon's most senior engineers. There is this one article by Colm that I couldn't get my head around because I've grown up in a time that you minimize the number of bytes on the wire. One more byte means more time, more delay. That's no longer the case. He describes this system in which if the receiver always has to do exactly the same number of things because there are 10 things in this packet but eight of them may be empty, but everything is standardized and you don't need to think about it and the resilience grows up. It took me a long time to get my head around that. But the first time I read the intro to the story, it immediately picked my curiosity. It took me a long time to learn what he really tried to achieve there. No matter how old we are, there are moments every time when you get sort of 'Oh, how would that be?' I live here in a place where there are a lot of electric scooters, the ones that Lime that Uber bought and others. I've always seen them, but I was always curious how it would be to ride one. Now it's just a click on your phone and you jump on it and go to the supermarket to buy your groceries and come back. It's just fun. Curiosity is really one of the most amazing things that is uplifting in our life.

I do think if your job was only being a code monkey, just tapping, all you do is code, you don't think, you don't plan. If that would be... but I think most of us have had to think about some of the stuff that we built. We had to think about algorithms, tradeoffs. You went over to your colleague on the other side and said, 'This is what I need to solve here, but I think there's a cache out for if that happens and that will brown out, then do you think that too? Shall we set up a test environment and see whether that works or not?' There are so many parts to development that will require our brains. That's why I picked the word Renaissance. Before the Renaissance there were the Dark Ages: a thousand years of the Black Death, the plague, everything ordered by religious institutions. That changed at some moment where people became interested again in all the amazing things that had been done a thousand years before by the Arabs, the Romans, the Greeks. They suddenly completely started to change. There is this word associated with the Renaissance: polymath. Many people think that's someone who can do mathematics in many different forms. No, 'poly' means many, and 'mathia' means learning, much to learn. If you look at the people in those days, they suddenly started to become interested in many more things than just the one thing they were specialized in. Da Vinci was not just a sculptor, he built airplanes. Well, they didn't fly, but he did build them. Think about all the people in those days that suddenly allowed their curiosity to come out. As developers, there are a number of things we will encounter. First of all, we've been learning for 60 years now how to do computer science. We've been learning programming languages for 60 years, going from mainframes to minis to PCs to cloud to whatever. Everything required a new approach to building or enabled us to do new things. Before cloud, you may have only had one colo and never would be able to build a replicated database, but then cloud came and suddenly you could replicate your database. You need to learn how to do that. I believe it's not just sufficient to... and now I need to be careful because I don't want to give away too much of my keynote. I believe to be successful not only now, not only in the future but also now, is to not only have a deep specialism but start to become interested in the broadness as well. It's called a T-shaped developer. Someone that is not just a database expert, but knows about other types of applications, other programming languages, may even be able to help his colleagues on the other side or at least can have a conversation about it, understands the business principles of the business that he's actually running. Another area that the newer type of developer, the Renaissance developer, needs to be is an excellent communicator. If you look at the Amazon website, just imagine that for you. There are some parts of the Amazon website that always need to work because otherwise we can't sell anything: browse, search, shopping cart, checkout, and reviews because if there are no reviews people don't buy things. Five things that absolutely need to work. Then we have all the other things that are really important as well: recommendations, personalization. Then there is stuff that is just nice to have, like best lists. As a technologist, you need to be able to have a conversation with the business and say, 'How many nines do you want behind that? Oh, you want four nines behind your bestseller list? That's going to cost you so much.' Then it becomes a business decision how I am going to implement this. But I need to be able to explain to the business what the risks are, what the costs are, how resilient can I make this. Without that kind of communication, you're not building the things that you want for your customers. An important part of the Renaissance developer is to be able to communicate in exactly the right way, not only to the business but also with your customers. What are you building? How does this interact with this? If I show you a picture of the thousands of microservices that build out Amazon.com, if I do something here, what's happening there? Is there a relationship between the two? System thinking becomes crucial as well. Not just about your little piece that you're building, but what impact does that have on other things. You're happy going away, your database is running, your code is running, transactions are playing through. Suddenly the number of transactions doubles, but there isn't a doubling of the number of customers on the website. Who the hell is doing this to me? Being a specialist in one particular area and just staying there is safe, is fine. But you live in a bigger system. That really comes out of Donella Meadows' work on system thinking. In nature, if you remove one piece out of the equation of the complete nature equation, you ruin the overall thing. At some moment in Yellowstone Park, there were too many wolves. They removed the wolves from the park because they were killing all the elks. Then the number of elks grew like mad, which started eating all sorts of parts of Yellowstone. Not until they reintroduced the wolves did the balance get back. So system thinking is something that we as the future Renaissance engineers need to be part of as well. We need to understand that the one thing we're working on at this moment has impact on all the other pieces around it. We need to be able to communicate with the others, to see how we are part of this bigger problem. And it will be fun. One of the things I always found less interesting in the beginning of my life as a developer were code reviews. It's a bit like standing in front of the class and the whole class gets a chance to say you're an idiot. But code reviews are fun. Sometimes you think there are mistakes, sometimes you go 'wow, that's an elegant solution, I wish I had thought about that.' Code reviews are super important for junior engineers because the senior engineers are in the room discussing the code on the screen, and you're learning on the spot from all their years of experience. Someone will say, 'Yeah, I tried that when we were building product X, Y, or Z, and it really didn't work then, or the problem at that time was something.' Whether the code on the screen is generated by you or by some AI agent doesn't really matter. We still need to do code reviews because we have ownership. Whether we used a tool to create the code that we're looking at or whether we actually wrote it ourselves, we're still responsible for it. We still own it. Those things don't go away. If your system has been created by one of the AI tools, as I said earlier, you are responsible for it. Especially if you're in life sciences, healthcare, financial services, you cannot only rely on the fact that 'oh but AI built it.' You are still responsible for what you deliver. That means you need to be able to look at it. Generation of code may go faster, reviews will probably go slower because this is not code that I've written. If it's my code, I can stand up in front of the class and say, 'This is why I did this and this is why I did that.' But if a completely unknown, non-human entity created this code for you, it takes longer to get used to it. That's not bad. Don't take this as that I'm cracking on AI. There are parts that will never leave us. We need to learn the next steps. We continue to keep ownership of what we do. We continue to need to learn the next language, the next tool, the next system that we build. We need to know more than just that one piece. We need to be more than that. My favorite, and he comes back in almost every presentation that I give, was Jim Gray. He won the Turing Award. He's the guy that actually built System R at IBM, the inventor of transactions. Jim was brilliant. There's an article if you want to look it up called '20 Questions to Jim Gray.' Jim said, 'Give me 20 business questions that you as a user of a database would want the database to answer. I will build a database for you.' One of the most interesting questions: he walks into the room where the big machinery is and he hears the disks rattling. He looks sideways and listens to the disk and says, 'Your database layout is wrong.' That was something he could hear. But he was not just a database expert. He had a lot of other skills in other areas. He was what we would call a T-shaped developer. An I-shaped developer is someone that knows only one thing. A T-shaped developer has a number of knowledges in other areas, whether it's computer science or from the world. It's a broader person than just only the database developer. In the future, this is something that we will continue to harness. You need to know more. You need to be able to communicate with your colleagues that built other parts of the system if you actually don't know anything about what and how they're doing it.

I'm getting old. I just had a great answer to what you wanted to do and I completely lost it. I do think that we've changed over time as developers. I've written VB, I think there's nobody that writes Visual Basic anymore. Is there? Not on purpose. Fix a bug maybe in legacy code if it's still there. But it was fun when we were doing it. I wasn't thinking about five databases replicated over five different data centers throughout the world at that particular moment. I was trying to fix my Excel code. We've all grown as developers over the past 10, 15, 20 years with all sorts of new tools. We have a new tool. There is one particular point that I have a small problem with: if you look at all the other tools that we've developed, we took some time to introduce them. We learned, we had people we told why we were building the tools, how we were building the tools, how they could best use them. The typical early adopter, then you had the chasm, then you had the early majority. It would take time, but you would learn, you would teach your users why and how that tool was there. With some of the current generative AI tools, they were just dumped in people's lap without telling them what it could do or what it couldn't do. There isn't almost a CIO that I meet today when I'm traveling that doesn't ask me, 'What should I be doing with AI?' I go, 'Well, my excuse is it's very inappropriate to answer a question with a question, but why are you asking me this?' They say, 'Those guys next door, they will be ahead of us.' I say, 'Are you really certain of that?' Then maybe because you're a little bit older, you start to dive down into what is actually the problem they're trying to solve with this technology, and is this the right technology for this? Every week we see five new models or 10 new models. Suddenly we went from regular LLMs to reasoning LLMs. I think as a business there is no shame in hitting the pause button for a moment and saying, 'Why don't we get ourselves educated about all of this?' Not just us as technologists, but also the business. At this moment, quite a few of our architectures are being determined by the media, not by us. That shouldn't be the case. We together with our business should determine how our architectures should look like, not because the newest thing. Of course, it's the task of the media to write negative headlines even when things are looking up. 'That company is massively behind that company.' You know what? AWS was never a consumer company. We don't build consumer products. We built tools such that you can build your chatbots. If AWS doesn't have a chatbot, it doesn't mean that we're out of business in AI. It just means it's not our business. That's really crucial in all of this: that we take time to learn the technologies, the capabilities of the technology, and where it can help us in our businesses. If we also give it to a whole bunch of Gen Alpha kids that can go do wild with it and build their own educational curriculum with them, great. Let them have it. It's a bit like us 50 years ago with hammer and nails building your own thing up in the tree. Now kids do different things. We need to give them the tools for it. But definitely in business, I think there is no shame in hitting the pause button and spending some time on education and making sure that you and your engineers are making the right decisions with the right tools. There is no hurry. No company will go out of business in the coming two months because they weren't using AI.

It's a bit like one of the other things. It didn't make it this time into the predictions, did it last year? One of the things that worries me is that parents driving in their car, the kids are in the back seat, they're getting, 'Dad, when are you getting home?' That was how we used to drive home. Now the kids get an iPad and become YouTube experts and they're quiet in the back, and the parents love it. But they set kids up from four or five years old to get dopamine reactions. They know how to manipulate YouTube continuously. Not only are they getting this dopamine high, there's something else called dopamine that removes your willpower. Whenever you stand at the bus stop next time, look at how many people pull their cell phone out. Even if they know that the bus is three minutes away, nobody wants to be bored anymore. Nobody wants to just stare out in the distance and use their brains. We can't help ourselves because we've ruined ourselves. If we do this with our young kids, we will have an epidemic on our hands 10, 15 years from now in terms of addiction. Sorry guys, I keep yapping.

Okay. Well, I really enjoyed it, guys. Come and watch my keynote, the last keynote at re:Invent. I'm doing the 3:30 on Friday and Thursday. So after me, everybody can go do whatever they want.

I am the closer.

Yes. Okay. Bye-bye.