AWS re:Invent 2025 | Special Closing Keynote with Dr. Werner Vogels

[music] Second, [music] [music] [music] [music] Heat. Heat.

[music] Heat. Heat.

[music] [music] [music] >> [music] [music] >> second [music] [music] [music]

Sex [music] Sex [music] Sex [music] >> [music] [music] [music] [music]

>> sex >> [music] >> I'm saying [music] [music] beat.

[music] >> [music] [music] >> Sax, [music] sex.

[music] >> [music] [music] [music] >> Hey, hey, hey.

>> [music] [music] [music] >> Hey, [music] hey hey.

>> [music] >> Sex.

[music] [music] [music] End of [music] the developer. I've heard

that before.

>> [music] >> Heat. Heat.

>> Heat. Heat.

>> [music] [music] >> Well, still having trouble.

Hi there, Lorraine.

>> What you doing?

>> 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.

Anything new at head office?

I've been reading about this uh coal.

>> Yes, it's the new high level language.

>> It's amazing. Now, anyone can write code.

>> I don't know about anyone. Writing

software is pretty tricky.

>> Soft what?

>> Software >> where >> [music] >> Hey, Marty. What you reading?

Just learning some [music] VB >> visual programming, huh?

Coding's history, Marty. Drag and drop is the future.

Drag and drop is still code. It still

has bugs and it still needs an engineer.

[music] >> Everything fails all the time.

Is this for real?

Could cloud mean there will be less engineers?

Less engineers.

Time for an airrop.

Huh? Servers in minutes. Scale on

demand.

Pay as you go. Wow.

You learn something new every day.

[music] You build it. You win it.

[music] >> Mom.

>> Hi, sweetie. Don't forget to call mom.

>> Why are you there, Marty?

It's a nice wormhole, isn't it? Mind if

I join you?

>> O, you can skip this [music] one.

Is this the end of development as we know it?

Or is it just another new beginning?

>> [music] [music] >> Please welcome the vice president and CTO of Amazon.com, Dr. Verer Vogels.

[music] [music] Thank you. Okay.

Thank you. Okay.

>> Trust I seek and I find in you something new for us every every day for us

something new an open mind for a different view and nothing else matters.

Good morning. Oh no it's not. Hello

guys. Uh so the video showed you every generation of developers that face a new wave of change. Yeah. Tools evolve,

architectures evolve, expectations evolve, and so do we.

But before we talk about that, let's talk about the elephant in the room. Yeah.

room. Yeah.

I've been giving this keynote since 2012 and I've done all of them. That's a lot of t-shirts, by the way. Yeah.

But today, this week ends, this is my final reinvent keynote. Yeah.

I have still things to do. I'm not

leaving Amazon or anything like that, but I think that after 14 of reinvents, you guys are owned

young, fresh, new voices. There are so many amazing engineers at Amazon that

have great stories to tell, to teach, to help you, to educate you. And I think it's time for those younger different

voices of AWS to be in front of you.

[snorts] But nobody forces me to do this. I'm not leaving Amazon or anything

this. I'm not leaving Amazon or anything like this. This is my decision to make

like this. This is my decision to make sure that you get to hear different voices than just mine.

Now, let's talk about the other elephant in the room. Yeah.

I visited AWS customers all over the world and there is these days one question that keeps coming up in every

country and in every city.

Will AI take my job?

Maybe.

Yeah, our roles transform.

Some tasks will be automated.

Some skills will will become obsolete.

New ones will emerge.

So maybe we should rephrase and reframe this question.

Yeah.

Will AI make me obsolete?

Absolutely not.

Yeah.

If you evolve.

Yeah.

And if I look at the past years at uh at Amazon where you know we've been using all these new tools, we've seen how

you can evolve over time and still be a great engineer with just a new set of tools in your hands because we evolve as

developers.

Yeah. and so must tattoos and so change is constant and this has always been the case. It's nothing new.

Yeah. Here let's go back in time a little bit just for the heck. When I went to school I was taught 68,000 assembler cobalt and

Pascal.

Yeah. None of these languages are being used anymore.

Yeah. And in the 60s we got suddenly got compilers and you didn't really matter anymore what kind of assembly you those

those compilers spit out. However,

by learning assembly, I knew I learned how that loop impulse call actually translated into machine

code. And so that was important to me.

code. And so that was important to me.

And over time, you know, compilers became the highest level abstractions that most developers needed.

In the 70s, suddenly structured programming became popular. Yeah. And

we're moving towards that. Compilers out

of Bellabs and Berkeley, they supported this shift. They give developers a

this shift. They give developers a clearer control over flow and help them escape the chaos of unstructured code.

And then a few years later behind the strap he started exploring how to model real world concepts directly into coding

objects and classes and that became C++ and helped shape object oriented programming.

In late 1990s Amazon was still running as a monolith and in 98 and this is this famous moment.

Yeah. The the growth accelerated to such a point that the team began breaking off pieces of these monolith into services.

Yeah. And each each service had ownership of their servers, had their own interface. And it completely changed

own interface. And it completely changed how developers worked. They were moved faster. They become independent of other

faster. They become independent of other teams. They owned their systems end to end.

And over time the industry at large became adopting these kind of practices as a practical model for building and and operating large scale distributed

systems actually. And what about the tools in

actually. And what about the tools in those days?

Yeah. But in the 2000 most developers they were still building and deploying things on premise.

Yeah.

and writing code meant wrestling with hardware. Capacity planning, long

hardware. Capacity planning, long procurement cycles and when cloud services arrived, they changed the expectation of the role again.

Developers suddenly had on demand infrastructure, freedom to experiment uh without waiting for hardware. And

this required new skills and developers everywhere adopted the world to a world where cloud infrastructure just became the normal way to build and operate

software.

My first IDE, any guess?

VI.

No, I'm not an Emacs person. Yeah,

just the same. [applause]

uh and the ideas actually they evolved with us you know we got Microsoft at some moment you could catch draw boxes on the screen and you had this first

real IDE and uh later we got Visual Studio and then Visual Studio Code became the default because of all the amazing

plugins and all of that and today's environment are cursor and ko And that's the new workflow.

Is there a new new workflow next year, five years from now, 10 years from now?

Of course there is.

Yeah. Our tools today though I think are kind of extraordinary.

In in Matt's keynote, we already saw examples of developers becoming dramatically more productive with AI assisted workflows.

But none of this removes the work that only you can do.

Remember, the work is yours, not that of the tools. It is your work

that matters.

Yeah. Our tools are changing so many times over the course of my career and they will continue to change. We're

still builders.

We're still important. Nothing has

changed there.

There's never been a time to be more excited about being a developer. Bezos

not that long ago in an interview, he he talked about this as that we're living at the epicenter of of a multiple simultaneous golden ages coming

together. You know, space travel,

together. You know, space travel, artificial intelligence, robotics, each are advancing an incredible pace.

But what makes this moment different is how these breakthroughs actually reinforce each other.

Progress in one field accelerates progress in the other fields.

And this actually made me think back in history at a time when that was kind of similar.

The Renaissance, the rebirth, um came after a period of darkness, the dark ages,

the the the middle ages, the death plague, and anyone who knows Montipython knows about how that looked

like. Yeah. But the renaissance was a

like. Yeah. But the renaissance was a period where everything changed because people became

curious. Curiosity was absolutely

curious. Curiosity was absolutely exploding. And the result of that is

exploding. And the result of that is amazing scientists and philosophers. And

if you look at this, you know, the medit is probably the first version of a venture capitalist or a philanthropist.

So, whoever you want to name it, Galileo and Copenicus were amazing scientists.

Petar, one of the first philosophers, Dainci, we'll come back to him.

But what also evolved at the same time were their tools.

It's not just them. Because of

curiosity, a pencil was invented. That seems

nothing to be invented today. But it was a major thing. You know the fact that they start thinking about something

called a vanishing point. Well, suddenly

that if you compare paintings and drawings before the Renaissance, they were all flat.

Yeah. In the Renaissance, suddenly depth appeared and different lighting appeared in paintings and drawings.

And then these tools like the microscope and the telescope of course invented by Dutch people.

Yeah. Not saying anything.

Yeah. And then

you know the printing press of course we all see as sort of the the pinnacle of invention in the Renaissance. But that

was not just one invention.

You know, Gutenberg actually used a wine press as his first tape. But that was not the only thing he needed to invent.

He needed to invent movable type basically that you have characters that you can put together. He had to invent an ink that actually could be put on

those characters and then paper on press.

Imaginary almost imaginary in those days. Yeah. It

was a time where art and science were part of the same conversation.

Creativity and technology evolved together.

Now spend some time to think about what made people so effective in that world.

They were curious.

They questioned assumptions.

They learned broadly and applied that learning deeply. They didn't see

learning deeply. They didn't see boundaries between fields. They built

bridges between them. They were also bold experimenters. They sketched, they

bold experimenters. They sketched, they measured, they failed, they tried again, they learned by doing.

So if I take all of that in, I think by putting that together, I think we are again in a time of renaissance

and you are the new renaissance developer. Yeah, those quest those

developer. Yeah, those quest those qualities of those scientists in a renaissance are just as relevant today.

So I've brought them together into a framework that I call the Renaissance developer and I want to show you today

this framework hopefully help you evolve and be successful in this new era as well.

What is Kushov and all of this? The first quality that you need to nurture

is you need to be curious.

Curiosity is critical. As developers,

you always had to continuously learn because everything changed all the time.

And every developer I've met has this instinct to take something apart and then look at how it works. And that's

also what drives us here. The desire to understand, to improve, to build.

You have to protect that instinct.

Stay curious because curiosity leads to learning and invention.

Equally important for learning is two things. Yeah. For

all new inventions, you need to experiment.

And to experiment well, you need to be willing to fail. After all, Davinci

modeled an airplane that never flew, but we're flying now.

Yeah.

And by the way, an experiment is not an experiment if you already know the outcome.

Yeah. It drives experimentation drives to learning. And this willingness to fail is crucial.

When I learn a new language, whether that is Dutch or English or Portuguese or German, I find that the same principles apply. The best way to learn

principles apply. The best way to learn is fail and be gently corrected.

You can study grammar all you like, but relearning begins when you stumble into a conversation and someone helps you to get it right.

Software works the same way. You can

read documentation endlessly, but it is the failed builds and the broken assumptions that really teach you how a system

behaves.

And any of you who have recently used the Rust compiler knows how much feedback you can really get.

And there are some things that you can only do and only learn by doing.

Reading, watching, listening only takes you so far. But real learning happens when you engage.

When there's some pressure, when the outcome matters. There is a relationship

outcome matters. There is a relationship between stress and performance called the JS and Dobson law. The picture is a bell curve. You

law. The picture is a bell curve. You

know, too little pressure and you're disengaged. Too much pressure and you're

disengaged. Too much pressure and you're overwhelmed.

The sweet spot is somewhere on that rising slope where curiosity meets challenge. That's when your brain is

challenge. That's when your brain is fully alert, focused, and ready to grow.

Yeah. You can't reach that point by sitting comfortably. You have to put

sitting comfortably. You have to put yourself in positions that test you.

Now, there's a whole story behind this and that newspaper that you all found on your seats today, The Colonel, there's

an article in there by Andy Warfield who writes about this. I urge you all to read that article if you really want to

understand more of that.

Now, learning there's another side to it. Learning is social.

it. Learning is social.

Yeah, we're not here only to sit in a room and listen to one person telling you exactly what to do. The thing you really learn is by talking to each

other. Learning isn't just cognitive. It

other. Learning isn't just cognitive. It

is social. You have to touch the grass occasionally. And by that I mean you

occasionally. And by that I mean you have to get out of your usual environment. Go to a user group, attend

environment. Go to a user group, attend a conference like reinvent have coffee with a friend and talk about systems. One of the best ways to stay

sharp is to be around other people who are building things.

And for me that often happens when I'm on the road. I travel a lot for work.

And those trips keep me connected to how people are actually using technology not just how we imagine they might.

This year I was very fortunately I took two monthlong trips one to Africa to Sahara Africa and the other to Latin America in both regions. I gave some

talks but I mostly meet with customers and the real thing I do is learning from those customers. Here are a few

those customers. Here are a few examples. Yeah, here's a

examples. Yeah, here's a this is actually also it took me 21 years to actually end up on the Amazon.

Yeah.

And so GBA is a beverage company. They

support communities along the Amazon River in a way that they give young people an economic future so that they don't leave their villages to go to the

big towns. It is a brilliant experience

big towns. It is a brilliant experience and a great example of how doing good [snorts] can be profitable at the same

time.

The Amazon River was was beautiful. I

saw pink dolphins.

Yeah. But it reminded something else that I learned that not all of this is so great.

Um, earlier in the year I spoke with Boyan Slatt from the Ocean Cleanup Project during an episode of the Frugal

uh uh podcast and he told me that 80% of the plastic found in the ocean originates from just a thousandth of the

world's three million rivers.

to rid the oceans of plastic. They need

not only to clean up what is already out there, but also to stop new plastics from entering the ocean via these rivers.

And they do that, they've created a river model using drones, AI camera analysis, even GPS tagged dummy plastic.

the place where we went into onto the Amazon house, they actually took plastics and put GPS's in it, threw it in the river, see where it ended up.

Turns out the Amazon is not a big poller at all.

But this computational model that they've built, these AI cameras that are on bridges, that are on the back of

ships, yeah, they create a computational model that predicts how and where this plastic will traffic and helping them

position their cleanup systems for maximum impact.

Now, another thing that totally blew me away on this trip was actually in Rwanda.

Uh, in Rwanda, this is the headquarters of the Ministry of Health.

Yeah. And this is their health intelligence center. In their operation

intelligence center. In their operation centers, huge screens display near realtime data from four different tiers of health care facilities across the

country. They've built an impressive

country. They've built an impressive system that ingests and processes vast amount of health care data visualizing

everything from disease outbreaks to maternal health outcomes.

and they use it to create new policies.

Yeah, they've created this model which shows that which parts of the country are more than a 30inut walk away from a healthcare provider

and they use this data to strategically place new maternal health facilities in underserved areas.

They use data to drive policy and to actually implement that policy.

Another visit that actually I mean most of these trips I get blown away every time especially about well how young companies are attacking some of the

world's hardest problems. In this case, we're uh we're in Nairobi.

And I learned that in many places there, people will just borrow a dollar or$2 dollars in the morning, buy some goods, go and sell it on the market or on the

street, and in the evening they will give these dollars back and hopefully have 40 or 50 cents which they made that day.

And that's enough to go buy some food.

Great. It is not enough though to also buy the gas to cook your food.

So in those poor parts, [snorts] it's all burned on carbon which is massively polluting.

So this young company called Cocoa Networks, they came up with a completely different solution.

They basically build these kind of ATM machines with ethanol in them and a small canister that people have and they

can basically walk up to the ATM to the machine, plug in that canister and ask for five cents of gas which will be

enough to cook their food that night.

Yeah. This is what happens when developers apply their skills [snorts] to real human challenges.

Developers have always driven progress.

You have built the foundations of the digital world and today you're the ones tuning turning to AI from from

possibility into something useful, safe and scalable.

And developers like you were essential in the past. They're essential today.

And you will be essential in the future.

The United Nations expects that by 2050 we have two billion more people on this planet. How we're going to feed them?

planet. How we're going to feed them?

How we going to make sure they have an economic future? How going to make sure

economic future? How going to make sure they have healthcare?

that's on us to develop technologies so that we can help solve some of the world's biggest problems. us as

technologists have that ability to do.

And if I look at at some of you who spend so much of their time not just to actually build some things

in the corner of your room, but actually help others, the AWS heroes.

Yeah, we now have 200. Yeah, they they deserve an applause.

[cheering and applause] Go there.

So, I've met community builders. I met

AWS heroes and these are people that are solving hard problems in their own corners of their world. They're now 265

heroes across 58 countries. But what

constantly amazed me is how much we can learn from them.

By the way, this year's now go build award goes to Raphael Quinc. [cheering]

Stand up Raphael. [applause]

Rafi Rafi absolutely embodies the Renaissance developer. He doesn't just write code,

developer. He doesn't just write code, he builds communities. He mentors others and he co-leads the AWS user group in the Philippines since 2013.

Come on, Rafie. One more round of applause for him. [applause]

So the first quality I think that a renaissance developer needs to have is to be curious.

And I like this quote from Rald Whitman.

Yeah. We are not what we know but what we are willing to learn.

Another quality that I think the Renaissance developer has is that he thinks in systems. Yeah. And let me

Yeah. And let me just come with me for a moment if you don't really understand. I don't mean a computer system in this case but in a

big system. So in the 70s an ecologist

big system. So in the 70s an ecologist called Donella Meadows began studying how complex systems behave. uh she

wasn't a computer scientist but her insights describe our world of software perfectly and she wrote yeah a system is

a set of things people cells or whatever interconnected in such a way that they produce their own patterns of behavior over time and

that was an extraordinary definition because it capture what every engineer eventually learns that our systems have lives of their own. Let me give you an

example by the way that is not computer related. One of the most striking

related. One of the most striking examples of systems comes from ecology.

In the early 20th century, the wolves were removed from Yellowstone National Park. It seems logical. Yeah. Fewer

Park. It seems logical. Yeah. Fewer

predators meant more elk meant more life. Yeah. But the opposite happened.

life. Yeah. But the opposite happened.

The valleys were overg graced. The trees

disappeared. The rivers became to began to erode. And this phenomena is called

to erode. And this phenomena is called the trophic cascade.

When we reintroduced in 2010 wolves back into the park, slowly the park started to heal.

Vegetation returned. Beavers came back.

Even rivers changed course. The wolves

the wolves didn't move the rivers.

Yeah. They didn't they changed the behavior of the overall system. That

single feedback loop predator and prey reshaped the balance of the entire system. And when structure changes,

system. And when structure changes, behavior changes. And when feedback

behavior changes. And when feedback changes, outcome changes. That's what's

called systems thinking. So when

thinking in systems, we think in complete systems, not just in isolated parts. Every service, every

API, every queue is part of a larger system. You can't change one part in

system. You can't change one part in isolation.

Alter a retry policy and you affect load. You add a cache and you change

load. You add a cache and you change traffic load. Um you change traffic

traffic load. Um you change traffic flow. You shift team ownership. You

flow. You shift team ownership. You

change the pace of delivery.

Each change creates new patterns. Some

stable, some not.

Every dynamic system is shaped by feedback loops. Reinforcing loops,

feedback loops. Reinforcing loops, sometimes called positive loops, amplify change. balancing loops or negative

change. balancing loops or negative loops counteract that change and push the system back into an equilibrium.

Meadows thought that once you see patterns like this, you start to see where small wellplaced changes might

shift the overall systems behavior.

Della uh wrote a paper very paper it's called leverage point places to intervene in a system where she put all of these things together there's some words that we know from computer science

on a daily basis positive and negative feedback loops but you really should read this paper call this homework yeah

take a picture of the QR code and that's your homework for the coming The Renaissance developer

thinks in systems and to build resilient systems you need to understand the bigger picture.

If I think about a third quality of the Renaissance developer is communication.

He she communicates Yeah. And if you step into this broader

Yeah. And if you step into this broader view, you realize that the ability to express your thinking clearly is just as

critical as the thinking itself.

And this is why I believe that one of the most important things that an engineer or a technical leader can do for their career is to practice develop

strong communication skills.

Let me give you an example. Well, let's

go back two years when we did the frugal architect. Don't know if you remember

architect. Don't know if you remember this picture. This is the uh the Amazon

this picture. This is the uh the Amazon homepage and I explained to you how we had divided that homepage or the overall Amazon system into three different

tiers. Tier one is something that is

tiers. Tier one is something that is absolutely necessary to make the system work. Yeah. Search, browse, shopping

work. Yeah. Search, browse, shopping cart, checkout, and reviews. Without

those five things, the site doesn't work. Tier one. Tier two are things that

work. Tier one. Tier two are things that are important to our customers.

Personalization, recommendations, things like that. And

tier three might be nice to have kind of parts [snorts] to be able to do. This is important not just for us as engineers, but as

communication tools towards the business. You go and sit around the

business. You go and sit around the table with the business and talk about how many nines available does tier one need to be.

Oh, four nines that will cost you that much. Yeah. Or tier two maybe three

much. Yeah. Or tier two maybe three nights.

Yeah. Tier three, maybe you don't care at all. Two nights. Or you think, well,

at all. Two nights. Or you think, well, you know, we'll do a manual fail over if the data set data center goes offline.

But it's a communication that you need to have. You need to be able to clearly

to have. You need to be able to clearly describe your system and the capabilities and the opportunities towards the business.

Communication is crucial.

Now, human languages, it's a bit of a challenge, isn't it?

Yeah. Although

Yeah. Because natural language is ambiguous.

Yeah. But we have so many different senses at the same time. Yeah. That we

can turn this natural language into something less ambiguous.

Yeah.

Do we uh do we put grammar on the grill or are we having dinner tonight?

Yeah.

Even without a comma, you probably already have figured this one out.

Yeah. Now, we've always communicated to machines through programming languages because they were precise. We could

precisely indicate to the machine what we wanted it to do.

Yeah. But in today's world of AI assisted coding, we increasingly communicate with the machine in natural

language which is ambiguous.

So we need to help to develop mechanisms to reduce the ambiguity of that language

and reduce the ambiguity of of the human such that a machine can create logic.

Yeah. Specifications

reduce ambiguity and our history is rife with stories of specdriven development. Dystra's

specdriven development. Dystra's structure programming environment before it was based on formal specifications but that proved program correctness

before you even implemented it.

The Apollo guidance system relied on meticulous specifications that guided its 145,000 lines of code, a blueprint

so precise that it helped land people on the moon.

And to talk more to you about specifications, I'd like to welcome Cla Loriori, senior princip developer on the Kho team. Claire, up to you.

Kho team. Claire, up to you.

>> [music] [music] >> Thank you, Verer.

Sometime last year, I started noticing that as I was vibe coding more and more, I had a communication problem. I was

spending more and more time trying to describe to the AI what I wanted.

The code that the AI generated was good, but the end software didn't do what I wanted it to do. I would often try to start over with a new prompt and start

all over over again and try again.

I noticed that over time I wrote longer and longer, more detailed prompts trying to define what the software should do. I

would write these long mar detailed prompts in obsidian and markdown and then I would copy and paste it over to my coding assistant.

I was essentially creating a specification to better communicate with the AI what I wanted.

Software specifications can clearly communicate how a system should behave, what it should and shouldn't do. And

like Verer said, many systems in history have been based on specifications like Apollo missions.

It felt like specifications were exactly what was missing from my interactions with my coding assistant.

But then I thought, how could we use this idea of specs as prompts? What

would spec driven development look like?

And this spark of an idea led us to start work on the Kira IDE.

With this idea though, we now had a new communication challenge. How could we

communication challenge. How could we communicate and validate this idea with potential users?

We didn't know what it would look like and we didn't know what users wanted. It

was also kind of difficult to describe what specdriven development was. They

hadn't seen it before and we hadn't built it yet.

One of the best ways to get your ideas across is to quickly build a prototype.

Something that your users can see and touch.

Rapid prototyping is of course not a new idea. Let's go back to the 60s to the

idea. Let's go back to the 60s to the time of punch cards.

In 1964, Doug Engelbart at SRRI had a rough idea for a device that had wheels on the bottom and you would slide it across a tabletop to point to something on a computer screen. And we can

probably all picture this device in our head. But can you imagine going back to

head. But can you imagine going back to the 60s and trying to describe what a mouse is to this guy?

Angelbart's team rapidly built a prototype out of a block of wood. It was

a wooden shell. It had wheels on the bottom and a button on top. And this

rough prototype communicated better what a mouse was, better than any drawing or description could have. It let people put their hands on it and get the concept immediately. It had great

concept immediately. It had great ergonomics. It felt great in their

ergonomics. It felt great in their hands.

And like the mouse, rapid prototyping was crucial for Curo. We knew that the ergonomics of spectriven development was going to be important, how it felt in

the hands of a developer. We rapidly

built prototypes of how we thought spectriven development could work. And

we put those prototypes in the hands of some internal users. and we asked them to use Curo every day. That was going to be the best way for us to understand what felt good and what didn't feel

good.

This is a great example of what AI can do for us. Now, AI has fundamentally enabled rapid prototyping for software.

I'm sure that in the past we've all spent months manually coding a single idea and now we can give our users real

working prototypes in minutes to get feedback about what feels right.

Rapidly prototyping Kuro even let us use Kuro to build Kuro. Our very first prototype of the Curo IDE could only do vibe coding. But from that moment on, we

vibe coding. But from that moment on, we were able to use the Curo IDE to generate the code for the Curo IDE.

And by using the Curo IDE to build out the product, we were able to iterate through many ideas of how specri development could work.

One idea was test-driven development specs. Taking inspiration from TDD

specs. Taking inspiration from TDD techniques. You would describe a change

techniques. You would describe a change that you wanted and Kira would generate tests to validate the behavior that you described.

Kira would then generate application code and made sure that it passed those tests. But we found that developers

tests. But we found that developers couldn't always capture the nuance of what they wanted their software to do or look like with tests only.

We tried out traditional technical specifications similar to those that Verer described for the Apollo guidance system. They

describe the system as a whole and each component in detail.

With this, you'd add a new feature to the overall spec, and Cira would kick off coding tasks based on the changes that you described. These specs were great context for the AI and even for

developers who weren't very familiar with this codebase. But for real world projects, they sometimes became overwhelmingly long. So it was difficult

overwhelmingly long. So it was difficult to figure out where in this long spec you should put your changes for your new feature.

We took a step back and we looked at how we already worked as a team. When we had a new feature idea, we would describe it. We would work through product

it. We would work through product requirements, review a design dock, and create sprint tasks. And we thought that perhaps specs

tasks. And we thought that perhaps specs could follow the same pattern and that became feature-driven specs. We

separated the flow into three documents, requirements, designs, and tasks. And we

found that this gave developers more control over the AI and let them better communicate what they wanted.

All of these rapid prototypes gave us critical user feedback that led to today's spectriven development workflow that's in the Curo IDE. With a spec

workflow now in place in Curo, we could use it more effectively to keep building out the product because now we could communicate more precisely with the AI

what we wanted.

Often with vibe coding, I find that we give these very ambiguous tasks to the AI. We might say, "Build me a web trivia

AI. We might say, "Build me a web trivia game." And out of this very short

game." And out of this very short prompt, there's probably a million possible different final outcomes. But

probably only one of those is what you have in your head. With five coding, the AI is going to take its best guess as to what you meant. It'll generate code, but

that leaves you to iterate on the code with the AI instead of on what you originally meant.

With specdriven development, you have an opportunity to refine what you mean more precisely through specs. You can give the Curo IDE that same ambiguous task,

but instead of jumping into the code right away, it's going to first generate requirements, designs, tasks. And if

those don't match what's in your head, you have the opportunity to ask Curo to change it and refine it.

Let's walk through a real example of a production feature that we built in the Curo IDE using specdriven development system notifications.

We started here with a little annoyance that we ourselves experienced with an early version of the Curo IDE. Agents

can take a while to complete their coding work and meanwhile we would switch away to a different app. But then

the agent would need user input or it would complete its work and we would have no idea that it was sitting there idle while we were away doing other work.

So we set out to build a feature that would notify the user when the agent needed its attention.

We started by having Cira generate a spec and the generator requirements actually helped us to think through some details like which agent actions should trigger notifications to the user.

When we got to the design phase, we'd expected this to be a pretty simple integration into the Curo agent code.

But instead, Curo generated this very complex design that would build an entirely new notification system directly in our agent code. Now, if we had vibe coded this, we would have ended

up with a lot of code that we didn't actually want.

But instead, the spec process helped us quickly realize this was a much bigger project than we originally thought.

We iterated on the spec to first focus on building a notification system directly outside of the agent code and directly in the underlying IDE code.

This needed to be built on top of Electron's native notification API.

Kira IDE is based on code OSS which is a codebase that spans 10 years of development and two million lines of code. It can be difficult for any

code. It can be difficult for any developer to figure out where they need to make changes in this codebase.

But Kira spec workflow actually helped us to explore and understand where these changes needed to be made. And once

these changes were in place, we were again able to use specdriven development to integrate it into our agent code.

Throughout this prospect, we were able to quickly iterate on our specs till we got exactly what we wanted from the AI.

With specd driven development, we would have shipped this we shipped this agent in roughly half the time as if we had viodated it. In our experience building

viodated it. In our experience building Kira, we realized that AI has changed how we communicate and how fast we can

iterate.

We can iterate on the software design by communicating with the AI through specs.

And we can iterate on what the software does by putting real working applications fast into our users hands and get feedback.

AI and specdriven development helped us to build a better Curo IDE. And this was in large part due to more precise communication with our users through

rapid prototypes and with AI through specs.

Natural language doesn't have to mean high ambiguity. And personally, this is

high ambiguity. And personally, this is what I think makes Kira IDE so special.

Kira IDE brings precision to natural language. And with that, I'll hand it

language. And with that, I'll hand it back over to Verer.

[music] [music] Thanks, Claire.

Communication is so important that CLA shows it leads to systems that have fewer mistakes actually.

So let me get tell you a story again sort of out of my own youth. When I went to to computer science school there was

a class called interview technique and I go what interviews? Because you think about journalists and things like that.

No, it was how to learn to talk to your customer to really trying to understand what he or she actually really wanted because they may come to you already

with a technology solution without knowing anything about technology.

Wouldn't be the first time these days when I meet a customer who says, "What should I be doing with Gen AI?"

And then because you're really trained in trying to figure out into depth say I'm very I very apologize to answer your question with a question but why are you

asking me this most of this is fear of missing out and so really diving into it with the customer to understand what's the

problem they want to solve what's the opportunity that they see all of that is communication that we as engineers should have.

Now let's go to the fourth what I call the fourth quality of the Renaissance developer.

Yeah, the developer is an owner.

Ownership. I've spoken about it before but today I want to focus on one part of

it. Owning the quality of your software.

it. Owning the quality of your software.

AI will let us build things bigger systems, explore more ideas, move faster than ever before. These tools will, as

the modernday philosophers Deb Punk once said, help us build harder, better, faster, and stronger.

And if we use these tools correctly, they can help us produce high quality software.

But there is a risk in how some developers are starting to use these tools. VIP coding is fine, but only if

tools. VIP coding is fine, but only if you pay close attention to what is being built. We can't just pull a lever on

built. We can't just pull a lever on your IDE and hope that something good comes out. That's not software

comes out. That's not software engineering. That's gambling. And you

engineering. That's gambling. And you

need to be out there somewhere for that.

Yeah. Remember what I said at the beginning, the work is yours, not the tools. [snorts]

If you subject to regulatory requirement, let's say healthcare, uh, financial services and whatever, if AI creates some code that suddenly violates

the regulatory requirement, you can't go to the regulator and say, "Oh, was AI?"

No, it's still your responsibility. The

work is yours, not that of the tools.

Now the world is changing.

You will write less code because generation is so fast. You will review more code because understanding it takes time. And when you write the code

time. And when you write the code yourself, comprehension comes with the act of creation.

When the machine writes it, you will have to rebuild that comprehension during review.

That's what's called verification depth.

And it's one of the two main challenges that I hear when I speak with developers about this new style of work. AI can

generate code faster than you can understand it. Code arrives instantly,

understand it. Code arrives instantly, but comprehension does not.

That gap allows software to move towards production before anyone has truly validated what it actually does.

The second challenge of course is hallucination.

Claire showed already a perfect of example of that earlier. The model

produced a design that looked confident but was completely wrong for the architecture.

Some API change and LMS invent attributes that do not exist. Sometimes

they propose solutions that are completely inappropriate or overengineered or ignore your systems own patterns. These outputs look

own patterns. These outputs look plausible but are not grounded in reality.

I think we're making progress there.

Yeah, we're developing practices that like specdriven development which CLA showed how can it how it can dramatically improve quality. Uh Byron

in Swami's keynote showed how tools like Cairo can actually use automatic reasoning with your specification to create code that is verified.

We showed how we can also use automatic reasoning to ensure that code generated against AWS APIs is correct.

I also see many developers looking at their CI/CD pipelines then building more and more automated testing. Yeah, these

are all types of mechanisms. Here I want to make a change. See, I

want I want you to really understand these two things. There are mechanisms and there are good intentions.

They're not the same.

And let me do you that by uh again going back a little bit in the past and tell you a story about Jeff Bezos.

Um in the early days of Amazon, we as executives were required each year to spend two days with customer service and

take calls from customers such that we would truly understand what our customers were going through and not just us lonely executives, Jeff himself

as well. So Jeff sits next to this

as well. So Jeff sits next to this customer service agent. Phone goes and automatic system already spits up at the order histories of this customer. And

before that the customer has says anything. The customer agent says to

anything. The customer agent says to Jeff she's going to return that table and indeed the customer returns wants to return the table because it's damaged.

Call is over and Jeff looks at the agent says how did you know that? She says,

"Well, 70% of those tables are coming back because there's some drop shipper that actually doesn't really know how to package them, right?"

Of course, you know, Jeff gets everybody in the room. Uh,

and start to think about sort of, you know, everybody go has good intentions.

No, of course, we don't want this to happen. But without a mechanism, nothing

happen. But without a mechanism, nothing changed because everybody already has good intentions.

So he introduced a new mechanism.

Amazon's version of Toyota's famous end court. So the end court in Toyota was

court. So the end court in Toyota was the principle was no car should leave the production line with a known defect

and then any engineer working on the line could pull this cord and bring the whole manufacturing line to a standstill

until the defect was fixed. the end cord that these um the customer service agents got was a button to make the

product uniable.

Yeah. That made alarms go off with the people that were responsible for the products to go and fix it. But you know before this everybody already had good

intentions but until we introduced the mechanism nothing changed.

Yeah. Now let's go back to the technology world. Mechanisms take many

technology world. Mechanisms take many forms. Each team builds their own one that fits the scale and the nature of their work. The S3 team for example uses

their work. The S3 team for example uses something which they call durability reviews. When an engineer proposes a

reviews. When an engineer proposes a change that might touch durability, they pause and model the risks. They write

down the changes.

They list every threat imaginable, map out the guard rails to keep the data safe and is a mechanism with a very

powerful effect. It turns durability

powerful effect. It turns durability from a property of code into the habit of the organization. It makes engineers

think in failure modes, not happy paths.

And it shows why mechanisms matter.

They convert good intentions into consistent outcomes.

Now if you think about it, [snorts] code reviews are also a mech mechanism and I know it. We all hate code reviews.

It's like being 12 year old and standing in front of the class. Yeah. But they're

a very important mechanism because they create a moment where intent and implementation meet where another

engineer can question assumptions and catch things that the author no longer sees.

In an AIdriven world, they matter more than ever. In an AIdriven world, they

than ever. In an AIdriven world, they are crucial.

Models can generate code faster than we can understand it. So the review becomes the control point to restore balance.

It is where we bring human judgment back into the loop and make sure that the software actually does what we expect it

to do.

I encourage all of you to continue and you increase your human to human code reviews.

When senior and junior engineers work through code together, it becomes one of the most effective learning mechanisms we have. Seniors bring pattern

we have. Seniors bring pattern recognition and high hard earned judgment.

Juniors bring fresh eyes and often spot details others overlook. This is how we transfer knowledge and how we grow the

next generation of builders.

AI will change many things but the craft is still learned person to person.

So the fourth quality in my eyes of the Renaissance developer is an owner.

You build it, you own it.

The last quality that I want to talk to you about is that I think you the future Renaissance developers

need to become a polymouth.

Now ma has nothing to do with math by the way. Yeah. It's not mathematics or maths

way. Yeah. It's not mathematics or maths or whatever you want to call it.

It actually the word polymath has nothing to do with that. It actually

means many because it comes from the the math comes from the Greek word matanian which means

to learn. It's about having deep domain

to learn. It's about having deep domain experience but also have knowledge that spans many different subjects. Dvinci

probably was the absolute best example of a polymath because he worked across so many different disciplines. He was a painter, he was an engineer, he was an

anatomist and he was an inventor. Yeah.

Now I do not expect you all to become a Da Vinci. Yeah.

Da Vinci. Yeah.

But you should expand your knowledge just beyond deep domain expectations.

Yeah. This is what I would call Yeah. an

eye developer.

An eyeshaped developer is someone who is really deep and really highly specialized in one area.

Let me tell you again an interesting story out of my own experience. This is

my uh old mentor and friend Jim Gray.

And Jim um got a touring award because actually you should all know Jim Gray because he's the inventor of transactions. Every

transaction you do today we have Jim to think for this. But he also had this great mind. He was interested in so many

great mind. He was interested in so many more things than just databases. And

this is one of his famous sort of challenges. Give me 20 questions, 20

challenges. Give me 20 questions, 20 important questions that you want to ask of your data and I will design the system for you.

One of the first ones he worked on was the uh the sky skylo the Sloan digital sky survey. This was one of the first

sky survey. This was one of the first massive data sets that were out there.

There's groundbreaking work in developing the sky server. Yeah. Jim's

indepth knowledge as a database expert was transformative for the computation in astronomy data.

This is actually a really funny story about that. At some moment uh Jim goes

about that. At some moment uh Jim goes to Philadelphia, Baltimore where um where the group group is and he walks into the server room. 30 seconds later,

he walks out and he tells them that their database layout is wrong.

And everybody looks at him and says, "How do you know that?" By just listening to the rattling of the discs, he knew that there was way too much

random access. His intuition built from

random access. His intuition built from decades of experience had given him a six sense of how systems should behave.

He advised him to redesign the architecture and performance improved dramatically.

Now Tim wasn't what I would call an eyeshaped developer at all. His

curiosity reached far beyond databases.

He understood people. He understood

business and he understood a wide range of technologies.

And like great technologist, I will describe him as T-shaped.

Yeah. Deep in one domain, but broad in understanding.

The skills you need to be successful in your job are a unique mix of personal skills, functional depth, industry

knowledge. A database developer who

knowledge. A database developer who understands front-end performance or cost aware architectures can make a better architectural choices because

they see how their work shapes the overall system.

That breath of knowledge gives you the perspective to improve what you build because you understand the trade-offs.

T-shaped developers combine depth with breath.

They can dive deep into a specific problems but will also understand how it fits into a larger system.

That is my advice to all of you. Build

both. Develop depth in your domain but cultivate cultivate the range to connect to

multiple disciplines and ideas.

So the last takeaway from the Renaissance developer is become a polymoth. Well, I don't expect you all

polymoth. Well, I don't expect you all to become that, but you should broaden your tea. Great developers are T-shaped.

your tea. Great developers are T-shaped.

They're experts in their field who understand their work fits into a larger system. You must broaden your tea.

system. You must broaden your tea.

Now if you look at sort of the Renaissance developer throughout this talk I've called them different ways.

Yeah. I think you need to be curious and keep learning.

thinking systems. Communicate with precision.

Be an owner. If you build it, you own it.

And finally, become a polyimoth.

Expand your knowledge.

Then you'll have plenty of time next week to start putting the all of this into practice.

But for tonight, yeah, join me at the Las Vegas Festival Grounds. There'll be great food, some

Grounds. There'll be great food, some crazy games, and of course, live music headlined by Beck and Cascade. It's a

chance to celebrate with your teams and unwind after a week of serious learning and building.

Now, there's one more thing.

I want you to leave you with this. Yeah.

When you build something like an app, do you customers ever thought about all the work that goes underneath there?

An Amazon customer will click a button and a package arrives.

Does it think about the people that actually maintain the catalog that make that do the supply chain all

of that work? Nobody sees that.

Yeah. Your customers are never going to tell you that your database engineers are doing amazing work and they love

what they've done. Only you

understand that work that goes into it.

I believe it is important for all of us to have pride in our work in the unseen systems that stay up for

the night in clean deployments. The

rollbacks that nobody notices.

Most of what we build nobody will ever see.

And the only reason why we do this well is our own professional pride in operational excellence.

That is what defines the best builders.

They do the things properly even when nobody's watching.

And when I look at the work that you deliver every day, I see that commitment everywhere.

So for that, I am immensely proud of you. Thank you for all that you do.

you. Thank you for all that you do.

Two more. Oh, [applause]

[applause] [applause] two more words.

Manor [screaming] out.

[cheering] Heat. Heat. [applause]

Heat. Heat. [applause]

[music] [applause] [music] Heat. Heat. N.

Heat. Heat. N.

[music] Heat.

Heat.

Heat. [music]

[music] Heat.

>> [music] >> Say [music] [music] >> [music] [music] [music] [music]

Sex Sex.

>> [music] [music]