【十字路口】对话 Jeff Barr：AI、云计算、恐惧、保持年轻【视频播客】

The very first spreadsheet was called VisiCalc, which was invented I think in 1979, 1980.

50 years ago. In 2004, you started to write blogs. So back then, I believe a B2B tech blog was a radical idea. How did you convince the whole team to embrace it?

1.5 million words and about 3,300-

Wow, that's a lot

... so it was such a amazing 20 years. But I didn't think of that as the important part. To me, the important part is I got to help bring so many services out to the world.

Wow.

I got to light that fire in the minds of developers.

What was the company like back then? And looking at AWS's incredible journey, what has surprised you the most?

And for the first time, someone who's not really a programmer can go and they can set up effectively business calculations. Kiro is an AI-powered development tool to think big thoughts and to dream big dreams.

Hi, Jeff. Welcome to the show. So today is a truly special episode, not only because we have a very special guest, but also because this conversation will be in English. We are thrilled to welcome Jeff Barr, the chief evangelist of AWS.

I'm super happy to be here and to be your guest.

Jeff has been working in the technology industry since he was, like, 16 years old.

16 years old.

Wow. In 2002, he joined Amazon, and it was two years before the official launch of AWS. And Jeff is one of the key figures in the founding story of AWS, and he has played an essential role in shaping many of its cornerstone products, including EC2, S3, Bedrock, and so on.

He's also the principal author of the AWS blog, where he has been writing and publishing technical blogs for over 20 years, helping countless developers and businesses around the world understand and adopt cloud technology. Welcome, Jeff. We're so happy to have you on the show.

I'm looking forward to having a great conversation today.

You joined Amazon in 2002, before AWS was born. What was the company like back then? And looking at AWS's incredible journey, what has surprised you the most?

Let's see. So I joined Amazon in 2002, right after we had launched our very, very first web service product.

Wow.

And this was long before AWS was even an idea. But we had built these, these relatively simple services that gave developers access to the Amazon product catalog, and I had done some consulting work and some other kinds of work in the, the very early web services business, back in the days of XML and SOAP and WSDL, all these kind of obsolete protocols that were very-

Wow

... popular 20-plus years ago. And so I saw this very, very first service that we built, and I immediately had this great thought that maybe Amazon would be a good company to work for. I joined as a development manager, and I was actually responsible for, for this...

basically this kind of, kind of an accounting system that was written in, in Perl.

Mm-hmm.

But my manager also knew that I had an interest in web services, and so he gave me this little extra time allocation where he said, "Please go out and help the web services team in any way you'd like."

It was not specific at all. It was not-

Oh, it's very flexible

... it was no particular amount of time.

Mm-hmm.

No particular thing to do. He was so generous of him. He just said, "Go, go and help those guys out." It was literally, "Go and help those guys out." And so I helped to answer questions from customers, I helped to build some sample code.

And then at one point in time, the team came to me-

Mm-hmm

... and it was kind of one of these funny moments because I was just... I remember sitting at my desk and three or four members of this team came to me. They were all kind of standing around my desk, and it kind of felt like something bad was about to happen.

Okay.

And they said, "Well, Jeff, um, we're really kind of sorry, but you're the new guy, so we're gonna put this problem on you." And-

So what happened?

Well, they said, "Well, we have this conference, and we need someone to speak at the conference. None of us like to speak at conferences, so it's, it's your problem to do this." And I said, "Oh, I'm, I'm fine.

I love to speak at conferences. I will be happy to do that for you."

Wow.

And so they're... they thought they were giving me a problem, but they were actually giving me something I was really excited about.

Wow.

So I spoke at that first conference-

Uh-huh

... and I did a few more. And then they came to me and they said, "We have this new job that we're creating called the web services evangelist."

Mm-hmm.

"And we think you'd be a wonderful person for this job. Would you like to take this job?"

So before you, there is no evangelist job.

That's correct. So I was officially the first web service evangelist. This was sometime in early to the middle of 2003. So my initial job lasted about a year, maybe not even a year-

Wow

... before I took on that role of web services evangelist, and I gave myself a pretty simple definition. I said, "I'm going to understand all the different services that we build." I'm gonna understand them as deeply as I can, which we call dive deep in Amazon terms.

I'm gonna do a dive deep, and I'm gonna just go out and I'm gonna explain these to developers. I didn't make it very kind of conceptual or abstract in my description. It was just understand things and explain things.

Wow, that's cool.

And kept it really simple.

So the evangelist position, the job is, like, the very special in AWS. Is there any similar role back then at, like, Google, Microsoft?

There were a few evangelists back in that day around Microsoft, but I think each... The, the interesting thing about the role is that every person who has the role, we each get to be a little bit of an individual in it.

Mm-hmm.

There isn't really a standard set of activities or a standard job description.

Wow.

There are some people that are more toward the marketing side than the technical side. Some might be very business-focused. I decided I would bring my technical background.

Uh-huh.

I have a computer science degree-

Yeah

... and I earned my living building things with code for a long, long time.

Mm-hmm.

And I said, "I'm gonna take my technical background, which will give me this ability to understand things very deeply," you know-

Mm-hmm

... all the way down through all the different layers of the stack if I'd like to. But I, I really enjoy not just the understanding and the building, but I enjoy talking to developers, and I love to explain things to developers.

And I think of it as almost lighting a fire. I'm lighting this fire-

Uh-huh

... in a developer's mind-

Mm-hmm

... by saying, "Here's something new. It's really cool. Here are some capabilities it has. I think this might be something you find interesting and, and useful. Maybe you can do something amazing with this." And so very simple act of understanding and explaining-

Wow

... turns out you can actually make a whole career out of it.

Yeah, that's amazing.

Yeah.

So you enjoy this work all the long years.

It, it's so fun. It's so much fun-

Wow

... because I always have some new web service to explain. I always have something new effectively for my portfolio to talk about. But what is really awesome is I get to travel the world, and I get to speak to developers.

Mm-hmm.

And I get to speak to developers that are one or sometimes even two generations younger than I am.

Yeah.

And so there's a little bit of kind of this funny kind of age gap sometimes between me and them, but that makes it really interesting that I get to really actually keep myself young and current and get to really make sure I understand the youngest generation of developers.

In 2004, you started to write blogs, right? So back then, I believe a B2B tech blog was a radical idea. How did you convince the whole team to embrace it?

So it was actually really challenging, believe it or not.

Mm-hmm.

So as we started making the plans for AWS, I could see that we were setting up various teams, and I... for, for building, like S3 and EC2 and so forth. I could see those plans, but what I didn't really see a specific plan for was what we would call developer relations-

Uh-huh

... some kind of a marketing function that would go out to developers. So I wrote some plans to help us set up developer relations, and one of the pieces of the plan was to create a blog. And the challenge for the time for me and for the team was there wasn't any other kind of a blog I could point to and say, "I want to make something like this"-

Yeah

... "except for our products."

Understand.

So it took a little bit of work for me to really convince my teammates-

Mm-hmm

... and to convince management that this-

Mm-hmm

... would be the right thing to do.

So they thought it was risky?

There was a kind of a sense of a risk and an unknown because if we go back to that time, blogs were not usually technical.

Yeah.

They were more about a person and-

Uh-huh

... "Here's my life, and here's what I like, and here's what I don't like."

Yeah.

It was more kind of a, a self-expression.

A lifestyle.

It was more self-expression-

Mm-hmm

... than technical products.

Yeah.

So... and the interesting thing is I, I don't know that I had, like, a particular vision-

Mm-hmm

... of how I wanted that blog to be, other than that I wanted to do the same thing of the understanding and the explaining. And so ultimately, I, I put my first two blog posts online that were just like, "Here we are.

Welcome."

Mm-hmm.

And my first one about probably some service. I don't even r-remember what the second one was.

What was the feedback?

As soon as I put those first two, the feedback internally was, "We now understand what you're trying to tell us."

Cool.

But, but the great lesson there, I think, is sometimes doing versus talking about doing, the doing is the more important part. And actually just saying-

Mm-hmm

... "This is what I want to make," and, and making one is better than putting a lot of words and concepts around something-

Yeah

... because it's hard to convey the thoughts.

So the show, not tell.

Exactly right.

Yeah.

And so I started off very early making sure I always would put my personal touch on the blog and making sure-

Mm-hmm

... like, as we started launching services, I would always insist that the team would give me access to the service before we would launch, so I could use it myself. And I would never just write from the perspective of, "I heard something about this."

It's always, "I tried it out, and I used it myself-"

Mm-hmm.

"... and this is what I learned." And then with the idea being, "I can do it," and then I slowly transitioned in my writing. It would always be, "I did this, I did this, I did this, and you can do this."

And it was this very engineered kind of a transition to make sure that I'm empowering my audience to realize that I can do it, but they can do it as well, and I think that was, like, super, super important as part of the, the success.

Wow, that's amazing.

The... Now, one of the funny things is that when I was much younger, when I was back in school, I was never much of a writer. I'd never learned to be a-

Oh, really?

... high quality writer.

Uh-huh.

And I, I actually had a teacher when I... before I graduated school. She took me aside and she said, "Jeff, you kind of seem like you're kind of a pretty smart person, but you don't really know how to write very well."

You know how to write code.

Exactly.

But not articles.

Even back then, back then, this was when I was, like, 17 and graduating from high school.

Awesome.

I was good as a developer, not good as a writer, and... but I, I learned that skill as I went, and I learned again by, by practicing and by writing and by the time I finished my time on the blog, I'd written 1.5 million words and about 3,300-

Wow

... blog posts.

That's a lot.

So it, it was such a amazing 20 years to be able to-

Wow

... to do that and... but, but I didn't think of that as the important part. To me, the important part is I got to help bring so many services out to the world.

Uh-huh.

I got to light that fire in the minds of developers, make sure that they knew what was happening. And at a certain point, probably maybe four or five years in, I might be out at a restaurant with my family.

I remember the first time being out at a restaurant with my family-

Uh-huh

... and someone came up to me and said, "Are you the Jeff that writes those blog posts?"

Well, how do you know you are the Jeff? You post your photos on the internet and-

He, he could, he... my... He could find me. He could find me on social media and so forth.

Oh, okay.

And so he came up and s-

So how do you feel?

Okay. The funny thing is-

Uh-huh

... I had this bad feeling that-

What was it?

... maybe what would happen is that he would say, "I followed your instructions in my blog post, and it was wrong, and it ruined all my data-"

Oh.

"... and my startup got destroyed." That was my fear, that I would somehow-

Wow.

I had this unusual fear-

Mm-hmm

... that I would somehow be misleading my audience. But that fear is what led me to always get that personal experience with the services-

Mm-hmm

... and to do everything I could to be technically perfect and technically accurate.

Wow. It takes lots of time.

And, and of course, he only had... It really does, does. But, but he only had good things to say, and my family was so impressed. They said, "Oh, my gosh, Dad's famous," you know? "Everybody knows Dad here now."

And still to this day, my wife and I can be walking around the streets of Seattle, and people will stop and say hello and want to say something, something nice, and that's such a wonderful thing to have happen.

And I... It's always just wonderful to know that you've actually made an impact. And people will say, "You know, I have read some of your posts, and it helped me to learn something new," that learning something new helped me to get a better job or helped me to step up in my career, and that feels good.

It's such a gratifying feeling to be able to do that.

But how do you, like, make complex technologies feel simple and clear in your writing, especially when your teacher once said-

Mm-hmm

... you are not good at writing?

A lot of practice, and-

Uh-huh

... to me, you have to... When you understand something really well-

Mm-hmm

... it becomes easy to explain.

Mm-hmm.

And sometimes when we see something that's written with a lot of words, that means the author didn't fully understand it. So instead of getting to the point, they're kind of going in circles, and they're going here, and they're going there, and they're trying this.

But if you truly understand it, it's start here and explain it, and it becomes very easy and very direct. So I, I almost looked at the blogging as explaining to myself. If, if I didn't understand it, there's no way I can explain it to the audience.

Mm-hmm.

You have to read the documentation. You need to actually use the service yourself.

Mm-hmm.

There's no ... shortcut. You just have to do that. You have to put in the work.

Sounds like get your hands dirty.

You always have to get your hands dirty. And the, the temptation I've found in careers is you start out as a person who is... You're kind of at the starting point-

Uh-huh

... and it's always about getting your hands dirty.

Yeah.

But as you go up the, the career ladder, it becomes a little bit more distant, a little more abstract. And I've always resisted that temptation. You know?

Mm.

There, there's a point when sometimes they say, "Well, you could be the technical evangelist, but you know, you could be a little bit more business-y, and go talk to business leaders-

Mm

... and talk to CIOs and CTOs." Perfectly good kind of a job.

Yeah.

But you end up being more using, like, enterprise vocabulary and enterprise words.

Mm.

And it's not the deep core technical kind of things that I'm, I'm most comfortable with and that I enjoy speaking about.

Yeah.

I would much rather speak to a bunch of 20-year-old developers-

Uh-huh

... than 50-year-old CIOs and CTOs. But nothing, nothing wrong with the second group.

Uh-huh.

That direct, that hands-on, that's what I really enjoy.

Yeah, yeah. Understand. That's cool. So you have been writing constantly for, like, over 20 years.

For 20 years. I-

Yeah.

So we should be really clear-

Uh-huh

... that at the exact 20-year mark, I finished my time on the blog.

On the blog, yeah.

So that was, that was last November.

Oh.

So the reason I did that is I thought 20 years was a long time to do anything, but we also, over the, the last 10-plus years, we have built up a really strong team-

Mm

... that it wasn't just me. That I was doing some of the posts-

Oh

... but we carefully over the years, we put a manager in place. We allowed other members of the team to start creating content. I would always review and give them some feedback. They are all doing an amazing job.

I read their posts and I realize that they're doing better than I ever did, and I felt very comfortable wanting to, to not just do something new, but I wanted to make sure that they had their chance to be in the lead versus thinking they were somehow competing with, with me for the, the authorship.

I, I think that's sometimes important.

Mm.

When you get all the attention-

Mm

... it's okay to take that attention and enjoy it for a while. But there's also a time you say, "I've kind of had enough, and I think it's somebody else's turn to be famous."

I think your work is a living history of the-

Mm

... cloud. So how have developers' core problems evolved over, like, the past two decades?

So I think what, what has evolved over the years is that developers have more choices. The initial launch of every one of our services was pretty straightforward.

Mm-hmm.

So when we launched EC2, there was one location, or one region, as we call it, and there was a single instance type.

Mm-hmm.

It was just the M1 small with a fixed amount of memory and storage and compute power. And those were so easy that developers didn't have to make any choices. Today, there are well over 30 regions all around the world.

Mm-hmm.

There are hundreds of different instance types with different processors, different amounts of memory, different amounts of storage.

Oh.

And so developers are now faced with a lot of choices to make.

Oh.

The, the... Each one is, is simple and obvious and documented, but you put them all together, there's a lot of different choices that developers-

Yeah

... might need to-

I bet so

... to actually make. Yeah.

Oh. So how do you make this complicated system simple?

You have to point out to developers that in most cases, you don't need to understand everything before you can get started. And part of being a productive developer is you need to focus on the parts that matter, and you almost have to put on these, like, like, blinders and say, "I'm only gonna look at the part that's in front of me."

Uh-huh.

"I know there's good things here, I know there's good things here. I will just have to pretend that they don't exist-"

Yeah.

"... for a while."

It's not easy.

It's not, because there are so many interesting and so many powerful services available to developers. Sometimes the temptation is, I'll take this and this and this and this, and I'll use all these things to build a really cool app.

I say, you know what? That's a wonderful goal.

Oh.

You can aspire to that. Start simple, get that first one working, add one more service, make that work, add another service, make that work. And make sure you're doing it because you're actually delivering value to your customers. Don't do it just because you enjoy using all the services, right?

There's a, a real difference there of-

Yeah, yeah

... doing it for yourself versus doing it for your customers.

Interesting. So in this new AI era, how are developers', uh, needs changing?

Okay. So we're in this really fun time where I think that the last two years, developers have perhaps seen more change in their development style and methodology than maybe in the last 20.

Oh.

So for 20 years, even longer, we'd start with the blank screen or the blank piece of paper-

Mm-hmm

... or the blank punch card, and we'd have to imagine everything, and we would start from nothing. And most of our job involved... There was a really kind of a memorization component. So we would learn a programming language.

We'd have to learn the statements and the data types and the operators and the functions for the language, commit those to memory, and then as we're writing our program, we're kind of like remembering, "Well, what is-

Mm.

"What... How do I write this function, and how do I do this kind of math?" And so forth. But we're always starting from the bottom and building things up with the... starting from, from nothing, essentially. And so we're expressing our intent, but expressing it at a fairly low to medium level, but we're also giving the computer instructions.

Do this, then do this, check this, make this decision, activate this, deactivate this.

Mm.

With the AI tools, we're flipping everything around. We're expressing our intent by saying, "This is the end result that I want." We're not saying, "Use these functions, use this code, do the following data types and operations." We're saying, "This is the kind of application I want, and I want it to do this and this and this."

And then letting the, the AI-powered tools work backward from that to actually build a solution for us.

Yeah.

So it's a, it's a very different communication style.

This, this difference is huge. What does this mean to cloud providers like AWS?

So I think what it ultimately is gonna mean is that there are gonna be more people able to be effectively developer. They might call themselves developers or makers-

Mm-hmm

... or business problem solvers, but the fact that these AI tools can let you create a solution-

Mm

... without necessarily deeply understanding all the different technologies means that more people get to solve problems on their own.

Do you think today's AI coding tools remind you of the productivity revolution from the early days?

They do, but in a very different way. So there was... So these days, almost everybody knows a spreadsheet, like Excel-

Yeah

... for example.

Uh-huh.

And it's almost like a standard thing you might learn in high school or college.

Yeah.

That you know how to use Excel to do calculations. Well-

I think young people are born with Excel.

I think so, actually. But there was a time before Excel. The very first spreadsheet was called VisiCalc, which was invented, I think, in 1979, 1980.

Oh, like 50 years ago.

Yeah.

Yeah.

That sounds like a really long time now.

Oh.

But yeah, okay.

That's a long time ago.

I remember the time.

Oh.

Okay, let's say. So VisiCalc is invented, and for the first time, someone who's not really a programmer can go and they can set up effectively business calculations. And this was the... a, a huge turning point from, well, you- Do I actually have to become a programmer or hire a programmer because I want to set up some business logic and do some business calculations?

That was the before scenario.

Mm-hmm.

Then VisiCalc comes along and says, "Well, put in some formulas, put the, the, the, the numbers in." It will figure out how to do the calculation, put the results there on the screen for you, and suddenly business users can solve their own problems in a way that they could not do before.

Mm-hmm.

And this was maybe the biggest turning point that we would see. And, and I remember being in the business of selling computers at the time, and so we suddenly went from the programmers would come in to buy the computer to the business person would come in and buy the computer and say, "I'm not quite sure why I'm doing this, but I've seen this thing called VisiCalc-

Uh-huh

... and I know it can solve my business problems for me."

Yeah. It boosted the productivity.

It boosted the productivity. It gave them the power to do things themselves-

Mm-hmm

... instead of asking a developer to do it for them.

Mm-hmm.

And I really see these AI powered dev tools as very, very similar in that role of empowering people to solve problems for themselves.

AWS recently introduced Kiro. Can you please introduce Kiro to us?

Sure. Okay. So Kiro is an AI powered development tool, and the concept of Kiro, we call it Spec-Driven Development, and spec is short for specification.

Uh-huh.

And the idea is that Kiro helps a developer to build an application in a somewhat structured kind of a way. So the first step that you do with Kiro is you, you interactively work with it to build a specification for your application.

So spec first.

Right. You, you get the spec first, and you might say, "I'd like to build an application to help me collect data, store it in a database, and organize it in several different ways and produce some reports." You might put that initial requirement or, or spec into Kiro-

Mm-hmm

... and Kiro would say, "Okay, let me give you a set of requirements I understand from that." And then you might look at that and say, "You know, I forgot a couple things." Add those into your, your set of requirements.

So you, you actually converse with Kiro, and you go back and forth as if you're, you're working with another human being, and you're-

Working with a product manager.

Right. And the... You're the developer, I'm the product manager, and we're, we're having a conversation back and forth, except Kiro is effectively the developer for you. And at a certain point you realize, okay, I've, I have carefully and fully described my desired application to Kiro.

Yeah.

From there, you can move on to having it construct a set of requirements for you.

Mm-hmm.

From there, it will actually break that down into a set of tasks-

Mm-hmm

... that, that might be like, let's create the file structure, let's build the first set of internal modules, let's build test cases for those. And then, then you go and you start activating those tasks one at a time, and you, you watch as Kiro does the, the work for that, initiates the work, it waits for it to finish, it validates the output, makes sure it's correct, gives you an opportunity to review it yourself, which is very, very important, and then lets you proceed.

And so the idea is that this specification model is a lot more structured than this concept where you might heard, have heard called Vibe Coding.

Yeah.

Vibe Coding is wonderful.

Uh-huh.

Is great for the small to the approaching medium sized applications. When you get to the point where you're b- doing medium to large applications, you realize that you need to do something a little bit more organized than simply jumping in and, and writing code immediately.

Yeah.

And that's where we think that Kiro and Spec-Driven Development are, are really gonna be helpful to developers.

Okay. So the AI coding is a very crowded market, right? Besides the spec first, what other aspects do you think make, like, Kiro stands out?

Let's see. So, so we built Kiro b- because we talked to a lot of customers, and we, we have this Amazon principle called customer obsession. And we talked to a lot of customers and said, "Well, how can we make this a wonderful development tool for you?"

And they, they really said that the, the Vibe Coding tools were incredibly powerful, pointed out the, the actual value of AI based coding, but also said, "Give us something that we're gonna be able to apply to, to a really wide range of different kinds of applications, regardless of the scale."

Another aspect to Kiro that I think is pretty unique is you can create these documents we call Steering Documents, where if you are part of a team or if you have some corporate standards that say, "This is how we organize the files in application.

These are the standards that we use for our, let's say for security. These are the technologies for the back end and the middleware and the database and the front end," you can have basically like a shared file, and all your developers, all your teams could use that same set of shared files.

So you have a... You can enforce company rules and company policies-

Mm-hmm

... and coding standards across your organization without having to repeat them over and over again.

To make the-

So you're effectively providing more context to the-

Oh

... the code generator.

That's cool. To make the whole project clean and consistent.

Make the project clean and consistent within itself, but also consistent with the other projects that your peers might be building-

I see

... as well.

Okay. Cool. So beyond tools, how will AI reshape cloud infrastructure itself?

So I think that all of what developers already understand about cloud infrastructure-

Mm-hmm

... will continue to be of value. Developers are gonna be able to build great applications with Kiro, and then they're gonna wanna say, "I wanna deploy those. Maybe I wanna deploy them for worldwide use, and I wanna deploy them across multiple different AWS locations-

Mm-hmm

... or regions." So the, the cool thing about Kiro is it can help you with that as well. It can help you package the app. It can help you create the, the deployment scripts or the templates-

Uh-huh

... that will help you to actually launch the right cloud resources, get your code installed, and, and get it all ready to go in production form.

Oh, that's amazing. So right within the Kiro app.

Exactly.

Oh, cool.

So w- this is the kind of app you would expect developers to, to live inside. Like, some of us live-

To live inside

... inside of our email client. I live inside my Slack and my email clients.

Uh-huh.

You know, I'm... A lot of my day is spent messaging back and forth with colleagues-

Okay

... and with customers and fans and, and so forth.

I see. I live inside my WeChat.

Okay.

Yeah, that's cool. Living inside Kiro.

But, but you can imagine developers effectively living inside of Kiro-

Uh-huh

... as their, their primary application.

So will we see an AI optimized cloud with more GPUs or a fully AI driven cloud where AI automatically monitors, repairs, and allocates resources?

Yeah. So, so we're really more toward the, the second, ultimately, and, and this is one of the, the really powerful features of the cloud-

Uh-huh

... is the cloud is gonna to make sure that when you're running on a particular set of resources, if that hardware is failing, it's gonna automatically move your application to another piece-

Wow

... of hardware.

Mm-hmm.

If you get a lot of users, a lot of traffic, it's gonna add more, more hardware to scale out. It's going to make sure that you're... And this is, this is one of the values of using the cloud, is having access to that scale of resources, so that as your application grows, you've got more compute power, more GPUs, more storage, more memory, more network bandwidth.

All those things are available to you from the cloud.

I think AWS played a defining role in this serverless paradigm. What do you believe is the next major paradigm?

Wow, okay. So I, I agree that we definitely played a defining role in serverless. And the, the interesting thing of when we, when we launched Lambda and really started using the word serverless, people understood that very, very quickly.

And they said, "You know what? We understand all about the idea of managing servers. We know how to do it. It's something that we can do, but we don't really want to have to do it."

Mm-hmm.

And so serverless with the, the idea of, like, write your code, hand it off to Lambda, Lambda's gonna take care of all those details of running it on servers and scaling up to more and scaling down to less.

That's all just taken care of. As far as where we're going next, I see a lot of people talking lately about agent-based applications.

Agent-based applications.

Exactly, yeah. And I'm still trying to understand for myself exactly what that means, and there, there's a lot of different people kind of talking about agent applications in-

Oh

... slightly different ways. But basically you can think of the agent as having an, an LLM, a language model inside-

Oh

... and having access to, uh, a set of different tools they can use to carry out various activities. So maybe you have an application that knows how to maybe set up some travel for you.

Oh.

And so you might say, "I want to make a trip from Shanghai to Shenzhen. I need to stay for two nights. I need to find some restaurants while I'm there." So the agent would have access to things like getting flight information, reserving tickets, finding out a good place to stay, maybe checking some maps, maybe checking some reviews for restaurants, making you some reservations and plans.

So the agent... the... and then, so the, the model inside the agent is the one that's gonna take your request. Um, you're, you're simply saying, "I'm going to Shenzhen next week, and I need some help to get everything set up."

It can take that, break it down into a set of different tasks, and then it's gonna coordinate all the different work of those different tools and then get, get all those tools to work on your behalf. That's the...

The thing about the agent is those tools are working on your behalf, sometimes with your identity and with your credentials to carry out that operation that you request.

Wow.

So this is where a lot of people are kind of talking about as a future.

Mm-hmm.

We'll, we'll certainly see as this unfolds in the, in the coming months and years how that pans out.

So can we use Kiro now?

You totally can. You start by getting a builder ID, and the builder ID will let you download Kiro-

Mm-hmm

... and start using it. You can... There's a kind of a defined amount of usage you can do at no charge every month.

Oh.

And one of the really cool things that we just announced is that if a developer builds an app with Kiro to enter into a hackathon or a competition, and if they win, we're going to match their winnings up to a total of one million.

Wow, that's a lot.

I think it's pretty cool.

Wow. So as long as they use Kiro to build an application-

Exactly.

And win-

Right. And, and the cool thing is that they're gonna get some great experience with Kiro along the way. So we do absolutely for sure hope that they win.

Oh.

And if they win, that's awesome. If they got that experience, I, I think that's great for them as well.

Wow. I think this is a brilliant idea.

I think so. And the, the thing is we really see a, a massive value in-

Oh

... making sure that developers are empowered to do... I always like to say to think big thoughts and to dream big dreams, and I want to see developers doing that with Kiro.

Okay, that's cool. So in your final AWS blog post, you mentioned you plan to build new things, right? Can you give us a hint about what problem or idea you are excited to tackle next?

So let's see. So I think I had this plan that for this year, for twenty twenty-five-

Uh-huh

... that I would basically sit down with dev tools and be building things.

Mm-hmm.

And ultimately, what happened is after I announced that I was finishing up the blog, I got a lot of invitations to go out and speak at events all over the world. And so I've ultimately been traveling the world and speaking to developers, and it's, it's been an incredibly fun year.

I think by the end of this year, I will have been in fourteen or fifteen different countries speaking to developers. And so that, that is effectively what I'm... I guess you could say I'm, I'm building the, the developer community-

Uh-huh

... is what it's turned out to be. It's wonderful to have plans sometimes-

Mm-hmm

... but you can also... you need to have a bit of flexibility in your life and say, "Well, this is kind of where life is taking me."

Yeah.

And it turns out that-

Just go with the flow

... you gotta go with the flow and say, every time I do one, one speaking event, I get invited to two more. People must actually like what I'm doing, so I'll, I'll keep on doing that for a while.

That's cool. That's cool. Yeah. So our last question is, today with AI tools and social media, it feels like everyone can be an evangelist, right? So my question is, what does it mean to be a true technical evangelist?

What is the one principle that guides your work?

Well, I, I think that the technical part is really important.

Uh-huh.

Like, understanding what you're doing is super important, and then whatever medium you choose, could that be written, could it be speaking, could it be videos-

Uh-huh

... could it be TikTok videos, whatever you like to do, create that content. And the interesting thing is, as developers, we're always needing to learn something new. And as you learn something new, you're-- maybe you're, you're building some code or you're taking some notes.

You might as well actually turn that into some content. And you actually... and to me, that's almost like a, a little, like a secret weapon, effectively, is that you can get value twice from doing something once. So you do the learning, but you create the content as you go.

Mm-hmm.

But you've, you've only made that one-time investment-

Uh-huh

... but you've, in addition to the learning-

That's the value twice

... right. But you're getting the value also of building your, your social media reputation-

Uh-huh

... by, by sharing that content.

That's cool.

And the, and the neat thing is, there's no official or standard way to do any of that content. Whatever way you figure out that works for you and that you think works for your audience, that's the way you should do it.

Okay, that's cool. So thank you, Jeff.

It's been really fun.