(Illustration: AWS re:Invent 2025 Special Closing Keynote with Dr. Werner Vogels. Image source: AWS.)
Dr. Werner Vogels, AWS VP and CTO, delivered his final re:Invent keynote after 14 consecutive years since 2012. (Sigh, I was in the audience, feeling sad as I listened.) Instead of announcing new services, Werner presented “The Renaissance Developer” framework with five qualities that define how developers should evolve in the AI era. Guest speaker Clare Liguori demonstrated spec-driven development with the Kiro IDE, and Werner shared stories from his travels across Africa and Latin America to illustrate how developers are solving real-world problems.
✳️ tl;dr
One theme “The Renaissance Developer” runs throughout, with five qualities:
- Be Curious: Experimentation and willingness to fail, the Yerkes-Dodson Law (stress-performance curve), social learning and touching the grass, global travel stories (AJE, Ocean Cleanup, Rwanda Health Intelligence, KOKO Networks), AWS Heroes (265 across 58 countries) (waving).
- Think in Systems: Donella Meadows’ systems thinking, Yellowstone wolves and trophic cascades, reinforcing and balancing feedback loops, “Leverage Points: Places to Intervene in the System” paper.
- Communicate: Spec-driven development reduces ambiguity, historical examples (Dijkstra’s structured programming, Apollo Guidance System), Clare Liguori and Kiro IDE (from vibe coding to spec-driven development, feature-driven specs, notification system shipped in half the time), rapid prototyping (Engelbart’s mouse analogy).
- Be an Owner: Verification debt (AI generates code faster than you can understand it), hallucination challenges, mechanisms vs good intentions (Jeff Bezos / Amazon Andon Cord), S3 durability reviews, code reviews are more important than ever in the AI era.
- Become a Polymath: I-shaped vs T-shaped developers, Jim Gray (Turing Award, transactions, Sloan Digital Sky Survey), deep domain expertise combined with broad knowledge.
Contents
✳️ Structure
This 75-minute special closing keynote by Dr. Werner Vogels is structured around one theme and five qualities. Unlike traditional AWS keynotes packed with service announcements, this keynote is a philosophical and practical guide for developers navigating the AI era.
One theme “The Renaissance Developer” runs throughout, with five qualities:
- Be Curious
- Think in Systems
- Communicate
- Be an Owner
- Become a Polymath
The keynote opens with a pre-recorded drama video showing the evolution of developers through decades (from punch cards to COBOL to cloud to AI), followed by Werner’s announcement that this is his final re:Invent keynote. He draws a parallel between the historical Renaissance and the current moment in technology, arguing that just as curiosity, tools, and the printing press transformed society, AI is transforming development today.
The logic flows from individual mindset to broader impact. “Be Curious” starts with personal growth; “Think in Systems” expands to understanding complex interactions; “Communicate” bridges the gap between humans and machines; “Be an Owner” establishes responsibility in the AI era; and “Become a Polymath” synthesizes everything into a complete developer identity. This progression builds a framework where each quality reinforces the others, creating the Renaissance Developer.
✳️ Highlights
The Renaissance Developer
- The Renaissance Developer Framework
- Werner draws a parallel between the historical Renaissance and today’s technological moment
- Multiple golden ages converging simultaneously: space travel, artificial intelligence, robotics
- Progress in one field accelerates progress in others, just like the Renaissance
- Five qualities define the Renaissance Developer: Be Curious, Think in Systems, Communicate, Be an Owner, Become a Polymath
Quality 1: Be Curious
- Experimentation and Willingness to Fail
- Da Vinci made an airplane that never flew, but we are flying now
- An experiment is not an experiment if you already know the outcome
- Software works the same way: failed builds and broken assumptions teach you how a system behaves
- Yerkes-Dodson Law
- Bell curve relationship between stress and performance
- Too little pressure: disengaged; too much pressure: overwhelmed
- The sweet spot is on the rising slope where curiosity meets challenge
- You cannot reach that point by sitting comfortably
- Social Learning and Touching the Grass
- Learning is not just cognitive, it is social
- Get out of your usual environment: user groups, conferences, coffee with a friend
- One of the best ways to stay sharp is to be around other people who are building things
- Travel Stories
- AJE: Beverage company supporting communities along the Amazon River, giving young people economic futures so they do not leave their villages
- The Ocean Cleanup: 80% of ocean plastic originates from just a thousandth of the world’s 3 million rivers; AI cameras and GPS-tracked dummy plastics create computational models predicting plastic traffic
- Rwanda Health Intelligence Center: Near real-time data from four tiers of healthcare facilities, using data to strategically place new maternal health facilities in areas more than 30 minutes walk from a provider
- KOKO Networks (Nairobi): Ethanol ATM machines where people can buy five cents of gas to cook their food, replacing carbon burning in poorer communities
- AWS Heroes and Now Go Build
- 265 AWS Heroes across 58 countries
- Now Go Build award goes to Raphael Quisumbing, co-leader of AWS user group in the Philippines since 2013
- Embodies the Renaissance Developer: builds communities, mentors others, writes code
Quality 2: Think in Systems
- Donella Meadows and Systems Thinking
- In the 1970s, ecologist Donella Meadows began studying how complex systems behave
- “A system is a set of things interconnected in such a way that they produce their own patterns of behavior over time”
- Systems have lives of their own; our software systems are no different
- Yellowstone Wolves and Trophic Cascades
- Wolves were removed from Yellowstone National Park in the early 20th century
- Expected result: fewer predators meant more elk, more life
- Actual result: valleys overgrazed, trees disappeared, rivers began to erode
- When wolves were reintroduced, vegetation returned, beavers came back, rivers changed course
- The wolves did not move the rivers; they changed the behavior of the overall system
- Feedback Loops
- Every dynamic system is shaped by feedback loops
- Reinforcing loops (positive loops) amplify change
- Balancing loops (negative loops) counteract change and push the system back into equilibrium
- Every service, API, and queue is part of a larger system; you cannot change one part in isolation
- Leverage Points
- Donella Meadows’ paper “Leverage Points: Places to Intervene in the System”
- Once you see patterns, you start to see where small well-placed changes might shift the overall system behavior
- To build resilient systems, you need to understand the bigger picture
Quality 3: Communicate
- Specifications Reduce Ambiguity
- Natural language is ambiguous; programming languages were precise
- In the AI era, we increasingly communicate with machines in natural language
- Need mechanisms to reduce ambiguity so the machine can create logic
- Historical Examples
- Dijkstra’s structured programming: formal specifications that proved program correctness before implementation
- Apollo Guidance System: meticulous specifications guided 145,000 lines of code to land people on the moon
- Clare Liguori and Kiro IDE
- From vibe coding to spec-driven development
- Problem: longer and more detailed prompts to describe what software should do, essentially creating specifications
- Feature-driven specs separated into three documents: requirements, designs, and tasks
- Notification system case study: spec process helped realize the project was bigger than expected, iterated on specs, shipped in roughly half the time compared to vibe coding
- Kiro IDE was built using Kiro IDE itself
- Rapid Prototyping
- Engelbart’s mouse (1964): a wooden shell with wheels and a button communicated better than any drawing or description
- AI has fundamentally enabled rapid prototyping for software
- What used to take months of manual coding can now produce real working prototypes in minutes
Quality 4: Be an Owner
- Verification Debt
- AI can generate code faster than you can understand it
- Code arrives instantly, but comprehension does not
- That gap allows software to move towards production before anyone has truly validated what it does
- Hallucination
- Models produce designs that look confident but are completely wrong for the architecture
- APIs change and LLMs invent attributes that do not exist
- Sometimes propose solutions that are over-engineered or ignore the system’s constraints
- Mechanisms vs Good Intentions
- Jeff Bezos story: customer service agent knew 70% of tables were being returned due to poor packaging
- Everyone had good intentions, but without a mechanism, nothing changed
- Amazon’s Andon Cord: button to make a product unviable, triggering alarms for responsible teams
- Inspired by Toyota’s Andon Cord: no car should leave the production line with a known defect
- S3 Durability Reviews
- When an engineer proposes a change that might touch durability, they pause and model the risks
- Write down changes, list every threat imaginable, map out guardrails
- Turns durability from a property of code into a habit of the organization
- Code Reviews in the AI Era
- Code reviews are a mechanism where intent and implementation meet
- In an AI-driven world, they matter more than ever
- The review becomes the control point to restore balance and bring human judgment back into the loop
- Senior engineers bring pattern recognition; junior engineers bring fresh eyes
- The craft is still learned person to person
- “The work is yours, not the tools”
- Vibe coding is fine, but only if you pay close attention to what is being built
- If AI creates code that violates regulatory requirements, you cannot blame the AI
- Responsibility remains with the developer
Quality 5: Become a Polymath
- I-Shaped vs T-Shaped Developers
- I-shaped developer: deep and highly specialized in one area
- T-shaped developer: deep in one domain, but with broad understanding across multiple disciplines
- Great developers combine depth with breadth
- Jim Gray
- Turing Award winner, inventor of transactions
- Worked on the Sloan Digital Sky Survey, one of the first massive datasets
- Could diagnose database layout problems by listening to disc rattling (too much random access)
- His curiosity reached far beyond databases: understood people, business, and a wide range of technologies
- Breadth Enables Better Depth
- A database developer who understands performance and cost-aware architectures makes better architectural choices
- Breadth of knowledge gives perspective to improve what you build because you understand the trade-offs
- Build both: develop depth in your domain, cultivate range to connect to multiple disciplines and ideas
✳️ Watch the Video
Content from AWS re:Invent 2025. Full session: AWS re:Invent 2025 - Keynote with Dr. Werner Vogels.
✳️ Knowledge Graph
(More about Knowledge Graph…)
Overview
Renaissance Developer Lifecycle
✳️ Transcripts
Opening Drama & Farewell
- (pensive music) (computer bleeping) (phone ringing) (newspaper rustling) - Mm.
- End of the developer.
- I’ve heard that before.
- (gentle ethereal music) (footsteps tapping) (gentle suspenseful music) (door clicks and creaks) (gentle suspenseful music) (electricity crackling) (car door hisses and clicks) (sunglasses click) (monitor beeping) (palms rustling) (buttons beeping) (engine whirring) (car engine revving) (electricity crackling) (Werner shouting) (suspenseful music) (car engine whirs) (pensive music) (office workers chattering) (cards rustling) (buttons clicking) (cards thudding) (Lorraine sighs) (chair thuds)
- 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 in the bogo compiler, and talking to you.
- Anything new at head office?
- I’ve been reading about this, uh, COBOL.
- Yes, that’s the new high level language.
- It’s amazing.
- Now, anyone can write code.
- (newspaper rustles) - I don’t know about anyone.
- Writing software is pretty tricky.
- Soft, what?
- Software.
- Where?
- (suspenseful music) (buttons beeping) (machine whirring) (Werner shouting) (suspenseful music) (upbeat music) Hey, Marty, what you reading?
Opening Drama: Developer Evolution
- Just learning some VP.
- Visual Programming, huh?
- (scoffs) 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.
- (monitor warbling) (gentle chimes music) - Everything fails all the time.
- (bell dings) (suspenseful music) (electricity crackling) (Marty sighs) - Is this for real?
- Could cloud mean there will be less engineers?
- [Werner] Less engineers.
- (chuckles) Time for an air drop.
- (book whooshes) (book thuds) - Huh?
- Servers in minutes.
- Scale on demand.
- Pay as you go.
Opening Drama: Transition to Keynote
- Wow.
- (chuckles softly) You learn something new every day.
- (electricity crackling and whirring) (exciting music) - You build it.
- You run it.
- Mom.
- Hi, sweetie, don’t forget to call Mom.
- Hi, there, Marty, it’s a nice wormhole, isn’t it?
- Mind if I join you?
- Oi, you can skip this worm.
- Is this the end of development as we know it?
Werner’s Farewell Announcement
- Or is it just another new beginning?
- (triumphant music) (car engine revving) (monitor beeping) - [Announcer] Please welcome the vice president and CTO of Amazon.com, Dr. Werner Vogels.
- (upbeat music) (audience clapping) (audience cheering) - [Audience] Werner, Werner, Werner, Werner, Werner.
- Werner, Werner, Werner, Werner, Werner.
- (Werner chuckles) - Thank you, okay.
- [Audience] Werner, Werner.
- First, I seek and I find in you something new for us every.
- No, 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.
- So, the video showed you every generation of developers that face the new wave of change, yeah?
- Tools evolve, architectures evolve, expectations evolve, and so do we.
- But before we talk about that, (Werner clears throat) let’s talk about the elephant in the 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 streak ends.
- This is my final re:Invent keynotes.
- (audience gasping) I’ve still things to do.
- I’m not leaving Amazon or anything like that.
- But I think that after 14 of re:Invents, 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.
- By the way, nobody forces me to do this.
- I’m not leaving Amazon or anything like this.
- This is my decision to make sure that you get to hear different voices than just mine.
- Now, let’s talk about the other elephants in the room.
- I visited AWS customers all over the world, and there is one question that keeps coming up in every country and in every city.
Evolution of Development and The Renaissance Analogy
- Will AI take my job?
- Maybe.
- (audience laughing) Or else transform.
- Some tasks will be automated, some skills will become obsolete.
- Nuance will emerge.
- So, maybe we should rephrase and reframe this question.
- Will AI make me obsolete?
- Absolutely not.
- If you evolve.
- And if I look at the past years at Amazon where we’ve been using all of 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.
- And so must our tools.
- And so, change is constant.
- And this has always been the case, it’s nothing new.
- Let’s go back in time a little bit.
- Just for the heck, when I went to school, I was taught 68,000 Assembler, COBOL and Pascal.
- None of these languages are being used anymore.
- And in the ’60s, we certainly got compilers, and you didn’t really matter anymore what kind of assembly those compilers spit out.
- However, by learning assembly, I knew, I learned how that loop in Pascal actually translated into machine code.
- And so, that was important to me.
- And over time, compilers became the highest level of abstractions that most developers needed.
- In the ’70s, suddenly structured programming became popular.
- And we’re moving towards that, compilers, and Bell Labs and Berkeley, they supported this shift.
- They give developers a clearer, control overflow and help them escape the chaos of unstructured code.
- And then, a few years later behind the stress trap, 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.
- In the ‘98, and this is its famous moment, the growth accelerated to such a point that the team began breaking off pieces of this monolith into services.
- And each service had ownership of their servers, had their own interface, and they completely changed how developers worked.
- They had moved faster, they became 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 operating large scale distributed systems.
- Actually, and what about the tools in those days?
- But in the 2000s, the most developers, they were still building and deploying things on premise.
- And writing code meant wrestling with hardware, capacity planning, long procurement cycles.
- And when cloud services arrived, they changed the expectation of the world again.
- Developers suddenly had owned amount infrastructure, freedom to experiment.
- We now waiting for hardware.
- And this required new skills.
- And developers everywhere adopted 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 EMAX person.
- (audience cheering and clapping) Just to say.
- And IDE, actually, they involved with us.
Evolution of Tools and the Golden Age
- We got Microsoft at some moment, you could draw boxes on the screen and you had this first real IDE.
- And later we got Visual Studio.
- And then Visual Studio Code became the default, ‘cause of all the amazing plugins in all of that.
- And today’s environment, our cursor and (indistinct), and that’s the new workflow.
- Is there a new workflow next year?
- Five years from now?
- 10 years from now?
- Of course, there is.
- Our tools today though I think are kind of extraordinary.
- 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.
- Our tools have changed so many times over the course of my career, and they will continue to change.
- We are still builders, we’re still important.
- Nothing has changed.
- There’s never been a time to be more excited about being a developer.
- Bezos, not that long ago in an interview, he talked about this that we are living at the epicenter of a multiple simultaneous golden ages coming together.
- Space travel, artificial intelligence, robotics.
- Each are advancing at an incredible pace.
- But what makes this moment different is how these breakthroughs actually reinforce each other.
- Progress in one field accelerates progress in 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, came after a period of darkness.
- The Dark Ages.
- The Middle Ages.
- The def plague.
- And anyone who knows Monty Python knows about how that looked like.
- But the Renaissance was a period where everything changed because people became curious.
- Curiosity was absolutely exploding.
- And the result of that is amazing scientists and philosophers.
- And if you look at this, de Medici is probably the first version of a venture capitalist or philanthropist, or whoever you want to name it.
- Galileo and Copernicus were amazing scientists.
- Petrarch, one of the first philosophers.
- Da Vinci, 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.
- The fact that they start thinking about something called a vanishing point.
- Well, certainly, that if you compare paintings and drawings before the Renaissance, they were all flat.
The Renaissance Analogy
- 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.
- (audience chuckling) Not saying anything.
- And then, the printing press, of course, we all see as sort of the pinnacle of invention in the Renaissance.
- But that was not just one invention.
- Gutenberg actually used a wine press as his first 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, people on present.
- Imaginary, almost imaginary in those days.
- It was a time where art and science were part of the same conversation.
- Creativity and technology evolved together.
- I’ve spent some time to think about what made people so effective in that world.
- They were curious.
- They questioned assumptions.
- They learned broadly and applied that learning deeply.
- They didn’t see boundaries between fields.
- They built britches between them.
- They were also 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 the time of Renaissance.
- And you are the new Renaissance Developer.
- Those qualities of those scientists in the 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 crucial in all of this?
- It’s 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 it’s also what drives us here.
- The desire to understand, to improve, to build, you have to protect that instinct.
- Stay curious, ‘cause curiosity leads to learning and invention.
- Equally important for learning is two things.
- For all new inventions you need to experiment, and to experiment well, you need to be willing to fail.
- After all, Da Vinci made an airplane that never flew, but we are flying now.
- And by the way, an experiment is not an experiment if you already know the outcome.
- It drives experimentation, drives to learning.
Quality 1: Be Curious
Experimentation, Failure, and Social Learning
- And this willingness to fail is crucial.
- When I learned a new language, I read that this Dutch or English or Portuguese or German, I find that the same principles apply.
- The best way to learn is fail and be gently corrected.
- You can study grammar all you like, but relearning begins where you stumble into a conversation, and stumble helps you to get it right.
- Software works the same way.
- You can read documentation endlessly, but it is the failed built 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 relearning happens when you engage, when there’s some pressure, when the outcome matters.
- There is a relationship between stress and performance called the Yerkes and Dodson Law.
- The picture is a bell curve, too little 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 fully alert, focused, and ready to grow.
- You can’t reach that point by sitting comfortably.
- You have to put yourself in positions that test you.
- Now, there’s a whole story behind this.
- And that newspaper that you all found on your seats today, “The Kernel,” there’s an article in there by Andy Warfield who writes about this.
- I urge you all to read that article if you really want to understand more of that.
- Now learning, there’s another side to it.
- Learning is social.
- We’re not here only to sit in the room and listen to one person telling you exactly what to do.
- The thing you really learn is by talking to each other.
- Learning isn’t just cognitive, it is social.
- You have to touch the grass occasionally.
- And by that I mean, you have to get out of your usual environment.
- Go to a user group, attend to conference like re:Invent.
- I 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, very fortunately, I took two-month long trips.
- One to Africa, trip to Sahara, Africa, and the other two, Latin America.
- In both regions I gave some talks with the mostly meet with customers.
- And the real thing I do is learning from those customers.
- Here are a few examples.
- Here’s AJE.
- This is actually also, it took me 21 years to actually end up on the Amazon.
- And so, a group of AJE 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 and a great example of how doing good can be profitable at the same time.
- The Amazon River was beautiful.
- I saw pink dolphins.
- But it reminded something else that I learned that not all of this is so great.
- Early in the year, I spoke with Boyan Slat from The Ocean Cleanup project during an episode of “The Frugal” podcast.
- And he taught me that 80% of the plastic found in the ocean originates from just a thousandth of the world’s 3 million rivers.
- With 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 mobile using drones, AI camera analysis, even GPS tracks dummy plastic in the place where we went onto the Amazon near Manaus, they actually took plastics and put GPSs in the foods in the river, see where ended up.
- Turns out the Amazon is not a big polluter at all.
- But this computational model that they’ve built, these AI cameras that are on bridges, that are on the back of ships.
- 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.
- In Rwanda, this is the headquarters of the Ministry of Health.
- And this is the health intelligence center.
- In the operations centers, huge screens display near real time data from four different tiers of healthcare facilities across the country.
- They’ve built an impressive system that ingests and processes vast amount of healthcare data, visualizing everything from disease outbreaks to maternal health outcomes.
- And they use it to create new policies.
- They’ve created this model which shows that which parts of the country are more than a 30-minute walk away from a healthcare provider.
Travel Stories and AWS Heroes
- 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 in Nairobi.
- And I learned that in many places there, people will just borrow a dollar or $2 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 poorer parts, it’s all burned on carbon, which is massively polluting.
- So, it is young company called KOKO Networks.
- They came up with a completely different solution.
- They basically built these kind of ATM machines with ethanol in them, and a small canister that people have.
- And they can basically walk up to the machine, plug in their canister and ask for five cents of gas, which will be enough to cook their food that night.
- This is what happens when developers apply their skills to real human challenges.
- Developers have always driven progress.
- You have built the foundations of the digital world, and today, you are the ones tuning, turning to AI 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 2 billion more people on this planet.
- How are we gonna feed them?
- How are we gonna make sure we have an economic future?
- How can we make sure we 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 some of you who spent 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.
- We now have 200.
- (audience clapping) Yeah, they deserve an applause.
- They’re there.
- So, I’ve met community builders, I’ve met AWS Heroes, and these are people that are solving heart problems in their own corners of their world.
- There are 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 awards goes to Raphael Quisumbing.
- Stand up, Raphael.
- [Audience] Raffy, Raffy, Raffy, Raffy, Raffy, Raffy.
- Raffy absolutely embodies the Renaissance Developer.
- He doesn’t just write codes, he builds communities, he mentors others and he co-leads the AWS user group in the Philippines since 2013.
- Come on, Raffy, one more round applause for him.
- So, the first quality I think that a Renaissance Developer needs to have is to be curious.
- And I like this quote from Walt Whitman, “We are not what we know, but what we are willing to learn.”
Quality 2: Think in Systems
- Another quality that I think the Renaissance Developer has is that he thinks in systems.
- And just come with me for a moment.
- If you don’t really understand, I don’t mean the computer system in this case, but in a big system.
- So, in the ’70s, an ecologist called Donella Meadows began studying how complex systems behave.
- She wasn’t even a computer scientist, but her insights describe our world of software perfectly.
- And she wrote, “A system is a set of things, people, cells or whatever, interconnected in such a way that they produce their own patterns of behavior over time.”
- 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 examples of systems comes from ecology.
- In the early 20th century, the wolves were removed from Yellowstone National Park.
- It seems logical.
- Few predators meant more elk, meant more life.
- (wolves howling) But the opposite happened.
- The valleys were overgrazed, the trees disappeared, the rivers began to erode.
- And this phenomena is called the trophic cascades.
- When we reinduced in 2010, wolves back into the park, slowly the park started to heal.
- Vegetation returned, beavers came back.
- Even rivers changed course.
- The wolves didn’t move the rivers, they changed the behavior of the overall system.
- That single feedback loop, predator and prey, reshaped the balance of the entire system.
- And then, structure changes, 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 isolation, alter or rewrite policy and you affect load.
- You add a cache, then you change traffic load, you change traffic 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.
Feedback Loops and Leverage Points
- Reinforcing loops, sometimes called positive loops, amplify change.
- Balancing loops or negative loops counteract, they change and push the system back into an equilibrium.
- Meadows thought that once you see patterns like this, you start to see where small well placed changes might shift the overall systems behavior.
- Donella wrote a paper, a (indistinct) paper, it’s called “Leverage Points: Places to Intervene in the 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.
- Take a picture of the QR code, and that’s your homework for the coming week.
- The Renaissance Developer thinks in systems.
- And to build resilient systems, you need to understand the bigger picture.
Quality 3: Communicate
- If I think about a third quality of the Renaissance Developer, it’s communication, he/she communicates.
- 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 technical leader can do for their career is to practice, develop strong communication skills.
- Let’s go back two years when we did “The Frugal Architect.”
- Don’t know if you remember this picture, this is 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’s absolutely necessary to make the system work.
- Search, browse, shopping cart, checkout and reviews.
- Without those five things, the site doesn’t 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.
- To be able to do this, it’s important not just for us as engineers, but as communication tools towards the business.
- You go and sit round 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 nines.
- Tier three, maybe you don’t care at all, two nines.
- We think, well, we’ll do a manual fail if data center goes offline.
- But it’s a communication that you need to have, you need to be able to clearly describe your system and the capabilities and your opportunities towards the business.
- Communication is crucial.
- Now, human languages, it’s a bit of a challenge, isn’t it?
- ‘Cause natural language is ambiguous.
- But we have so many different senses at the same time that we can turn this natural language into something less ambiguous.
- Do we put grandma on the grill, or are we having dinner tonight?
- Even without a comma, you probably already have figured this one out.
- Now, we’ve always communicated to machines through programming languages, because they were precise.
- We could precisely indicate to the machine what we wanted it to do.
- But in today’s world of AI assisted coding, we increasingly communicate with the machine in natural language, which is ambiguous.
- So, we need to help to develop mechanisms to reduce the ambiguity of that language.
- And reduce the ambiguity of the human so that the machine can create logic.
- Specifications reduce ambiguity.
- And our history is rich with stories of spec-driven development.
- Dijkstra’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 has helped land people on the moon.
- And to talk more to you about specifications, I’d like to welcome Clare Liguori, senior principle developer on the Kiro team.
- Clare, up to you.
- (audience clapping and cheering) - Thank you, Werner.
- 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 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 mark 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 Werner said, many systems in history have been based on specifications like Apollo missions.
- It felt like specifications were exactly what was missing from my interactions with my coding assistant.
- But then I thought, how could we use this idea of specs as prompts?
- What would spec-driven development look like?
- And this spark of an idea led us to start work on the Kiro IDE.
- With this idea though, we now had a new communication challenge, how can we communicate and validate this idea with potential users?
- We didn’t know what it would look like and we didn’t know what users wanted.
- It was also kind of difficult to describe what spec-driven development was.
- They hadn’t seen it before and we hadn’t built it yet.
- One of the best ways to get your ideas across is to quickly build a prototype, something that your users can see and touch.
- Rapid prototyping is of course not a new idea.
- Let’s go back to the ’60s to the time of punch cards.
- In 1964, Doug Engelbart at SRI had a rough idea for a device that had wheels on the bottom, and you would slide it across the tabletop to point to something on a computer screen.
- And we can probably all picture this device in our head.
Clare Liguori and Kiro IDE
- But can you imagine going back to the ’60s and trying to describe what a mouse is to this guy?
- Engelbart’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 ergonomics, it felt great in their hands.
- And like the mouse, rapid prototyping was crucial for Kiro.
- We knew that the ergonomics of spec-driven development was going to be important, how it felt in the hands of a developer.
- We rapidly built prototypes of how we thought spec-driven development could work.
- And we put those prototypes in the hands of some internal users, and we asked them to use Kiro every day.
- That was going to be the best way for us to understand what felt good and what didn’t feel good.
- This is a great example of what AI can do for us now.
- AI has fundamentally enabled rapid prototyping for software.
- 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 and minutes to get feedback about what feels right.
- Rapidly prototyping Kiro even let us use Kiro to build Kiro.
- Our very first prototype of the Kiro IDE could only do vibe coding.
- But from that moment on, we were able to use the Kiro IDE to generate the code for the Kiro IDE.
- And by using the Kiro IDE to build out the product, we were able to iterate through many ideas of how spec-driven development could work.
- One idea was test-driven development specs, taking inspiration from TDD techniques.
- You would describe a change that you wanted and Kiro would generate tests to validate the behavior that you described.
- Kiro would then generate application code and made sure that it passed those 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 Werner described for the Apollo Guidance System.
- They described the system as a whole and each component in detail.
- With this, you’d add a new feature to the overall spec, and Kiro would kick off coding tasks based on the changes that you described.
- These specs were great context for the AI and even for developers who weren’t very familiar with this code base.
- But for real world projects, they sometimes became overwhelmingly long.
- So, it was difficult to figure out where in this long spec you should put your changes for your new feature.
- We took a step back and 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 requirements, review a design doc, and create sprint tasks.
- And we thought that perhaps specs could follow this 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 spec-driven development workflow that’s in the Kiro IDE.
- With a spec workflow now in place in Kiro, we could use it more effectively to keep building out the product.
- Because 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 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 vibe coding, the AI is going to take its best guess as to what you meant, it’ll generate code, but that leaves you to iterate on the code with the AI instead of on what you originally meant.
- With spec-driven development, you have an opportunity to refine what you mean more precisely through specs.
- You can give the Kiro IDE that same ambiguous task, but instead of jumping into the code right away, it’s going to first generate requirements, designs, tasks.
- And if those don’t match what’s in your head, you have the opportunity to ask Kiro to change it and refine it.
- Let’s walk through a real example of a production feature that we built in the Kiro IDE using spec-driven development system notifications.
- We started here with a little annoyance that we ourselves experienced with an early version of the Kiro IDE.
- Agents can take a while to complete their coding work, and meanwhile, we would switch away to a different app, but then the agent would need user input or it would complete its work, and we would have no idea that it was sitting there idle while we were away doing other work.
- So, we set out to build a feature that would notify the user when the agent needed its attention.
- We started by having Kiro generate a spec and the generator requirements actually helped us 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 Kiro agent code.
- But instead, Kiro generated this very complex design that would build an entirely new notification system directly in our agent code.
- Now, if we had vibe coded this, we would’ve ended up with a lot of code that we didn’t actually want.
- But instead, the spec process helped us quickly realize this was a much bigger project than we originally thought.
- We iterated on the spec to first focus on building a notification system directly outside of the agent code, and directly in the underlying IDE code.
- This needed to be built on top of electron’s native notification API.
- Kiro IDE is based on code OSS, which is a code base that spans 10 years of development and 2 million lines of code.
- It can be difficult for any developer to figure out where they need to make changes in this code base.
- But Kiro spec workflow actually helped us to explore and understand where these changes needed to be made.
- And once these changes were in place, we were again able to use spec-driven 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 spec-driven development, we shipped this agent in roughly half the time as if we had vibe coded it.
- In our experience building Kiro, we realized that AI has changed how we communicate and how fast we can iterate.
- We can iterate on the software design by communicating with the AI through specs, and we can iterate on what the software does by putting real working applications fast into our users’ hands and get feedback.
- AI and spec-driven development helped us to build a better Kiro IDE, and this was in large part due to more precise communication with our users through rapid prototypes, and with AI through specs.
- Natural language doesn’t have to mean high ambiguity.
- And personally, this is what I think makes Kiro IDE so special.
- Kiro IDE brings precision to natural language.
- And with that, I’ll hand it back over to Werner.
- (audience clapping) (upbeat music) - Thanks, Clare.
- Communication is so important that Clare shows, it leads to systems that have fewer mistakes.
- Actually, let me get tell you a story again, sort of, outta my own youth.
- When I went 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, like 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 GenAI?”
- And then, because you really trained in trying to figure out into depth, say I’m 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.
Quality 4: Be an Owner
- Now, let’s go to the fourth, what I call the fourth quality of the Renaissance Developer.
- 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.
- AI will let us build things, bigger systems, explore more ideas, move faster than ever before.
- These tools will, as the modern day philosophers Daft Punk 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.
- Vibe coding is fine, but only if you pay close attention to what is being built.
- We can’t just pull a lever on your IDE and hope that something good comes out.
- That’s not software engineering, that’s gambling, and you need to be out there somewhere for that.
- Remember what I said at the beginning, the work is yours, not the tools.
- If you subject to regulatory requirement, let’s say, healthcare, financial services and whatever, if AI creates some code that certainly violates the regulatory requirement, you can’t go to the regulator and say, “Oh, it 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, ‘cause generation is so fast, you will review more code because understanding it takes time.
- And when you write a code yourself, comprehension comes with the act of creation.
- When the machine writes it, you’ll have to rebuild that comprehension during review.
- That’s what’s called verification debt.
Mechanisms vs Good Intentions
- 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, 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.
- Clare showed really a perfect example of that earlier.
- The model produced the design that looked confident but was completely wrong for the architecture.
- Some APIs change and LMS invent attributes that do not exist.
- Sometimes they propose solutions that are completely inappropriate or over-engineered, or ignore your system’s own talents.
- These outputs look plausible, but they’re not grounded in reality.
- I think we’re making progress there.
- We’re developing practices that like spec-driven development, which Clare showed how it can dramatically improve quality.
- Byron (indistinct) keynote showed how tools like Kiro 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 codes generated against AWS APIs is correct.
- I also see many developers looking at their CICD pipelines, then build in more and more automated testing.
- These are all types of mechanisms.
- Here, I wanna make a change.
- 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, again, going back a little bit in the past, and tell you a story about Jeff Bezos.
- In the early days of Amazon, as we as executives were required each year to spend two days with customer service, and take calls from customers so that we would truly understand what the customers were going through.
- And not just (indistinct) executives, Jeff himself (indistinct).
- So, Jeff sits next to this customer service agent.
- Phone goes and automatic system already spits up the order, histories of this customer.
- And before that the customer says anything, the customer agent says to Jeff, “She’s gonna return that table,” and indeed the customer wants to return the table because it’s damaged.
- Call us over, and Jeff looks at the agent says, 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, Jeff gets everybody in the room and starts to think about sort of, (indistinct) has good intentions.
- No, of course we don’t want this to happen.
- But without a mechanism, nothing changed because everybody already has good intentions.
- So, he introduced a new mechanism, Amazon’s version of Toyota’s famous Andon Cord.
- So, the Andon Cord 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 cords and bring the whole manufacturing line to a standstill until the defect was fixed.
- The Andon Cord that the customer service agents got was a button to make the product unviable.
- That made alarms go off if the people that were responsible for the products to go and fix it.
- But before this, everybody already had good intentions, but until we introduced the mechanism, nothing changed.
- Now, let’s go back to our technology world.
- Mechanisms take many forms.
- Each team builds their own one that fits the scale, that new nature of their work.
- The S3 team, for example, uses something which they call durability reviews.
- When an engineer proposes a change that might touch durability, they pause, and model the risks.
- They write down the changes, they list every threat imaginable, map out the guardrails to keep the data safe, and is a mechanism with a very powerful effect.
- It turns durability from a property of code into the habit of the organization.
- It makes engineers think in failure modes, not happy paths.
- And it shows why mechanisms matter.
- They convert good intentions into consistent outcomes.
- Now, if you think about it, code reviews are also a mechanism.
- And I know it, we all hate code reviews.
- It’s like being 12-year-old and standing in front of the class, yeah?
- But they were very important mechanism because they create a moment where intent and implementation meet.
- Where another engineer can question assumptions, and catch things that you alter no longer sees.
- In an AI driven world, they matter more than ever.
- In an AI driven world, they are crucial.
- Models can generate code faster than we can understand it.
- So, the review becomes the control point to restore balance.
- It is where we bring human judgment back into the loop, and make sure that the software actually does what we expect it to do.
- I encourage all of you to continue and 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 recognition, and high hard-earned judgment.
- Juniors bring fresh eyes and often spot details.
- Others of, look, 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 wanna talk to you about is that, I think, you, the future Renaissance Developers, need to become a polymath.
Quality 5: Become a Polymath
- Now, it has nothing to do with math, by the way.
- It’s not mathematics or maths, or whatever you want to call it.
- The word polymath has nothing to do with that.
- It actually means many because the math comes from the Greek work manthanein, which means to learn.
- It’s about having deep domain experience, but also have knowledge that spans many different subjects.
- Da Vinci probably was the absolute best example of a polymath because he worked across so many different disciplines.
- He was a painter, he was an engineer, he was an economist and he was an inventor.
- Now, I do not expect you all to become a Da Vinci.
- But you should expand your knowledge just beyond deep domain expertise.
- This is what I would call an I-developer.
- An I-shape 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 old mentor and friend, Jim Gray.
- And Jim got a Turing 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 thank for this.
- But he also had this 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 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 Sloan Digital Sky Survey.
- This was one of the first massive data sets that were out there.
- It was groundbreaking work in developing the SkyServer.
- Jim’s in-depth knowledge as a database expert was transformative for the computation in astronomy data.
- There is actually a really funny story about that.
- At some moment, Jim goes to Philadelphia, Baltimore, where the group is, and he walks into the server room.
- 30 seconds later, he walks out and he tells them that a database layout is wrong, (machine rattling) 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.
- This intuition built from decades of experience, had given him a sixth sense of how systems should behave.
- He tries him to redesign the architecture and performance improved dramatically.
- Now, Jim wasn’t what I would call an I-shaped developer at all.
- His curiosity reached far beyond databases.
- He understood people, he understood business, and he understood a wide range of technologists.
- And my great technologist, I will describe him as T-shaped.
- Deep in one domain, but brought an 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 understands font and performance or cost aware architectures can make a better architectural choices because they see how their work shapes the overall system.
- That breadth of knowledge gives you the perspective to improve what you build because you understand the trade-offs.
- T-shaped developers combine depth with breadth.
- They can dive deep into a specific problems, but we’ll 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 polymath.
- Well, I don’t expect you all to become that, but you should broaden your T. Great developers are T-shaped.
- They’re experts in their field who understand their work fits into a larger system.
- You must broaden your team.
Closing & Call to Action
- Now, if we look at sort of the Renaissance Developer throughout the stock, I’ve called them they different ways.
- I think you need to be curious and keep learning.
- Think in systems, communicate with precision, be an owner.
- If you build it, you own it.
- And finally, become a polymath, expand your knowledge.
- Then, you’ll have plenty of time next week to start putting all of this into practice.
- Before tonight, join me at the Las Vegas Festival Grounds.
- There’ll be great food, some crazy games, and, of course, live music headline by Beck and Kaskade.
- And 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.
- When you build something like an app, do customers ever thought about all the work that goes underneath there?
- An Amazon customer will click a button and the package arrives.
- Does it think about the people that actually maintain the catalog, 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 built, 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.
- Two more.
- Oh.
- Two more words.
- Werner out.
- (remote clatters) (bright music) (bright music continues)
✳️ Reference
- AWS re:Invent 2025 - Keynote with Dr. Werner Vogels - Full keynote video on YouTube
- Amazon Kiro - Agentic IDE for specification-driven development
- The Frugal Architect - Werner Vogels’ cost-aware architecture framework from re:Invent 2023
- Leverage Points: Places to Intervene in a System - Donella Meadows’ seminal 1999 paper on systems thinking
- The Ocean Cleanup - Nonprofit developing technologies to remove plastic from oceans and rivers
- KOKO Networks - Clean cooking fuel and technology solutions for cities in Africa and India
- AWS Heroes - Community program recognizing technical leaders worldwide
- Jim Gray (computer scientist) - Turing Award winner, pioneer of transaction processing and database systems