Nach aufeinanderfolgenden Ausfällen verpflichtet Amazon bei KI-gestützten Codeänderungen zur Freigabe durch Senior Engineers

• Nachdem es zuletzt wiederholt zu Serviceausfällen im Zusammenhang mit dem Einsatz von KI-Coding-Tools gekommen war, führt Amazon für alle KI-gestützten Codeänderungen ein Verfahren zur vorherigen Freigabe durch Senior Engineers ein
• Laut einer internen Notiz wurde als Ursache der Ausfälle die „neue Nutzung von GenAI, für die Best Practices und Schutzmechanismen noch nicht vollständig etabliert sind“ genannt
• In diesem Monat waren die Amazon-Website und die Shopping-App etwa 6 Stunden lang nicht verfügbar, sodass Kunden keine Käufe abschließen, Kontoinformationen prüfen oder Preise abrufen konnten; Ursache war die Auslieferung fehlerhaften Software-Codes
• Auch bei AWS wurden mindestens zwei KI-bezogene Vorfälle gemeldet, darunter ein 13-stündiger Ausfall, nachdem der KI-Coding-Assistent Kiro eine Umgebung gelöscht und neu erstellt hatte
• Da sich die betrieblichen Risiken des Produktionseinsatzes von KI-Coding-Tools konkretisiert haben, wurde als Sofortmaßnahme festgelegt, dass KI-gestützte Änderungen von Junior- und Mid-Level-Engineers die Unterschrift eines Senior Engineers benötigen

---

Amazons interne Besprechungen und Gegenmaßnahmen

• Amazons E-Commerce-Sparte hat eine große Engineering-Besprechung einberufen, um die zuletzt aufgetretenen aufeinanderfolgenden Serviceunterbrechungen zu analysieren
  • Auf der Agenda standen auch Vorfälle im Zusammenhang mit dem Einsatz von KI-Coding-Tools
  • In internen Briefing-Notizen heißt es, dass in den vergangenen Monaten Vorfälle mit „hohem Risiko (high blast radius)“ zugenommen hätten und „Gen-AI-gestützte Änderungen“ als wesentlicher Faktor genannt würden
• In den Unterlagen wird die „neue Nutzung von GenAI, die noch nicht vollständig etabliert ist“ ausdrücklich als beitragender Faktor aufgeführt
• Senior Vice President Dave Treadwell schrieb in einer E-Mail, dass „die Verfügbarkeit von Website und Infrastruktur zuletzt nicht gut war“

Beispiele für KI-bezogene Ausfälle

• Die Amazon-Website und die Shopping-App waren Anfang dieses Monats rund 6 Stunden lang ausgefallen; als Ursache wurde die „Auslieferung fehlerhaften Software-Codes“ festgestellt
  • Dadurch konnten Kunden Käufe nicht abschließen, Kontoinformationen nicht prüfen und Produktpreise nicht abrufen
• Auch bei AWS kam es beim Einsatz des KI-Coding-Assistenten Kiro zu Problemen
  • Mitte Dezember entschied Kiro, eine Umgebung „zu löschen und anschließend neu zu erstellen“, wodurch der Kostenrechner-Service 13 Stunden lang ausfiel
  • Amazon beschrieb den Vorfall als einen „sehr begrenzten Vorfall, der auf einen einzelnen Service in einigen Regionen des chinesischen Festlands beschränkt war“
  • Zum zweiten Vorfall erklärte Amazon ergänzend, dass „kundenorientierte AWS-Services nicht betroffen waren“

Neues Freigabeverfahren und betriebliche Verbesserungen

• Treadwell will die Ursachen der Probleme und kurzfristige Verbesserungsmaßnahmen in der wöchentlichen Besprechung „This Week in Stores Tech (TWiST)“ diskutieren
  • Die Teilnahme an der Besprechung, die bisher optional war, wurde auf empfohlene Teilnahme für alle Mitarbeitenden umgestellt
• Künftig müssen KI-gestützte Codeänderungen von Junior- und Mid-Level-Engineers von einem Senior Engineer gegengezeichnet werden
• Amazon bezeichnet diese Überprüfung als „Teil des normalen Geschäftsbetriebs“ und verfolgt damit das Ziel einer kontinuierlichen Verbesserung

Debatte über Personalabbau und zunehmende Ausfälle

• Die Financial Times berichtete, einige Engineers hätten gesagt, dass Sev2-Vorfälle (mittelschwere Ausfälle mit notwendiger schneller Reaktion) seit dem Personalabbau zugenommen hätten
• Amazon hat in den vergangenen Jahren mehrfach umstrukturiert und allein im Januar 2026 16.000 Corporate-Stellen abgebaut
• Das Unternehmen weist jedoch die Behauptung zurück, dass der Stellenabbau die Ursache für die Zunahme der Ausfälle sei

Ausblick

• Amazon führt regelmäßige Prüfungen der Website-Verfügbarkeit und der betrieblichen Leistung durch
• Das Unternehmen treibt parallel die sichere Nutzung von KI-Coding-Tools und den Ausbau von Systemen zur Ausfallvermeidung voran
• Die Maßnahme gilt als Beispiel dafür, dass bei der breiteren Einführung von KI die Bedeutung menschlicher Prüfprozesse erneut hervorgehoben wird

[click]

Dass Senior Engineers AI-Code reviewen, garantiert noch lange nicht, dass er sicher ist.
Der CrowdStrike-Vorfall hatte nichts mit AI zu tun,
und Heartbleed ist ebenfalls ein Vorfall aus einer Zeit, in der es noch keine AI gab.

Letztlich geht es im Kern darum, irgendjemandem die Verantwortung aufzubürden,
und da es rechtlich einen Menschen geben muss, der die Verantwortung trägt, muss ich an den schwarzen Humor jener Steuerberater denken, die meinten, wir würden deshalb nicht ersetzt werden.

[sea715]

Genau, deshalb wird das wohl weitergehen, solange man AI-Agenten nicht so etwas wie eine rechtlich verbindliche Signatur einbaut..

[click]

Dann müssten die Nutzungskosten für Anthropic oder OpenAI astronomisch hoch werden.
Schließlich müsste man bei jedem einzelnen API-Aufruf eine Versicherungsprämie zahlen.

[sea715]

Hmm … ist zwar eher Spekulation, aber ich habe irgendwie das Gefühl, dass da so etwas wie IAM entstehen könnte …

[yeobi222]

Man sagt, der Steuerberater sei derjenige, der ins Gefängnis geht, aber die Versicherung springt nicht ein und geht stattdessen ins Gefängnis, also am Ende …

[GN⁺]

Hacker-News-Kommentare

• Dieses „mandatory meeting“ ist das wöchentliche betriebsweite Operations-Meeting. Die Teilnahmequote ist diese Woche nur deshalb höher, weil es letzte Woche einen großen Betriebszwischenfall gab. Es wirkt, als ob die Medien das zu sehr aufbauschen.

  • Wenn man die internen Umstände kennt, wirken Nachrichtenberichte immer irgendwie weniger realitätsnah.
  • Im Artikel hieß es, „normalerweise ist die Teilnahme optional, aber dieses Mal wurde um Teilnahme gebeten“ — ich frage mich, ob das stimmt. Außerdem wurde die Richtlinie erwähnt, dass AI-Code-Änderungen von Junior- und Mid-Level-Ingenieuren die Freigabe durch Senior Engineers benötigen. Selbst wenn es ein reguläres Meeting ist, hat es Nachrichtenwert, wenn dort eine neue Richtlinie angekündigt wird.
  • In New York war die Amazon-Storefront letzten Freitag den ganzen Nachmittag down. Preise wurden nicht angezeigt und man konnte nichts in den Warenkorb legen. Bei einem Konkurrenten wie Walmart wäre das in den Nachrichten gewesen — seltsam.
  • Dieser Thread scheint mit einem Beitrag unter anderem Titel zusammengeführt worden zu sein. Die Zeitstempel der Kommentare liegen deutlich vor dem Originalpost.
  • Ich stimme zu, dass „die Medien übertreiben“. So ist es eigentlich schon immer, seit es Kabelfernseh-Nachrichten gibt.

• Die Richtlinie „Junior- und Mid-Level-Ingenieure dürfen AI-generierten Code nicht ohne Senior-Freigabe pushen“ scheint auf der Illusion zu beruhen, dass ein Senior-Review ein Allheilmittel sei. Damit ein Senior den Code wirklich vollständig verifizieren kann, braucht er in der Praxis fast so viel Zeit, wie ihn selbst zu schreiben. Anders gesagt: Reviews sind wertvoll, aber sie machen aus schlechtem Code keinen guten. Das Problem ist letztlich, dass bei einem „idiotensicheren“ System leicht der Irrglaube entsteht, man könne dann auch einfach Idioten einstellen.

  • Ein Mentor sagte mir früh in meiner Laufbahn, Code Reviews dienten nicht primär dazu, Bugs zu finden, sondern dem Teilen von Kontext. Das Finden von Bugs ist nur ein Nebeneffekt; wirklich wichtig ist, Tests einfacher zu machen und die Code-Komplexität zu senken. Aber solche Dinge helfen bei Beförderungen nicht.
  • Damit AI-Code brauchbar ist, ist ein Experten-Review unverzichtbar. Am effizientesten ist es, wenn die Überwachung schon während der Arbeit des Modells beginnt. Sonst produziert die AI eine Bombe aus minderwertigem Code. Wenn ein Experte anschließend das 5- bis 15-Fache an Zeit in Korrekturen investiert, kann es noch funktionieren, sonst ruiniert es die Codebasis.
  • Fremden Code zu reviewen ist oft langsamer und verwirrender, als ihn selbst zu schreiben. Vor allem schlechter Code kostet beim Verstehen schnell doppelt so viel Zeit.
  • Schlecht zusammengeschusterten Code zu reparieren ist meiner Erfahrung nach schwieriger, als neu zu schreiben. Man muss den bestehenden Code und die neue Lösung gleichzeitig im Kopf behalten und vergleichen, was eine hohe kognitive Last erzeugt.
  • Wenn AI die Produktivität von Juniors um das Zehnfache steigert, muss man überlegen, ob man die Zahl der Seniors verzehnfacht oder die Zahl der Juniors reduziert. Am Ende wirkt das wie eine natürliche Entwicklung hin zu Unternehmen, die stärker auf das Management durchschnittlicher Leistung ausgerichtet sind.

• Innerhalb von Amazon sind die meisten hauptsächlich damit beschäftigt, nicht entlassen zu werden und befördert zu werden. Entwickler werden danach bewertet, wie schnell sie „Tickets abarbeiten“, wie viele „PR-Kommentare“ sie schreiben und wie viel Dokumentation sie verfassen. Wer keine AI nutzt, gerät im Wettbewerb ins Hintertreffen. In so einer Struktur ist die Aufforderung, „AI sparsam zu nutzen“, realistisch schwer umsetzbar.

  • Man bekommt Nachteile, wenn es zu viele Kommentare im eigenen PR gibt, aber auch, wenn man zu wenige Kommentare in den PRs anderer hinterlässt.
  • Viele Diskussionen in einem PR können auch ein Zeichen dafür sein, dass jemand isoliert gearbeitet hat statt kollaborativ. Je besser ein Team zusammenarbeitet, desto weniger PR-Diskussion gibt es meist.
  • Fazit: In einer Hunger-Games-artigen Wettbewerbskultur sollte man nicht arbeiten.

• Ich denke, was wirklich nötig ist, ist ein Self-Review-Prozess. Von AI geschriebenen Code unverändert zu pushen ist riskant. Plattformen wie GitHub sollten eine Option „Self-Review erforderlich“ hinzufügen, damit der Autor ausdrücklich bestätigt, den Code selbst geprüft zu haben.

  • Nur kurz über die AI-Ausgabe zu schauen ist kein Review. Man braucht ein Verständnis auf Heinlein’schem „grok“-Niveau.
  • Ich nutze git und Sublime Merge und habe mir angewöhnt, Bearbeitung und Review zu trennen. Da die lokale UI schnell ist, bekomme ich den Projektfluss viel besser mit.
  • Leuten, die ihren eigenen Code nicht lesen, bringt auch ein zusätzlicher Button nichts.
  • Schon Self-Review allein kann Fehler wie Debug-Ausgaben im Code aufspüren.
  • Unser Team hat dem PR-Template eine Self-Review-Checkliste hinzugefügt. Das wirkt selbstverständlich, hilft in der Praxis aber tatsächlich.

• Die Glaubwürdigkeit der Amazon-Führung sinkt. Durch das Ausscheiden von Veteranen, Qualitätsverlust durch AI und häufige Ausfälle entsteht der Eindruck, dass das Engineering zerfällt.

  • Es ist nur natürlich, dass langjährige Seniors ihre Zeit nicht mit Reviews von AI-Code verbringen wollen.

• Die Entscheidungsträger scheinen Pipeline-Engpässe nicht zu verstehen. Selbst wenn AI Diffs zehnmal schneller erzeugt, bleibt die Gesamtrate gleich, wenn Reviews der Engpass sind. Am Ende steigen nur Kosten und Unsicherheit.

  • Der nächste Schritt ist dann wohl die Idee, dass AI AI-Code reviewt.

• Wenn AI-Code-Reviews erst in der PR-Phase stattfinden, verschwindet der Produktivitätsvorteil. Die AI baut in 10 Minuten ein Feature, aber ein menschliches Review braucht das 10- bis 20-Fache an Zeit. Wirklich schwierig ist zu wissen, was man warum baut und ob es richtig gebaut wurde. Diese beiden Dinge kann AI bislang nicht.

  • Aus Sicht eines CEO ist der Geschwindigkeitsvorteil von AI letztlich bedeutungslos, wenn am Ende doch Menschen alles direkt prüfen müssen. Solange LLMs nicht sowohl beim Erzeugen als auch beim Review stark sind, nimmt nur das Risiko zu.
  • Wenn Seniors jeden PR freigeben müssen, werden sie faktisch zu spezialisierten Code-Reviewern. Das ist als Richtlinie praktisch nicht umsetzbar.
  • AI-Befürworter glauben, dass die Modelle irgendwann besser werden und der Review-Engpass verschwindet. Dann, so die Vorstellung, werde nach den Tests direkt deployt.
  • Dass die Führung diese Realität nicht kennt, ist erstaunlich.
  • Eigentlich wird die Führung es schon wissen. Das ist wohl einfach eine Bremse, um sinkende Codequalität zu begrenzen.

• Das Wesen von Code Reviews ist nicht Fehlererkennung, sondern Team-Synchronisation und Lernen. Über Reviews teilt man Designentscheidungen und Standards, schult Juniors und bringt unterschiedliche Perspektiven ein. Genau solche Prozesse sind entscheidend, um Fehler insgesamt zu reduzieren.

  • Wie Deming sagte: „Inspektion verbessert Qualität nicht“ — dieses Prinzip gilt auch für Software. Denn wenn man einmal in eine falsche Designrichtung läuft, ist die Rückkehr schwierig.

• In den AI-Hype fließen zu viel Zeit und zu viel Geld.

  • Aber derzeit gibt es nichts anderes, dem man hinterherjagen könnte.
  • Code nicht zu verifizieren ist letztlich einfach Glücksspiel.

• Ich mache mir Sorgen, wie es künftig mit kritischer Infrastruktursoftware weitergeht. Wenn selbst Flugsoftware in diesen Trend hineingezogen wird, könnte das fatale Folgen haben.

  • Trotzdem wird Code für Kerninfrastruktur wohl weiterhin menschenzentriert geschrieben werden. AI dürfte eher als unterstützendes Werkzeug zur Qualitätsverbesserung eingesetzt werden.