Faktor 10 steckt nicht im Modell

Über 50 Teams im selben Konzern, alle mit denselben KI-Werkzeugen, alle an bestehenden Systemen statt auf der grünen Wiese, alle mit der üblichen Mischung aus Junior- und Senior-Entwicklern. Gezählt wurden keine Commits, sondern Features, die tatsächlich in Produktion gingen. Ein Teil der Teams kam auf weniger als das Dreifache des bisherigen Durchsatzes, andere auf mehr als das Zehnfache.

Key Takeaways (TL;DR)

• Arbeitsweise umbauen statt Tools ergänzen: Ändere den Prozess, bevor du den Nutzen eines Coding-Agenten bewertest.
• Fehlgriffe als Kontextlücke lesen: Frag bei jedem falschen Ergebnis zuerst, welche Information gefehlt hat, und leg sie dort ab, wo der Agent sie findet.
• Anlaufverlust einplanen: Rechne mit einer langsameren Phase, in der du Werkzeuge, Fehlermeldungen und Codestruktur für Agenten herrichtest.
• Dich selbst aus der Schleife nehmen: Gib Agenten Aufgaben, die sie gegen Compiler und Tests selbst abschließen können, statt jeden Zwischenschritt zu bestätigen.
• Feedback lokal und deterministisch machen: Mocke externe Dienste auf dem eigenen Rechner, damit ein roter Test eindeutig auf den eigenen Code zeigt.

Basiert auf “I Looked Into How Devs Are Actually Using AI” von ForrestKnight. Das Original findest du hier: https://www.youtube.com/watch?v=qCheZDyFX2U. Ergänzt um “How frontier teams are reinventing AI-native development” von Swami Sivasubramanian im AWS-Blog: https://aws.amazon.com/blogs/machine-learning/how-frontier-teams-are-reinventing-ai-native-development/

Zwischen minus 19 Prozent und Faktor 10 liegt keine Modellfrage

ForrestKnight ist Softwareentwickler und YouTuber, dessen Bekanntenkreis von den großen KI-Labs über frisch finanzierte Startups bis zu Banken, Rüstung und Gesundheitswesen reicht. Dort sieht er dasselbe Bild wie in den Studien, die er für das Video durchgearbeitet hat: Die Effekte von KI auf den Output streuen von minus 19 Prozent bis zum Doppelten und darüber, obwohl alle dieselben Modelle und dieselben Harnesses nutzen dürfen.

Mit Geld lässt sich das nicht erklären. KI-Labs haben zwar praktisch unbegrenzt Compute, aber ein Unternehmen, das sein Token-Budget aufstockt, verzehnfacht damit nicht seinen Durchsatz. Aufschlussreich wird es erst in einem Vergleich, in dem Werkzeug, Firma und Budget konstant bleiben. Den liefert Amazon in drei Stufen.

Sechs Leute in 76 Tagen, aber nicht irgendwelche sechs

Die erste Stufe war Bedrock, der Dienst, über den AWS-Kunden Modelle wie Claude und GPT nutzen. Für die neue Inference Data Plane hatte Amazon 30 Entwickler über 12 bis 18 Monate geschätzt. Sechs Senior Engineers mit Kiro, Amazons hauseigenem Coding-Agenten, lieferten sie in 76 Tagen. Das klingt nach Durchbruch, bis man sieht, wer die sechs waren: Leute, die verteilte Systeme und LLM-Architektur ohnehin in- und auswendig kannten, darunter zwei Distinguished Engineers.

Die zweite Stufe lief bei Prime Video mit einem zehntägigen Sprint und wieder sechs Engineers. Danach sank die Schätzung für das Projekt von 90 auf 24 Wochen. Allerdings hatte ein Senior Engineer vorher drei Wochen lang kleine, präzise abgegrenzte Aufgaben geschrieben, die danach nur noch abzuarbeiten waren. Erst die dritte Stufe bildet einen normalen Arbeitsalltag ab.

Bei Amazon Stores, also amazon.com und den physischen Läden, zählte die normalisierte Deployment-Geschwindigkeit: ausgelieferte Features pro Sprint im Verhältnis zur eigenen Historie des Teams. Commits spielten keine Rolle.

Unter Faktor 3 blieb, wer KI auf den alten Sprint gesetzt hat

Die schwächere Hälfte hat das Werkzeug eingesteckt und sonst nichts verändert. Gewohnheiten aus früheren Sprints blieben, wie sie waren, und auch so reichte es für bis zu Faktor 3. Die stärkere Hälfte hat ihre Arbeitsweise grundlegend umgestellt. Amazon hat diese Gruppen anschließend interviewt und die Ergebnisse bewusst Gewohnheiten genannt, nicht Tricks, weil der neue Ablauf zum Standard werden muss.

Wissen aus Slack und Köpfen gehört in den Kontext

Was in Slack-Threads, Review-Kommentaren und Köpfen steckte, wanderte in Steering- und Skill-Dateien. Lieferte der Agent etwas Falsches, lautete die erste Frage nicht, was das Modell falsch gemacht hat, sondern was ihm niemand gesagt hatte. Und als die Modelle im Lauf von 2025 besser wurden, wurden Regeln wieder gestrichen.

Auf den ersten Blick widerspricht das der ETH-Studie zu Kontextdateien, nach der Repository-Übersichten die Inferenzkosten um über 20 Prozent erhöhen, ohne die Erfolgsquote zu verbessern. Beim zweiten Blick beschreiben beide dasselbe. Aufgeschrieben wurde kein Verzeichnisbaum, sondern Wissen, das im Code nicht steht: die Konvention aus dem Review, die Ausnahme aus dem Chat. Dass Regeln mit besseren Modellen wieder verschwanden, passt zum zweiten Teil des Befunds: Was das Modell selbst herausfindet, kostet im Prompt nur Tokens.

Die erfolgreichen Teams wurden zuerst langsamer

Am Anfang sank die Produktivität der späteren Spitzenteams, weil sie die Umgebung umbauten. Sie schrieben MCP-Server, damit Agenten alle nötigen Systeme erreichen, formulierten Fehlermeldungen so um, dass ein Modell erkennt, was genau kaputt ist, und strukturierten Codebasen für die Navigation durch Agenten um. Einige wechselten sogar die Sprache, von Python oder JavaScript zu TypeScript oder Rust, damit Typechecker und Compiler das Feedback liefern, das sonst ein Mensch geben müsste. Das ist Harness Engineering im Wortsinn: Das Modell bleibt gleich, die Umgebung wird besser.

Wer jede Antwort abnickt, ist selbst der Engpass

Die Spitzenteams schrieben nur noch 1 bis 2 Prozent ihres Codes von Hand. Den Rest erledigten Agenten, die stundenlang in Schleifen liefen, oft mehrere parallel, mit einer klaren Vorgabe: weitermachen, die eigene Arbeit prüfen und erst zurückkommen, wenn alles kompiliert, läuft und alle Tests grün sind. Wer dagegen alle 30 Sekunden auf eine Rückfrage antwortet, begrenzt den Durchsatz auf die eigenen Arbeitsstunden. Damit so eine Schleife sinnvoll endet, braucht sie Abbruchbedingungen, die nicht das Modell selbst bewertet, sondern Compiler und Testsuite.

Eine Spezifikation korrigierst du billiger als einen Diff

Ein vager Prompt führt zu Code, über dessen Implementierung du anschließend mit dem Agenten streitest. Die Spitzenteams klärten deshalb vorher, was sie meinten. Die drei Wochen Aufgabenzerlegung bei Prime Video sind die Extremform davon, und Kiro hat Spec-Driven Development fest eingebaut. Ein vollständiges Spezifikationsdokument für jede Kleinigkeit ist aber übertrieben und macht die Ergebnisse eher schlechter. Der Kern ist ökonomisch: Ein Absatz Klartext lässt sich schneller und mit weniger Tokens korrigieren als hunderte Zeilen generierter Diffs.

Lokale Mocks machen die Testsuite zur Schleife für den Agenten

Linter, Unit-, Integrations-, Performance- und Sicherheitstests waren bei den Spitzenteams vollständig ausgebaut, denn jede dieser Prüfungen verlängert die Strecke, auf der ein Agent ohne Mensch weiterarbeiten kann. Dazu mockten sie ihre Dienste lokal auf dem Laptop mit deterministischen Antworten. So laufen alle Integrationstests ohne Cloud-Dienste, der Agent korrigiert sich, bevor Code die Pipeline erreicht, und je schneller ein Durchlauf ist, desto mehr Durchläufe schafft er.

So könnte das in einem TypeScript-Projekt mit Vitest und MSW 2 aussehen. Das Snippet ist eine Illustration und stammt nicht aus der Quelle:

// test/setup.ts (in vitest.config.ts unter test.setupFiles eingetragen)
import { afterAll, afterEach, beforeAll } from 'vitest';
import { setupServer } from 'msw/node';
import { http, HttpResponse } from 'msw';

const serviceHandlers = [
  http.get('https://inventory.internal/api/items/:sku', ({ params }) =>
    HttpResponse.json({ sku: params.sku, available: 12, warehouse: 'FRA1' }),
  ),
  http.post('https://payments.internal/api/charges', async ({ request }) => {
    const charge = (await request.json()) as { amountCents: number };
    return charge.amountCents > 0
      ? HttpResponse.json({ status: 'authorized' }, { status: 201 })
      : HttpResponse.json({ error: 'amountCents must be positive' }, { status: 422 });
  }),
];

export const server = setupServer(...serviceHandlers);

// Ungemockte Requests brechen den Test mit klarer Meldung ab,
// statt still gegen einen echten Dienst zu laufen.
beforeAll(() => server.listen({ onUnhandledRequest: 'error' }));
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

Die Antworten sind deterministisch, also lässt sich ein roter Test eindeutig dem eigenen Code zuordnen. Und onUnhandledRequest: 'error' macht aus einem vergessenen Mock eine verwertbare Fehlermeldung statt eines Timeouts.

Die Zahlen stammen vom Hersteller des Werkzeugs

Der stärkste Einwand gegen all das: Amazon verkauft Kiro. Veröffentlicht hat die Zahlen AWS-Vizepräsident Swami Sivasubramanian, und die ersten beiden Piloten waren mit Leuten besetzt, die kein Durchschnittsteam abbildet. Auch intern sind die Angaben nicht ganz sauber. Wenn rund die Hälfte der Teams unter 3x blieb, kann der genannte Median von 4,5x nicht für alle Teams gelten, und der AWS-Text lässt offen, auf welche Gruppe er sich bezieht.

Der Einwand trifft die absoluten Faktoren, aber nicht den Vergleich. Innerhalb von Amazon Stores waren Werkzeug, Konzern, Metrik und Zeitraum für alle gleich. Selbst wenn jeder Faktor gleichmäßig geschönt wäre, bliebe der Abstand zwischen umgebauten und unveränderten Arbeitsweisen. Dazu kommt der Zeitpunkt: Die Piloten liefen 2025 und damit vor Opus 4.5, das am 24. November 2025 erschien. Die Zehnfach-Teams arbeiteten mit Modellen wie Claude 3.7, 4.0 und 4.1, die auf die Bitte um ein kleines Refactoring in einer Datei gern 20 ungefragte Änderungen quer durch die Codebasis zurückgaben. Für 2026 will Amazon das Vorgehen von 50 auf 2.000 Teams ausweiten. Auf die Frage, wo die versprochenen 10x-Entwickler eigentlich bleiben, hat ForrestKnight eine knappe Antwort:

“They’re here. You’re just not going to see it if you were solely relying on the model and giving in minimal effort into using it.”

3 Schritte zur Umsetzung

1. Fehlgriffe als Kontextlücken protokollieren: Notiere zwei Sprints lang bei jedem falschen Ergebnis des Agenten, welche Information gefehlt hat. Projektspezifisches Wissen wandert in Steering- oder Skill-Dateien, alles, was das Modell aus dem Code selbst lesen kann, bleibt draußen.
2. Die Feedback-Schleife auf den Laptop holen: Mocke externe Dienste deterministisch, lass ungemockte Requests hart fehlschlagen und bündle Typecheck, Lint und Tests in einem einzigen Befehl, den der Agent bis Grün wiederholen kann.
3. Deployte Features messen, nicht Commits: Vergleiche ausgelieferte Features pro Sprint mit der eigenen Historie des Teams und plane die ersten Sprints offen als Umbauphase ein, damit der anfängliche Rückgang nicht als Scheitern gilt.

Die Teams unter Faktor 3 und die Teams über Faktor 10 hatten dieselben Lizenzen, und den Unterschied findest du in keinem Modell-Changelog.