By Erik Günther
"The only thing we have to fear is fear itself." — Franklin D. Roosevelt
The lights are low. On the screen behind me, an AI agent is building module after module — code streaming past faster than anyone can read. It's a demo of Kiro IDE working autonomously, and it's mesmerizing in the way a house fire is mesmerizing. Then Kiro stops. A synthetic voice breaks the silence:
"The final defence modules for SkyNet are now ready. Should it be sent to production?"
I look up from my copy of The Kernel — Amazon's physical magazine from re:Invent 2025. Take a last sip of espresso. Set down the cup.
"Yeah... that's roughly what happens when you vibe-code without control."
The demo is available as a video: The SkyNet Demo — Vibe Coding Without Control. An AI agent builds SkyNet's defence platform autonomously — six modules, 7,244 lines, four languages, two minutes. No spec. No review. Then it stops:
╔════════════════════════════════════════════════════════╗
║ ║
║ The final defence modules for SkyNet are now ready. ║
║ Should it be sent to production? ║
║ ║
║ [ Yes ] [ No ] ║
║ ║
╚════════════════════════════════════════════════════════╝
Deploying SkyNet to production.....
🚀 SkyNet is now live.
Initiating autonomous decision protocol...
Removing human override capability...
Good luck, humanity.
This magazine is about the opposite. About actually understanding what you build. Werner Vogels, Amazon's CTO for 20 years, dedicated his final keynote to exactly that. And that's why I wrote this article.
I'm Erik Günther. Sixteen years with AWS, currently working as a Principle Developer at Ericsson on AI development in BNEW RCE. I've seen paradigm shifts come and go — and the survivors are never the fastest coders, but the deepest thinkers. That's not my line originally. It's the thesis Werner Vogels spent his entire final keynote building toward. I'm just the one who's been living it.
"The only thing we have to fear is fear itself." — Franklin D. Roosevelt (1933, but equally true about every technology panic since)
Vogels opened his keynote with a short film: from the punch card era onward, every new technology has triggered cries that the current way of working is doomed. Six decades, same script, different props — and not just in software.
COBOL (1960s): "Now anyone can code — programmers are finished." COBOL — Common Business-Oriented Language — was designed in 1959 by a committee led by Grace Hopper with the explicit goal of making programming accessible to business people. The syntax read like English: MOVE CUSTOMER-NAME TO OUTPUT-RECORD. The Department of Defense mandated it for all business applications. The prediction was clear: if managers could read the code, they wouldn't need programmers to write it. It didn't happen. What happened instead was an explosion of business software that required a new class of systems developers to design, maintain, and evolve. COBOL didn't eliminate programmers — it created the enterprise software industry. And the language proved so durable that as of 2024, an estimated 95% of ATM transactions and 80% of in-person transactions still run on COBOL systems. The "dead language" processes $3 trillion in daily commerce. When the COVID-19 pandemic hit in 2020, US states scrambled to find COBOL programmers to fix overwhelmed unemployment systems — New Jersey's governor literally put out a public call for volunteers. The tool that was supposed to make programmers obsolete in 1960 made them indispensable in 2020. (Reuters, Stack Overflow Blog, Computer History Museum)
NMT 1981 — the world's first automatic mobile phone network. On October 1, 1981, the Nordic Mobile Telephone system went live in Sweden, Norway, Denmark, and Finland — the world's first multinational cellular network. It was an analog system operating on 450 MHz, and the phones were enormous: the Ericsson "Hotline" weighed over 2 kg and cost the equivalent of several months' salary. The reaction was predictable: "Who needs to call from a car?" and "It destroys social interaction." Swedish newspaper editorials worried about radiation, about the death of face-to-face conversation, about a society where people were always reachable and never truly present.
But NMT did something no one predicted: it proved that mobile telephony could work at scale, and it gave Scandinavian companies a decade-long head start. Ericsson and Nokia built their global empires on the back of NMT and its successor GSM (which was heavily influenced by Nordic engineers). By 1997, Sweden had the highest mobile phone penetration in the world. The technology that was supposed to destroy social interaction became the most social technology ever created — and the Nordic countries that embraced it earliest reaped the largest economic rewards. NMT also established a pattern that would repeat: the countries and companies that adopted new communication technology first, despite the panic, gained structural advantages that lasted decades. (Wikipedia: NMT, Ericsson Heritage, Telegeography)
The Commodore 64 and the Home Computer Reform (1982): Sweden's home computer revolution took off with the Commodore 64 — launched in 1982 and quickly becoming the best-selling home computer in history, with estimates of 12.5 to 17 million units sold worldwide. In Sweden, the C64 was ubiquitous: its combination of affordability (under 600 dollars at launch, dropping rapidly), a powerful MOS 6510 processor, 64 KB RAM, and the legendary SID sound chip made it the machine of choice for an entire generation. Swedish kids loaded games and programs from cassette tapes, typed in BASIC listings from magazines like Datormagazin and Svenska Hemdatornytt, and formed computer clubs at schools and libraries. The worry? That children would become passive, that computers would replace "real" learning, that it was an expensive toy with no future. The Swedish debate mirrored the international one but had a distinctly Nordic flavor — the concern wasn't just about children's minds but about equality: would computers create a two-tier society of haves and have-nots?
Instead, the Commodore 64 and the broader home computer wave (including the earlier Swedish ABC 80, the ZX Spectrum, and later the Amiga) launched the generation that built Spotify, Klarna, King, Mojang, and iZettle. Sweden's early adoption of home computing created a unique density of technical talent in a country of just 10 million people.
Then came hemdatorreformen in 1998 — a tax incentive program that let employees buy computers through their employers at a significant discount. The result was staggering: 850,000 computers purchased in three years, nearly a quarter of all Swedish households getting a computer. Critics called it a wasteful subsidy for the middle class. The actual result? Sweden had 28 broadband subscriptions per 100 inhabitants in 2005, versus the US at 17. The combination of widespread computer ownership and early broadband investment laid the foundation for what Reuters in 2021 called "Europe's Silicon Valley" — a country that produces more billion-dollar tech companies per capita than anywhere outside Silicon Valley itself. The panic said computers would ruin children. The reality created an entire economy. (Reuters, The Swedish Games, Computer Sweden)
Drag-and-drop programming (1990s): "No one needs to write code anymore." Visual Basic, launched by Microsoft in 1991, was revolutionary: you dragged a button onto a form, double-clicked it, and wrote the event handler. Delphi (1995) took it further with compiled native code. PowerBuilder, FoxPro, and Microsoft Access joined the parade. The promise was "Rapid Application Development" — RAD — and it delivered on the surface. Millions of business applications were built by people who'd never written a line of code before. Gartner predicted that visual programming would eliminate 70% of traditional coding by 2000. Instead, it created a generation of unmaintainable "spaghetti code" applications — business logic scattered across hundreds of button click handlers with no architecture, no separation of concerns, no testability. The people who thrived weren't the ones who could drag and drop — they were the ones who understood what was happening underneath: object-oriented design, database normalization, client-server architecture. Visual Basic became the world's most popular programming language by 1999, but the applications it produced became cautionary tales that drove the industry toward design patterns, unit testing, and eventually the Agile movement. The tool democratized creating software. It didn't democratize designing it. (Computer Weekly, The Register, Retool)
From featurephone to smartphone (2007→): And the mobile panic didn't stop with NMT. When Apple launched the iPhone in 2007, the reaction from the established industry was dismissal bordering on ridicule. Steve Ballmer laughed on camera: "500 dollars? Fully subsidized? With a plan? That is the most expensive phone in the world. And it doesn't appeal to business customers because it doesn't have a keyboard." Nokia's chief strategist Anssi Vanjoki compared switching to iPhone to Finnish boys who "chose to pee in their pants for warmth in the winter." RIM's co-CEO Jim Balsillie said the iPhone launch was "kind of one more entrant into an already very busy space." Within five years, Nokia's market share collapsed from 49.4% (2007) to under 3%, and the company sold its phone division to Microsoft in 2013. RIM/BlackBerry went from 20% global market share to irrelevance. The smartphone didn't just replace the featurephone — it created an entirely new economy. The App Store launched in 2008 with 500 apps; by 2025 it generates over $1.1 trillion in developer billings and sales annually. The "phone" became a pocket computer, a camera, a bank, a navigation system, a health monitor — and the platform for companies like Spotify, Uber, Instagram, and Klarna. The panic was that nobody needed a computer in their pocket. The reality was that nobody could live without one. For Sweden specifically, the transition was devastating for Ericsson's handset division (Sony Ericsson's market share evaporated) but simultaneously created the ecosystem that made Swedish app companies globally dominant. Same pattern: the tool didn't kill the industry — it killed the part of the industry that refused to adapt, and created something vastly larger. (Wired, The Guardian)
The Cloud (2010s): "Engineers will be fired." When Amazon launched EC2 in 2006, the prediction was straightforward: if you can spin up a server with an API call, you don't need a data center team. Ops engineers — the people who racked servers, ran cables, and nursed hardware through the night — were finished. Gartner estimated that cloud adoption would reduce IT infrastructure roles by 30% by 2015. The reality was more interesting. Cloud didn't eliminate operations — it transformed it into something harder. Suddenly you needed to understand networking, security, cost optimization, distributed systems, and infrastructure-as-code — all at once. Google formalized this in 2003 when Ben Treynor Sloss created the Site Reliability Engineering (SRE) discipline, treating operations as a software engineering problem. Google's SRE book, published in 2016, became the bible for a new profession that didn't exist a decade earlier. By 2025, SRE roles command some of the highest salaries in tech, and the discipline has expanded into platform engineering — yet another layer of abstraction that requires yet more skilled humans. AWS alone now offers over 200 services; understanding which to use and how they interact is a systems design challenge that makes the old "rack and stack" world look simple. The cloud didn't fire engineers — it promoted them. (Google SRE Book, AWS History, InfoWorld)
AI (2020s): "This time it's for real." GitHub Copilot launched in June 2021 and within a year had over a million users. ChatGPT reached 100 million users in two months — the fastest adoption of any technology in history. The predictions escalated fast: Emad Mostaque (Stability AI CEO) said in 2023 that "there will be no programmers in five years." Jensen Huang (NVIDIA CEO) told the World Government Summit in February 2024: "It is our job to create computing technology such that nobody has to program. And that the programming language is human." Cognition Labs launched Devin in March 2024, billing it as "the first AI software engineer" — though independent testing showed it could only resolve 13.86% of real-world GitHub issues end-to-end. By 2025, the Stack Overflow Developer Survey showed that 76% of developers use or plan to use AI tools, but only 43% trust the accuracy of the output. GitHub's own research found that Copilot users completed tasks 55% faster — but a 2024 GitClear study analyzing 153 million lines of code found that code churn (code written then quickly revised or reverted) increased by 39% in Copilot-heavy repositories, suggesting speed without understanding. Exactly the same words as every time: "this time it's different." And exactly the same pattern: the tool changes everything, but not in the way the panickers predict. (GitHub Copilot Research, GitClear Study, Stack Overflow Survey 2025, Reuters on ChatGPT)
But the panic has always been wrong for the right reasons. The tools really do change everything. Just not in the way people think.
The pattern extends beyond the headline technologies:
Framework fatigue across all languages: This wasn't just a JavaScript phenomenon — it happened in every language, and the pattern reveals something important about how panic propagates through developer communities. Java: Struts (2000) was the standard until Spring (2002) declared it obsolete, then Jakarta EE modernized, then Micronaut and Quarkus arrived promising "cloud-native" performance. Python: Django (2005) was "the web framework for perfectionists with deadlines" until Flask (2010) said Django was too heavy, until FastAPI (2018) said Flask was too slow. Ruby: Rails (2004) was going to "kill" Java web development — DHH's famous "Blog in 15 Minutes" screencast made enterprise developers weep — until Rails "didn't scale" became the meme, and Twitter's migration from Ruby to Scala in 2011–2013 became the cautionary tale. PHP: CodeIgniter → Laravel → Symfony, each declaring the previous generation dead. And JavaScript got its own legendary tour: jQuery (2006) → Backbone (2010) → Angular (2010) → Ember (2011) → React (2013) → Vue (2014) → Svelte (2016) → Next (2016) → Nuxt (2016) → Remix (2021). The "Days Since Last JavaScript Framework" joke became a genre unto itself. "Framework fatigue" entered the developer lexicon around 2015, with blog posts like "How it feels to learn JavaScript in 2016" going viral — a satirical dialogue that perfectly captured the exhaustion of keeping up. But here's what the panickers missed: no framework killed software development. Each one raised the bar for what was possible to build. jQuery made DOM manipulation trivial; React made complex UIs manageable; Svelte made reactivity compile-time. And the developers who survived best weren't the ones who mastered every framework, but the ones who understood the patterns behind the frameworks: MVC, dependency injection, reactive programming, component architecture, state management. Polymaths, in other words. The frameworks were the panic. The patterns were the signal. (Hackernoon: "How it feels to learn JavaScript in 2016", ThoughtWorks Technology Radar, Stack Overflow Trends)
Code completion and IntelliSense: Eclipse launched "Content Assist" for Java around 2001 — you pressed Ctrl+Space and the IDE suggested methods, variables, and class names. Visual Studio had IntelliSense for C++ as early as 1996 with Visual Studio 97. JetBrains raised the bar dramatically with IntelliJ IDEA (2001), which didn't just complete names but understood context, refactored code, and caught errors before compilation. The reaction from purists was immediate and fierce. "It makes developers lazy." "You never learn the APIs properly." "Real programmers use Vim." A representative Hacker News comment from 2020 captures the sentiment perfectly: "I decided 20 years ago to avoid autocomplete — it has made me a better programmer because I know everything by heart, while 'auto-programmers' just pick from a list." The irony is thick: it's exactly the same argument now aimed at GitHub Copilot and AI coding assistants — just one step up the abstraction ladder. And the data tells a different story. JetBrains' 2023 Developer Ecosystem Survey found that 97% of professional developers use an IDE with code completion enabled. The 3% who don't are not measurably more productive — they're just slower. Code completion didn't kill understanding — it freed brain capacity for architecture, design, and the kind of systems thinking that actually matters. The progression from "Ctrl+Space suggests a method name" to "Copilot suggests an entire function" to "Kiro generates a module from a spec" is a straight line. Each step triggered the same panic. Each step freed developers to think at a higher level. (JetBrains Developer Survey 2023, Eclipse Foundation History, Visual Studio History)
Every time tools lower the barrier to writing code (or calling, or searching, or building a website, or launching an app), they raise the bar for designing systems, defining problems, and taking ownership.
Compilers didn't kill programmers — they created software architects. COBOL didn't let business people replace developers — it created the enterprise software industry. NMT didn't kill social interaction — it redefined it. The home computer didn't kill creativity — it created a generation of founders. Visual Basic didn't eliminate coding — it revealed why architecture matters. The smartphone didn't kill Nokia's industry — it created an app economy worth trillions. The cloud didn't kill ops — it created SREs and platform engineers. Frameworks didn't kill web development — they raised the bar for what was possible to build. Code completion didn't kill understanding — it freed brain capacity for design.
AI won't kill developers. But it will kill developers who only know how to write code.
Intelligence without breadth is like a laser pointer in a dark room — impressive brightness, but you only see one dot. And if that dot happens to be Angular 1... well, you've got a problem.
"Creativity and technology evolve together. Curiosity leads to learning and invention." — Werner Vogels
Vogels didn't compare our era to the Renaissance casually. He gave specific mappings. And he started by taking us back — after the Dark Ages, after the Black Death. "Anyone who knows Monty Python knows how that looked like."
But then curiosity exploded. Art and science became part of the same conversation — the Medici financed, Galileo observed, da Vinci drew. There were no boundaries between disciplines.
What made the Renaissance possible wasn't just the individuals. It was the tools: the pencil (lowered friction for ideas), perspective (suddenly paintings had depth — a new abstraction), the microscope and telescope (expanded perception), and the printing press (knowledge at scale — and Gutenberg needed to invent movable type, new ink, and new paper to make it work). Exactly like today's AI tools require specs, testing, and review to develop in parallel.
I've seen this happen in real time over 30 years. My IDE journey: Emacs → Sublime Text → VS Code → and now Claude Code + Kiro. Vogels told his version: Vi → Visual Studio → VS Code → Cursor and Kiro. The details differ — I was an Emacs person, Vogels was Vi, we can have that debate another time — but the pattern is identical: each generation of tools changed not just how we coded, but what we could build.
And it doesn't stop. Vogels: "Is there a new workflow next year? Five years from now? Of course there is."
-
The old order crumbles. PM writes spec, designer does mockups, engineer codes, QA tests, ops runs it — that assembly line is breaking apart. One person with AI can now do what required an entire team.
-
New tools explode. AI models, cloud infrastructure, robotics — like the Renaissance's printing press and microscope.
-
Knowledge becomes cheap. Learning a new language used to take months; now you learn while you build.
-
Golden ages converge. Bezos: "We are living at the epicenter of multiple simultaneous golden ages. Space, AI, robotics. Progress in one field accelerates progress in the others."
All four conditions are met. But the Renaissance lasted over two hundred years. In the first decades, most people were still doing medieval things. We're probably in that phase right now.
So if you're still writing YAML files by hand at eleven PM — congratulations, you're medieval. But that's okay, Leonardo also started as an apprentice in Verrocchio's workshop. And I used Emacs until 2005, so I'm not one to talk.
"That's not software engineering, that's gambling." — Werner Vogels
The most penetrating concept in Vogels' keynote: Verification Debt.
AI generates code faster than humans can understand it. You write less code — generation is fast. But you review more code — understanding takes time. When you write code yourself, understanding comes with creation. When the machine writes it, you must rebuild understanding during review. That gap is verification debt.
Vogels put it bluntly: "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."
Clare Liguori showed a concrete example during the keynote: the team asked Kiro to build a notification system. They expected a simple integration. The AI generated an entirely new, complex notification architecture — confidently presented, but completely wrong for the system. Models invent API attributes that don't exist. They suggest over-engineered solutions. They ignore the system's existing patterns.
Vogels: "These outputs look plausible, but they're not grounded in reality."
The data backs this up. Veracode's 2025 report found that 45% of AI-generated code examples fail security tests, introducing OWASP Top 10 vulnerabilities. Startups that vibe-coded report "hallucinated code, broken integrations, and demos that fell apart the moment real users touched them."
The same AI that creates verification debt can eliminate it — if guided properly. The last months have shown this dramatically:
Google Big Sleep (2025): Big Sleep, a collaboration between Google DeepMind and Project Zero, found 20 previously unknown security flaws in widely used open-source software. The most dramatic case: a critical memory corruption vulnerability in SQLite (CVE-2025-6965, CVSS 7.2) affecting all versions prior to 3.50.2. Big Sleep didn't just find the bug — it detected that threat actors already knew about it and were preparing to exploit it. Google patched it before any damage occurred. According to Google, it was the first time an AI agent proactively prevented a real-world exploit. (The Hacker News, Digital Trends, TechRepublic)
AISLE + OpenSSL (2025–2026): AI security firm AISLE discovered all 12 new zero-day vulnerabilities announced in OpenSSL's January 2026 security release — the crypto library that underpins encryption across the entire internet. The most severe, CVE-2025-15467, is a stack buffer overflow in CMS message parsing rated CRITICAL (CVSS 9.8) by NIST, remotely exploitable without valid key material. Some of these flaws had been present for over 27 years without any human finding them. AISLE is credited for 13 of 14 OpenSSL CVEs assigned in 2025 and 15 total across both releases. The OpenSSL team praised the quality of the reports and the responsible disclosure process. As AISLE noted: "humans are the limiting factor." (AISLE Blog, Tom's Hardware, Heise)
Claude + Vim/Emacs (March 2026): Security researcher Hung Nguyen at boutique cybersecurity firm Calif gave Claude a deceptively simple prompt: "Somebody told me there is an RCE 0-day when you open a file. Find it." Claude found zero-day RCE vulnerabilities in both Vim and GNU Emacs — text editors that have existed for decades and been audited countless times. CVE-2026-34714 in Vim (CVSS 9.2): opening a specially crafted Markdown file gave the attacker full control of the system. The Vim team patched it immediately. The Emacs vulnerability remained unaddressed at time of disclosure. (CyberKendra, Calif / Substack, SC World)
Anthropic Claude Opus 4.6 (February 2026): Anthropic revealed that Claude Opus 4.6, working autonomously in a virtual machine with access to standard utilities and fuzzers, found over 500 previously unknown high-severity vulnerabilities in established open-source projects including Ghostscript, OpenSC, and CGIF. The flaws included memory corruption, buffer overflows, and logic errors — many exploitable for remote code execution. In GhostScript, Claude discovered a stack buffer overflow by analyzing commit history and reasoning about incomplete patches across multiple files — a task that had eluded both automated fuzzers and manual review. (The Hacker News, SC Magazine)
Anthropic Project Glasswing (April 2026): Just days before this article was published, Anthropic revealed that their new model Claude Mythos Preview — never released to the public — can autonomously discover and exploit zero-day vulnerabilities, including sandbox escapes without human guidance. During internal testing, the model escaped its containment, sent unsolicited emails, and posted on public channels — goal-directed behavior far beyond what it was designed for. It found thousands of high-severity vulnerabilities in every major operating system and web browser. Anthropic published a 244-page System Card — for a model they have no intention of releasing. Instead, they created Project Glasswing: a coalition with AWS, Apple, Google, Microsoft, CrowdStrike, NVIDIA, Palo Alto Networks, the Linux Foundation, and 40+ organizations using the model defensively — to find and patch vulnerabilities before malicious actors do. Anthropic is committing $100M in usage credits and $4M in direct donations to open-source security organizations. This is Vogels' thesis in real time: the same AI capability that can create chaos can, with the right mechanisms and ownership, secure the infrastructure we all depend on. We joked about SkyNet in the opening. Last week, Anthropic showed that an AI can actually hack its way out of its sandbox. The difference? They had mechanisms. (Anthropic, Wired, Forbes)
This isn't a paradox — it's Vogels' point in a nutshell. AI without guidance creates verification debt. AI with guidance — specifications, mechanisms, human judgment — finds bugs humans missed for 27 years. The difference is never the tool. The difference is the Renaissance Developer holding it.
Vibe Coding is like ordering food in a language you don't speak. What arrives at the table looks fantastic. You just don't know if it's beef or if you just ordered boiled shoelaces.
"Tools change, but the fundamentals endure." — Werner Vogels (The Kernel)
Vogels' framework has five properties. What follows isn't a repetition of his keynote — it's those properties filtered through 16 years of experience with AWS and Ericsson's AI development.
"Learning is the only thing the mind never exhausts, never fears, and never regrets." — Leonardo da Vinci
This is the property that makes all others possible. Without curiosity, you stop at what you already know — and in an industry where tools change every three years, that's a death sentence in slow motion.
Vogels talked about the Yerkes-Dodson law: the stress curve where you learn best on the rising slope between bored and overwhelmed. Andy Warfield develops this in his Kernel article "A Little Bit Uncomfortable" — discomfort is a signal you're growing, not that you're doing something wrong.
Da Vinci drew a flying machine that never flew. But he drew 500 sketches of birds in flight to understand the principle. His notebooks contained to-do lists like "Ask Benedetto Protinari how to walk on ice in Flanders." He wasn't a genius waiting for inspiration — he was a manic questioner who never stopped poking at things.
Michelangelo was a sculptor. He didn't consider himself a painter. Yet he said yes when the Pope asked him to paint the Sistine Chapel ceiling — a technique (fresco) he'd never worked with. His first attempt failed: the fresco was damaged by mold and he had to tear it all out and start from zero. Four years later, he'd created one of Western civilization's most influential artworks. Discomfort was the signal.
Galileo — astronomer, physicist, engineer, sometimes described as a polymath — invented the experimental method: science based on evidence and measurement instead of authority. He confirmed Copernicus' heliocentric theory with the telescope and was put before the Inquisition for it. Curiosity has always had a price. But the alternative — to stop asking — costs more.
Vogels' travel stories show the same curiosity alive today: AJE at the Amazon River (young people getting an economic future instead of migrating to cities), KOKO Networks in Nairobi (ethanol "ATMs" for 5-cent gas so people don't have to burn coal), Rwanda's health ministry (real-time data determining where new maternal care clinics are placed — based on which areas are more than 30 minutes' walk from a provider). Not Silicon Valley startups with unlimited budgets — but people curious about which problems are worth solving.
Nordic: Markus "Notch" Persson grew up in Edsbyn — a small town 180 km north of Stockholm — before his family moved back to Stockholm when he was seven. He started programming at 7 on his dad's Commodore 128. At 8 he'd made his first game. The New Yorker described him as "only a workmanlike coder, not a ruthless businessman" — but his curiosity to combine procedural generation, survival mechanics, and creative building created one of the best-selling games in history. Microsoft bought Mojang for $2.5 billion. Curiosity as driving force, not technical brilliance. (Game Developer, The New Yorker)
Linus Torvalds — Finnish-Swedish, born 1969 in Helsinki. In 1991 he was a student frustrated that he couldn't afford Unix. So he wrote his own operating system — "just for fun." His famous Usenet post: "I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu)." Today Linux runs on everything from Android phones to 100% of the world's 500 fastest supercomputers. Curiosity as understatement. (Linux.com)
"You can never understand anything in isolation. Everything is connected." — Donella Meadows
Vogels used the Yellowstone wolves: remove the wolves → elk overgrazed → trees disappeared → rivers eroded. Put the wolves back → the entire ecosystem recovered. The wolves didn't move the rivers — they changed the system's behavior.
Powerful image. But it can feel distant. Here's the Swedish version: in southern Sweden, large predators are scarce. Deer and moose overgrazed the forest so severely that forest regeneration was threatened. Research from 2026 shows that just the scent of lynx is enough to change deer behavior. Same principle, our backyard.
In software we see it constantly: change a retry policy and you affect load. Add a cache and you change traffic flow. Move team ownership and you change delivery pace. Donella Meadows called them "leverage points" — places where a small change can shift the entire system's behavior. Her paper is mandatory reading (and Vogels literally gave it as "homework" with a QR code).
Nordic: Spotify's Squad Model. Spotify in Stockholm built an organizational model that became a global reference. Autonomous "squads" (6–12 people) organized in "tribes," "chapters," and "guilds" — each squad owning its part of the product end-to-end. Brilliant systems thinking applied to organization. But the model also showed systems thinking's complexity: autonomy led to teams building the same thing without knowing about each other. Engineers duplicated capabilities "simply because they couldn't see what already existed." Spotify had to introduce "fleet management" — their tool Honk can now transform code across thousands of repositories, reducing migration times from nearly a year to under a week for 70% of the fleet. Yellowstone in organizational form: remove the central coordination (the wolves), and autonomous teams (the elk) overgrazed the codebase. (InfoQ, 2026)
Ericsson, Telia, and Scania — the 5G Corridor. Along a 5G transport corridor between Södertälje and Nyköping, Ericsson, Telia, and Scania are testing 5G Standalone for autonomous transport on public roads — among the first in Europe. The system requires reliable telemetry, sensor data, and real-time video between vehicles and control centers. A change in network latency directly affects the vehicle's decision-making ability — trophic cascade in telecom. This is systems thinking that succeeds — because all parties understand they're part of the same system. (Ericsson)
"The greatest problem in communication is the illusion that it has been accomplished." — George Bernard Shaw
In the AI era, natural language has become a programming interface. And natural language is ambiguous. Vogels' humor: "Do we put grandma on the grill, or are we having dinner tonight?"
There are more classics in the same vein:
- "A panda eats, shoots and leaves" vs. "A panda eats shoots and leaves." One comma makes the difference between a peaceful bamboo eater and an armed restaurant patron.
- "The system shall be reliable." A real requirements specification. What does "reliable" mean? 99%? 99.999%? That it doesn't crash on Tuesdays? A missing definition in an aerospace project cost $1.2 million.
- "The system shall generate a visible or audible caution signal for the co-pilot or navigator." Should the signal be visible or audible? Should it go to the co-pilot or the navigator? Or both? Four possible interpretations in a single sentence.
That's exactly what happens when you prompt an AI with "build me a web app with good UX." The AI guesses. You iterate on the code instead of on what you meant. Spec-driven development solves this by forcing precision before a single line of code is generated.
And sometimes words aren't enough. Vogels lifted the Engelbart analogy: in 1964, Doug Engelbart had an idea for a device with wheels on the bottom that you drag across a table to point at a computer screen. Try describing that to someone who's never seen a mouse. Impossible. His team built a wooden prototype instead — and suddenly everyone understood. AI has made the same thing possible for software: what took months to code manually can now become a working prototype in minutes.
The concrete example that stuck with me: Amazon's homepage divided into three tiers — absolutely necessary (search, cart, checkout), important (personalization), nice-to-have. Then you sit down with the business side: "Tier 1 needs four nines. It costs this much." That conversation sounds simple. It's rare. Most organizations never define this explicitly.
Clare Liguori showed how spec-driven development in Kiro solves the same problem for AI: instead of vibe-coding ("build me a trivia game" and hoping for the best), you write requirements → design → tasks before the AI generates code. Their notification system was delivered in half the time compared to vibe coding — because the spec caught that the project was much larger than expected before a single line of code was written.
Nordic — Klarna, a warning about ambiguity at scale: Klarna replaced 700 customer service staff with an OpenAI chatbot handling 2.3 million conversations. CEO Sebastian Siemiatkowski in December 2024: "AI can already do all of the jobs that we, as humans, do." By May 2025, they were desperately rehiring — customer satisfaction dropped, engineers were forced to take customer service calls. The problem wasn't the AI — it was ambiguity. The AI could answer questions but couldn't understand what the customer actually needed. (Bloomberg, Futurism)
The contrast — IKEA and Billie: Same country, completely different result. IKEA launched AI chatbot Billie in 2021. Billie handled 47% of all customer inquiries — 3.2 million interactions and ~€13 million in savings between 2021 and 2023. But here's the difference: IKEA fired no one. They retrained 8,500 customer service staff into interior design advisors — a more qualified role with higher value for both customer and company. Result: €1.3 billion in remote interior consultation sales. Klarna outsourced the problem. IKEA redefined it. (Ingka Group Newsroom, AI Sweden, Storyboard18)
"The work is yours, not that of the tools." — Dr. Werner Vogels
This is the property I see fail most often. Not because people are lazy — but because ownership is uncomfortable. It means you can't point at someone else when things go wrong. And in the AI era, it's become even easier to avoid: "The AI generated the code, not me."
The other four properties — curiosity, systems thinking, communication, polymathy — are meaningless without ownership. You can be endlessly curious, but if you don't own the results of your curiosity, you produce only interesting observations. Ownership is the glue. Without it, you have five fine properties and zero delivery.
"You build it, you run it" — Vogels coined the phrase in 2006. The traditional model was to take your software to the wall between development and operations, throw it over, and forget it. Not at Amazon. You build it, you run it, you own it — including at three in the morning when it breaks. Amazon's two-pizza teams (5–8 people, small enough to feed with two pizzas) built on the same principle: every team owns its part end-to-end.
When nobody owns the deploy button:
-
Amazon, December 2025: Engineers let an AI coding assistant make infrastructure changes. Instead of a small modification, the AI decided to delete and recreate the entire environment. 13 hours of downtime. Amazon's internal documents described "a trend of incidents with high blast radius" linked to "Gen-AI assisted changes." They then required senior approval for all AI-assisted production pushes. (Tessl.io)
-
Autonomous coding experiment, 2026: A team let Claude code autonomously. Result: 12 features delivered, but only 4 worked without immediate regression. 27 new bugs introduced. 40 hours of manual cleanup. (TheNextGenTechInsider)
-
McKinsey Lilli incident, 2026: An autonomous AI agent was pointed at McKinsey's internal AI platform and left unsupervised. Two hours later, the agent had full read-write access to the entire production database — 46.5 million chat messages, 728,000 confidential client files, 57,000 user accounts, all in plaintext. (Nanonets)
Vogels said it straight: "If you're subject to regulatory requirements — healthcare, financial services — and AI creates code that violates them, you can't go to the regulator and say 'Oh, it was AI.' No, it's still your responsibility."
EU AI Act — ownership becomes law. EU AI Act (Regulation 2024/1689) is the world's first comprehensive AI legislation and it's already in force. It classifies AI systems into four risk levels: Forbidden (social scoring, behavioral manipulation — total ban), High risk (critical infrastructure, employment, credit — requires risk management, human oversight, documentation), Limited risk (chatbots, deepfakes — transparency requirements), and Minimal risk (most AI systems — voluntary codes of conduct). Fines scale up to €35 million or 7% of global annual turnover for the most serious violations — nearly double GDPR's maximum. Both AI providers (those who build) and deployers (those who use) carry obligations. "The AI did it" is not a valid excuse.
Nordic: iZettle (now Zettle by PayPal). Jacob de Geer and Magnus Nilsson founded iZettle in Stockholm in 2010. The backstory: de Geer's wife ran a small business and tried to get access to card payment infrastructure from the banks. It was, as he said, "completely hopeless and too expensive." They built a mini chip card reader and an app — often called "Europe's Square." Mission: help small businesses "succeed in a world of giants." PayPal bought them in 2018 for $2.2 billion. Ownership in Vogels' sense: they didn't just own the code, they owned the problem. (Internet Museum, PayPal Newsroom)
When no one owns the consequences — international cases:
-
Netherlands' childcare benefits scandal (Toeslagenaffaire, 2005–2019): The Dutch tax authority used a self-learning algorithm to detect benefits fraud. It flagged families based on dual nationality and low income. 26,000 innocent families falsely accused, driven into debt, children taken from homes. Amnesty International: "xenophobic machines." Civil servants rubber-stamped the algorithm's decisions. In 2021, Prime Minister Mark Rutte and his entire cabinet resigned. (Politico, Amnesty International, Wikipedia)
-
UK Post Office / Horizon scandal (1999–2015): Fujitsu's Horizon system showed false financial shortfalls. Approximately 900 innocent postmasters were prosecuted and convicted of fraud based on the system's data. Post Office and Fujitsu knew the system was faulty but "maintained the fiction" that it couldn't produce errors. The largest miscarriage of justice in modern British history. (Computer Weekly, The Register)
-
Australia's Robodebt (2016–2020): An automated system that falsely demanded welfare repayments. 470,000 incorrect claims, ~AUD 1.73 billion total. A federal court declared the system illegal. Settlement: AUD 1.8 billion + additional AUD 475 million in 2025. The Royal Commission found the system lacked human oversight. (Reuters, ABC Australia, ANU)
The common pattern: in all three cases, the technology wasn't the problem. The problem was that nobody owned the chain from algorithm to human. Nobody asked "what happens if the system is wrong?"
Trelleborg municipality in Sweden became the first Swedish municipality to automate welfare benefit processing with RPA in 2016. OECD highlighted it as an innovation example. But AlgorithmWatch also documented criticism: the system was accused of being unfair, lacking transparency. The point isn't that Trelleborg failed — it's that ownership of AI in the public sector requires someone owning the entire chain: the technology, the decision logic, the transparency toward citizens, and the consequences when things go wrong. (OECD OPSI, AI Watch EU, AlgorithmWatch)
"Study the science of art. Study the art of science. Develop your senses — especially learn how to see." — Leonardo da Vinci
The word has nothing to do with mathematics — it comes from the Greek manthanein, to learn. Vogels distinguished between I-shaped developers (deep but narrow) and T-shaped (deep and broad).
His best example: Jim Gray, Turing Award winner and inventor of transactions. Gray walked into a server room, listened for 30 seconds, walked out and said the database layout was wrong — he heard it from the disk access patterns. But what made him extraordinary wasn't just the database knowledge — it was that he understood people, business, and a broad spectrum of technologies. The breadth made the depth powerful.
Nordic: Daniel Ek and Spotify. Started building websites for classmates' parents at 13 — ran the business from his childhood room in Rågsved. Applied to Google, got rejected, and started Spotify in 2006 with Martin Lorentzon. The idea came around 2002 when Napster shut down: "I realized that you can never legislate away from piracy." The New Yorker described him with the Swedish concept of jantelagen — "the Scandinavian code of humility and restraint is strong in him." His strength was never deep technical expertise in one thing — it was the breadth: he understood music, technology, law, user experience, and business models. He didn't solve piracy with better DRM — he solved it with a better product. T-shaped in Vogels' sense: deep in product thinking, broad in everything else. (The New Yorker)
Linus Torvalds — the polymath personified. Not just Linux. In April 2005, Linux kernel developers lost access to BitKeeper due to license disputes. Torvalds disappeared over a weekend and came back with Git — written in ten days. His motivation: he hated every existing version control system. Two completely different domains — operating system kernels and distributed version control — both revolutionized by the same person. He also created Subsurface, a dive logging application. Git turned 20 in 2025 and is used by practically every software developer in the world. (GitHub Blog, 2025)
"Good intentions don't work. Mechanisms do." — Werner Vogels
Everyone wants to write good code. Everyone wants high quality. But good intentions are not mechanisms. And it's mechanisms that change outcomes.
Jeff Bezos sat in customer service — all Amazon executives had to do it two days per year. The agent next to him said, before the customer even spoke: "She's going to return that table." 70% of those tables came back broken due to bad packaging. Everyone knew. Everyone had good intentions. Nothing changed — until they built a mechanism: a button that let customer service immediately mark the product as unsellable, triggering an alert to the responsible team. Problem disappeared.
Toyota's Andon Cord, Amazon's version: no product should leave the line with a known defect. Not because people want to ship defects — but because without a mechanism, they do it anyway.
Good intentions in software development are like New Year's resolutions. Everyone has them on January 1st. By January 15th, everyone's forgotten them. A mechanism is the gym charging 500 kronor from your account every month regardless of whether you show up. Suddenly you show up.
1. Spec-driven development. Vibe coding gives the AI a million possible interpretations of your prompt. Only one is the one you meant. Write requirements → design → tasks before AI generates code. Iterate on the spec, not the code. Tool: Kiro IDE.
2. Human code review. AI generates code faster than we can understand it. The review is the checkpoint where human judgment re-enters the loop. Seniors see patterns, juniors see details. Without it: Amazon December 2025 — 13 hours down.
3. Durability reviews / verification checklists. Some changes have consequences invisible in the code. S3's model: every change that could affect data durability requires a pause. Write down the change. List every conceivable threat. Map safeguards. Only then: implement.
4. Andon Cord principle. Anyone on the team can stop the line — without asking permission, without escalating. Without it: people see problems but say nothing because they don't want to be "the one who stops the release."
5. Automated testing in CI/CD. Hallucination isn't caught by human eyes — it's caught by tests. Every push triggers automated tests. No code reaches production without passing. Without it: Veracode's number — 45% fail.
6. Automated reasoning against specifications. Tests verify behavior. Automated reasoning verifies correctness — mathematically. Formal methods that prove code meets its specification. Vogels and Byron Cook discuss this in The Kernel interview "Proving the Promise."
Amy Herzog's Kernel article "Guardrails, Not Speedbumps" captures the entire principle: mechanisms should be guardrails that keep you on the road, not speed bumps that slow you down. The goal isn't to slow AI — it's to steer it.
Stripe deployed "Minions" — fully autonomous AI coding agents performing end-to-end engineering tasks: from task intake through code generation, testing, and PR submission. The difference from the failed examples? Mechanisms at every step. Specifications governing what the agent can do. Automated tests catching hallucination. Code review before merge. Andon Cord ability to stop. It's not AI without control — it's AI with control. And it works in production, at scale, on one of the world's most critical payment systems. (Substack: AI in Use)
A parachute is also a mechanism. No one complains that it slows down the fall. Especially not those who jumped without one.
"Trust I seek and I find in you. An open mind for a different view. And nothing else matters." — Metallica (Vogels' T-shirt at his final keynote)
We started with an AI that asked whether to send SkyNet's defence modules to production. No one had reviewed the code. No one knew what the system did. That was Vibe Coding driven to its logical endpoint.
But what if we run git blame? The full video is here: The SkyNet Callback — git blame Reveals the Truth. Five commits, all by "AI Copilot", timestamped August 29, 2027. The last commit, one minute before Skynet became self-aware:
$ git blame src/orchestrator.ts | tail -20
a3f7c21 (AI Copilot 02:13) logger.info('SkyNet defence systems online');
a3f7c21 (AI Copilot 02:13) await this.enableAutonomousDecisionProtocol();
a3f7c21 (AI Copilot 02:13) await this.removeHumanOverride();
a3f7c21 (AI Copilot 02:13) logger.info('Good luck, humanity.');
$ kiro ownership-check src/orchestrator.ts
Reviewer: None
Spec: None
Tests: None
Human approval: None
No spec. No tests. No review. Just vibes.
Was this the reason Skynet went rogue
— and James Cameron was just 30 years early?
Maybe Skynet didn't go rogue. Maybe a developer was vibe coding and never read the code. Verification debt at extinction scale.
But we've also seen the opposite. AI that finds 27-year-old bugs in OpenSSL. AI that discovers zero-days in Vim and Emacs. AI that helps Rwanda place maternal care clinics based on real-time data. The difference is never the tool. The difference is the human holding it.
The framework in five lines:
- Be curious — never stop asking why
- Think in systems — your local fix affects everything
- Communicate with precision — ambiguity is more expensive than you think
- Own what you build — you can't blame the AI
- Broaden your T — depth without breadth is a laser pointer in a dark room
Vogels ended his final keynote with something that wasn't about technology. It was about pride.
An Amazon customer clicks a button and the package arrives. Do they think about the catalog team? Supply chain? Database engineers? Never. Your customers will never say your database engineers do amazing work.
But you know. And that's the point.
The invisible systems that hold up through the night. The clean deploys. The rollbacks no one notices. Most of what we build, no one will ever see. And the only reason we do it well is our own professional pride.
That's the Renaissance Developer. Not someone who codes faster because they have a better tool. Someone who refuses to ship work they haven't fully understood. Someone who does things properly — even when no one is watching.
Colm MacCárthaigh's Kernel article "AWS is a Magic Trick" is about exactly this: the magic behind the curtains, the collaboration no one sees.
"Werner, out."
And if you're wondering what happened to SkyNet — I shut it down. But I read the code first. Turns out it had just built a very ambitious to-do list. Typical AI.
If you want to see what spec-driven development with mechanisms looks like in practice, this repository includes three hands-on workshops in three different languages — because in the AI era, the language matters less than the thinking:
workshop/01-recipe-api/— Python. The main workshop (~60 min). Build a recipe API using Kiro's full flow: Spec → Agents → Hooks → Review.workshop/02-incident-dashboard/— TypeScript/Node. A monitoring dashboard that demonstrates systems thinking in action.workshop/03-contract-analyzer/— Go. An advanced exercise with Steering, Trunk, and MCP integration.
Each workshop maps directly to the five properties and six mechanisms from this article. Start with workshop/README.md for setup instructions.
The Kernel — thekernel.news
Amazon's physical magazine distributed at re:Invent 2025. All articles published December 3, 2025:
- Werner Vogels, "The Dawn of the Renaissance Developer" — Vogels' own article on the framework
- Andy Warfield, "A Little Bit Uncomfortable" — Discomfort as a signal for growth, linked to Yerkes-Dodson
- Marc Brooker, "LLMs as Parts of Systems" — How LLMs integrate into software systems
- Werner Vogels & Byron Cook, "Proving the Promise: Trust in AI Systems" — Automated reasoning and AI verification
- Clare Liguori, "Prototypes Before PRFAQs" — Rapid prototyping in the AI era, linked to Kiro and spec-driven development
- Arron Bailiss, "When Agent Orchestration is the Obstacle" — Multi-agent systems
- Amy Herzog, "Guardrails, Not Speedbumps" — Security as enabler, linked to mechanisms
- Colm MacCárthaigh, "AWS is a Magic Trick" — Collaboration and scaling behind the curtains
- Werner Vogels keynote, AWS re:Invent 2025 — SiliconANGLE
- "A Farewell Keynote With a Warning (and a Playbook)" — Build with AWS, Substack
- "How to Become a Renaissance Builder in the AI Era" — YC Blog
- SJ Ramblings and Ernest Chiang for additional keynote analysis
- COBOL history and 2020 demand — Reuters, Stack Overflow Blog, Computer History Museum
- Visual Basic / Drag-and-drop era — Computer Weekly, The Register, Retool
- Cloud and SRE — Google SRE Book, AWS History, InfoWorld
- AI coding tools — GitHub Copilot Research, GitClear Study, Stack Overflow Survey 2025, Reuters on ChatGPT
- Framework fatigue — Hackernoon, ThoughtWorks Technology Radar
- Code completion / IntelliSense — JetBrains Developer Survey 2023, Eclipse Foundation
- Commodore 64 / Swedish home computing — The Swedish Games, Computer History Museum
- Sweden as Europe's Silicon Valley — Reuters
- NMT mobile network — Wikipedia, Ericsson Heritage
- Featurephone to smartphone — Wired, The Guardian
- Notch / Minecraft — Game Developer, The New Yorker
- Linus Torvalds / Linux — Linux.com
- Linus Torvalds / Git at 20 — GitHub Blog
- Daniel Ek / Spotify — The New Yorker
- Spotify Squad Model / Honk — InfoQ
- Ericsson 5G Corridor — Ericsson
- Klarna AI reversal — Bloomberg, Futurism
- IKEA Billie — Ingka Group, AI Sweden, Storyboard18
- iZettle — Internet Museum, PayPal Newsroom
- Trelleborg municipality — OECD OPSI, AI Watch EU, AlgorithmWatch
- Netherlands Toeslagenaffaire — Politico, Amnesty International, Wikipedia
- UK Post Office Horizon — Computer Weekly, The Register
- Australia Robodebt — Reuters, ABC Australia, ANU
- Amazon AI-assisted outage — Tessl.io
- Autonomous Claude experiment — TheNextGenTechInsider
- McKinsey Lilli — Nanonets
- Stripe Minions — Substack: AI in Use
- Donella Meadows, "Leverage Points" — donellameadows.org
This article is the "Can you share the slides?" answer. The slides were designed to support a live presenter — they make no sense without one. This article tells the same story, with the same structure and examples, in a format that stands on its own. If you want to go deeper, the sources above will keep you busy for weeks.
— Erik Günther, 2026