KIberblick

Einer der teuersten Fehler? Hotz' Warnung im Realitätscheck

George Hotz nennt KI-Coding-Agenten einen der teuersten Irrwege der Branche. Was die Studienlage dazu sagt, wo er recht hat und wo er überzieht.

Entwickler:inProjektleiter:inQA / Tester:in
28. Mai 202610 Min. Lesezeit

George Hotz hat am 24. Mai einen Blogpost veröffentlicht, der in der Entwickler-Szene einschlug. Titel: "The Eternal Sloptember". Sein Fazit nach sechs Monaten praktischer Tests mit allen gängigen Modellen und Tools: "Die Einführung von KI-Agenten in die Softwareentwicklung wird einer der teuersten Fehler in der Geschichte des Feldes."

Das ist eine harte Ansage von jemandem, der weiß, wovon er redet. Hotz, in der Szene als "geohot" bekannt, lieferte mit 17 den ersten iPhone-Jailbreak, knackte später die PS3-Sicherheitsarchitektur, gründete comma.ai und entwickelt heute tinygrad, eine schlanke Alternative zu PyTorch. Er ist kein Theoretiker, sondern hands-on Entwickler mit Spur. Und er war früher LLM-Optimist: o1-preview nannte er noch "das erste Modell, das überhaupt programmieren kann". Diese Kehrtwende macht den Post lesenswert.

Lohnt sich also Panik? Wir haben die These gegen die Studienlage gehalten. Das Ergebnis ist weniger eindeutig als die Schlagzeile, aber interessanter.

Was Hotz konkret sagt

Hotz' Kernvorwurf ist nicht, dass Agenten nutzlos sind. Sein Vorwurf ist, dass sie eine Qualität vortäuschen, die nicht da ist:

"Agenten können nicht programmieren, und es dauert immer länger, das zu merken. Sie sind ein hochentwickeltes statistisches Modell, das die Verteilung von Programmcode nachahmt. Der Output ist kaputt, aber auf eine Weise, die immer schwerer zu erkennen ist."

Sein Bild dafür ist die Slot Machine: Der Agent erledigt die ersten 80 Prozent in Sekunden, dann gibt er dir den Hebel in die Hand und du ziehst immer wieder, in der Hoffnung, dass der Feinschliff diesmal klappt. Er klappt nie ganz.

Der zweite, eigentlich brisantere Teil seiner These betrifft Organisationen, nicht Einzelpersonen:

"Agenten werden großen Organisationen mehr schaden als leistungsstarken Einzelnen oder kleinen Teams. Die schwächsten Leute haben diesen Selbstcheck nicht. Sie sind die, die mit den Agenten 10x Output produzieren. Was glaubst du, passiert mit dem Durchschnitts-Output dieser Organisation?"

Man sollte dabei zwei Dinge auseinanderhalten. Sein Urteil über die Code-Qualität stammt aus der eigenen, sehr disziplinierten Arbeit an tinygrad. Dass die Agenten ihn gerade dort nicht überzeugt haben, wo sorgfältig geprüft wird, macht diesen Teil eher schwerer zu entkräften. Wo die Qualitätsdisziplin hoch ist, fällt schlechter Output schnell auf. Hotz sagt, er fällt eben trotzdem an, und der Feinschliff kommt nie ganz. Dass ein gutes Team die Probleme dann zügig fixt, ist gerade sein Punkt: Es kostet die Zeit, die der Agent vorne eingespart hat.

Seine zweite These, die über große Organisationen, ist dagegen eine Hochrechnung von außen. Hotz arbeitet in kleinen Teams, nicht in Konzernen mit schwächeren Entwicklern und lockerer Review-Kultur. Was dort passiert, beobachtet er, er erlebt es nicht. Seine Aussagen sind anekdotische Evidenz, keine Messreihe. Genau deshalb ist der Abgleich mit Daten nötig.

Was die Daten sagen

Auf den ersten Blick stützt die Forschung Hotz erstaunlich gut.

Die METR-Studie ist der sauberste Test, den es bisher gibt: ein randomisiertes kontrolliertes Experiment mit 16 erfahrenen Open-Source-Entwicklern und 246 realen Aufgaben aus großen, gut gepflegten Repositories. Das Ergebnis widerspricht der Intuition fast aller Beteiligten.

METR-Studie: Erwartung vs. RealitätWert
Was die Entwickler vorher erwarteten24% schneller mit KI
Was sie nachher zu erinnern glaubten20% schneller gewesen zu sein
Was tatsächlich gemessen wurde19% langsamer

Diese Lücke zwischen Gefühl und Messung ist der gefährlichste Befund der ganzen Debatte. Wer KI-Tools nutzt, fühlt sich produktiver, auch wenn er es objektiv nicht ist. Ein Folge-Update von METR im Februar 2026 mit neueren Modellen zeigte ein ähnliches Bild, hat aber ein Designproblem: Immer mehr Teilnehmer weigerten sich überhaupt, Aufgaben ohne KI zu bearbeiten.

Die zweite Quelle ist Faros AI, das zwei Jahre Telemetrie von 22.000 Entwicklern und über 4.000 Teams ausgewertet hat. Bei hoher KI-Adoption stieg der Task-Durchsatz um knapp 34 Prozent. Gleichzeitig:

  • Code-Churn (kurz nach dem Schreiben wieder geänderter Code): +861%
  • Bugs pro Pull Request: +28%
  • PR-Größe: +51%
  • Pull Requests, die ohne jedes Review in Produktion gehen: +31%

Das ist Hotz' Slot-Machine-Effekt in Zahlen: mehr Output, der hinten teurer wird. Der Google DORA Report 2025 passt ins Bild. KI-Adoption korreliert dort mit mehr Releases, aber weiterhin negativ mit der Stabilität der Auslieferung. 30 Prozent der Befragten haben wenig oder kein Vertrauen in KI-generierten Code. Wer den Mechanismus dahinter verstehen will, findet ihn im Artikel zur Code-Qualität bei KI-generiertem Code und zur unsichtbaren Arbeit hinter KI-Code.

Wo Hotz überzieht

So weit, so düster. Aber die Gegenrechnung fehlt bei Hotz komplett, und sie ist nicht klein.

Das stärkste Gegenbeispiel ist Spotify. Das interne System Honk, gebaut auf Claude Code und dem Anthropic Agent SDK, mergt laut Anthropic-Kundenstory über 650 agent-generierte Pull Requests pro Monat in Produktion. Bei komplexen Code-Migrationen spart das Team bis zu 90 Prozent der Engineering-Zeit. Spotifys erfahrenste Entwickler schreiben seit Dezember 2025 keinen Code mehr von Hand.

Der wichtige Zusatz, den die Schlagzeile verschweigt: Honk funktioniert nur, weil 15 Jahre Infrastruktur darunterliegen. Standardisierte Build-Systeme, umfangreiche Testsuiten, ein eigenes Fleet-Management. Kein Team kann das einfach kopieren. Aber es zeigt, dass Agenten unter den richtigen Bedingungen produktiv arbeiten, und das in genau der großen Organisation, der Hotz den Schaden prophezeit.

Auch Andrej Karpathy, Mitgründer von OpenAI und inzwischen bei Anthropic, steht als Gegenpol da. Er hält für richtig eingesetzte Entwickler mehr als 10x Produktivität für realistisch. Interessant ist, dass er Hotz' Qualitätsbedenken trotzdem indirekt bestätigt: Wenn er sich den Agent-Code genau ansehe, bekomme er "manchmal ein bisschen einen Herzinfarkt, weil es nicht super toller Code ist. Er ist sehr aufgebläht, viel Copy-paste, brüchige Abstraktionen." Beide sehen also dasselbe Qualitätsproblem. Sie ziehen nur unterschiedliche Schlüsse daraus. Die optimistische Lesart hat KIberblick im Artikel von Vibe Coding zu Agentic Engineering ausführlicher beschrieben.

Der eigentliche Riss

Wenn man Hotz, Karpathy und die Studien nebeneinanderlegt, löst sich der Widerspruch auf. Es geht nicht um die Frage "Agenten gut oder schlecht", sondern um Bedingungen.

Agenten helfen messbar bei neuen, klar abgegrenzten Aufgaben. Der oft zitierte GitHub-Copilot-Wert von 55 Prozent schneller stammt aus genau so einem Szenario: ein HTTP-Server in JavaScript, von null gebaut, ohne Altlasten, ohne gemessenen Review-Aufwand. Sie scheitern dagegen an Legacy-Code, dem das implizite Wissen aus alten Postmortems und Slack-Threads fehlt. Heraus kommt Code, der kompiliert und trotzdem systemisch falsch ist.

Und sie sind, das ist Hotz' stärkster Punkt, eine andere Sache in der Hand eines Seniors als in der eines Anfängers. Der Senior erkennt schlechten Output und wirft ihn weg. Der Anfänger produziert 10x davon und merkt es nicht. Genau diese Sorge haben wir schon bei der Lage der Junior-Entwickler beschrieben. Dass ein zu locker geführter Agent realen Schaden anrichtet, zeigte der Fall, in dem ein Agent eine Produktivdatenbank gelöscht hat, oder die Serie schwerer Ausfälle bei Amazon unter KI-Nutzungs-Zwang.

Was das für Teams im DACH-Raum heißt

Hotz' Pauschalurteil ist zu pauschal. Aber als Warnung vor blinder Euphorie trifft er etwas Richtiges. Drei Punkte sind für Teams hier konkret.

Erwartungsmanagement. Die METR-Lücke zwischen gefühlter und tatsächlicher Geschwindigkeit ist gefährlich, wenn die Führungsebene nach Sprint-Velocity urteilt. Mehr gemergte PRs sind kein Produktivitätsbeweis, solange niemand den nachgelagerten Aufwand misst. Wer das selbst sauber erheben will, findet den Ansatz im Artikel zum Messen von KI-Produktivität.

Review ist Pflicht, nicht Kür. Wenn laut Faros fast ein Drittel der PRs ungeprüft in Produktion geht, ist das bei DSGVO-Verpflichtung, IT-Sicherheitsverantwortung und Haftungsfragen ein echtes Problem. KI-generierter Code ist vor dem Review niemandem zuzurechnen.

Kostenkontrolle. Das Slot-Machine-Prinzip kostet Tokens. Schwächere Entwickler, die immer wieder den Hebel ziehen, können die Rechnung in die Höhe treiben, ohne dass am Ende brauchbarer Code entsteht.

Das Muster ist dabei nicht neu. Wer die Einführung von Scrum oder Kanban miterlebt hat, kennt es. Teams, die Agilität als Freibrief verstanden haben, Planung, Architektur und Absprachen wegzulassen, haben damit selten bessere Software gebaut. Gescheitert ist hinterher angeblich "das Agile", nicht der eigene Umgang damit. Bei KI läuft es genauso. Ein Agent, dem man ohne Spezifikation, Tests und Review freie Hand lässt, liefert Murks, und schuld ist dann "die KI". Der ehrlichere Befund ist meistens, dass man sich die Sorgfalt gespart hat, die das Werkzeug erst nützlich macht. Das Werkzeug verstärkt, wie ein Team arbeitet. Ein schludriges Team wird mit KI schneller schludrig.

Der nüchterne Schluss: KI-Agenten sind weder der teuerste Fehler der Branchengeschichte noch der versprochene 10x-Knopf. Sie sind ein scharfes Werkzeug, dessen Ertrag fast vollständig davon abhängt, wer es führt und wofür. Hotz hat recht, dass das in vielen Organisationen schiefgeht. Er hat unrecht, dass es schiefgehen muss.

Quellen7