100x Developer? Das AI-only-Team, das spektakulär gescheitert ist

Wes Winder entließ sein Entwicklungsteam mit der Begründung, KI könne es ersetzen - nur um kurz darauf wieder einzustellen. KI steigert die Produktivität, kann aber nicht die Zusammenarbeit und das Fachwissen ersetzen, die für die Softwareentwicklung unerlässlich sind. Sein Scheitern ist ein warnendes Beispiel dafür, dass man die Fähigkeiten der KI nicht überbewerten sollte.

Kann AI ein komplettes Software-Engineering-Team ersetzen? Im Dezember 2024 dachte der kanadische Entwickler Wes Winder genau das. Er machte Schlagzeilen, als er sein gesamtes Engineering-Team entließ und durch "o1" ersetzte. Mit seinem AI-gestützten One-Man-Team behauptete er, 100-mal produktiver zu sein. Nur wenige Wochen später war er zurück auf LinkedIn – auf der Suche nach neuen Entwickler:innen.

Die Tech-Community reagierte mit einer Mischung aus Spott und Schadenfreude. Vielleicht fiel die Reaktion so heftig aus, weil viele fürchten, dass AI ihre Jobs ersetzen könnte. Gleichzeitig gibt es enormen Hype rund um "AI" – während viele Entwickler:innen schon lange betonen: Das sind nur statistische Modelle. Und ja, sie haben recht. Trotzdem ist AI beeindruckend, und hinter dem Hype steckt reale Substanz. Nur eben nicht ganz so, wie Winder dachte.

Was AI gut kann

Tools wie GitHub Copilot, Cursor und JetBrains verändern ohne Zweifel die Art, wie Entwickler:innen arbeiten. Doch statt Menschen zu ersetzen, befähigen LLMs Teams – inklusive Product Ownern und Tech Leads – dazu, komplexe Herausforderungen schneller zu lösen.

Kontext schaffen

Oft sind Menschen irritiert, wenn sie mit sogenannten "Halluzinationen" konfrontiert werden – also plausiblen, aber frei erfundenen Inhalten. Man muss akzeptieren: Das ist kein Fehler im System, sondern liegt in der Natur der Technologie. Meist ist schwacher Kontext die Ursache: fehlende Datenstrukturen, fehlender Code oder schlicht zu wenig Projektwissen. Deshalb gilt: Soliden Kontext bereitstellen. Wenn man alle relevanten Modelle, Typen und Dokus einbindet, kann man die AI gut im Projekt verankern. Meist reicht eine Auswahl an Code-Beispielen. Wenn etwa eine neue UI-Komponente eingebunden werden soll, genügen Teile des Domain-Modells, eine ähnliche bestehende Komponente und die zugehörigen ViewModels. Das reicht meist aus, um eine passende Antwort zu erhalten.

Das richtige Modell nutzen

Der nächste wichtige Punkt ist die Auswahl des Modells. Nicht jedes Modell ist gleich. Allgemeine Modelle wie GPT-4o oder Claude 3.5 eignen sich gut für taktische Aufgaben: Testgenerierung, Code-Output in größerem Stil oder das Extrahieren von Strings für i18n. Der Prompt könnte etwa so aussehen:

/file types/recipe.ts
/file core/services/RecipeService.ts
/file app/dashboard/page.tsx

create a new page that displays the current user's recipes

Mit den richtigen Files und einem guten Beispiel liefert das Modell solide Ergebnisse – ganz ohne Prompt Engineering.

Doch bei komplexeren Aufgaben wie Refactorings oder hartnäckigen Bugs stößt man an Grenzen. Hier lohnt sich der Wechsel zu einem Reasoning-Modell wie Claude 3 Opus. Diese Modelle haben zwar ein kleineres Output-Limit, sind aber für strategisches Denken hervorragend geeignet.

Ein Beispiel:

/file types/recipe.ts
/file core/services/RecipeService.ts
/file app/recipe/page.tsx
/file hooks/useRecipes.ts

Outline a refactoring to separate concerns between UI, domain, and services

Das Modell analysiert den Code architektonisch und gibt eine strukturierte Schritt-für-Schritt-Anleitung. Diese kann dann wiederum von einem generativen Modell wie GPT-4o umgesetzt werden. Der Wechsel zwischen Modelltypen ist in der Praxis erstaunlich effektiv.

Auch bei Code Reviews oder Debugging zahlt sich ein Reasoning-Modell aus – vor allem dann, wenn strategisches Verständnis gefragt ist.

Aufbau einer Prompt Library

Beim Kontexterstellen helfen moderne IDEs enorm. Cursor, Copilot und Tabnine machen einen guten Job, aber besonders spannend ist der Ansatz von Zed. Dort gibt es Slash-Kommandos wie:

• /file: Fügt Dateien oder Ordner in den Prompt ein
• /fetch: Holt Markdown-Dokumentation via GET-Request von GitHub
• /prompt: Fügt gespeicherte Prompts aus einer Prompt Library ein

Jetzt stellen wir uns vor, dass wir Internationalisierungsstandards durchsetzen müssen. Anstatt dem LLM zu erklären, wie das geschehen soll und jedes Mal einen detaillierten Kontext zu erstellen, können wir einfach folgenden Prompt eingeben:

/prompt i18n
/file app/shopping-cart/

Das Team würde alle notwendigen Beispiele, Richtlinien und aktuellen Übersetzungsdateien in die i18n-Eingabeaufforderung einfügen und die Anweisung geben, diese auf alle folgenden Dateien anzuwenden. Das Modell könnte alle unübersetzten Strings aus allen Dateien im Sammelordner extrahieren und sogar die Übersetzungen selbst erstellen.

Die Erstellung einer solchen Prompt-Bibliothek rationalisiert den Entwicklungsprozess und macht die Qualitätsstandards für jedes Teammitglied transparent. Sie kann sogar als Lehrmittel für junge Entwickler:innen dienen. Angesichts der wachsenden Zahl von Anforderungen an eine Codebasis kann dies die mentale Belastung jedes Teammitglieds verringern.

Wo AI an Grenzen stößt

Als Winder sein Team entließ, wollte er der Held sein: der 100x Engineer. Solche Entwickler:innen gibt es durchaus, aber echte Produktivität kommt vor allem durch Führungsqualitäten, gute Architekturentscheidungen und das gezielte Einsetzen von Tools. AI kann ein Beschleuniger sein – aber kein Ersatz für echte Teamleistung.

KI kann als gutes Schmiermittel fungieren, um die Reibung zu reduzieren und die Abwanderung innerhalb eines Teams zu verringern, um vielleicht diese „100-fachen“ Gewinne zu erzielen. Aber bei jedem nicht-trivialen Projekt kann dies nicht von einer einzelnen Person geleistet werden. LLMs verbessern die menschliche Fähigkeit, Code zu produzieren, so wie es ein Smartphone mit Internetzugang tut oder in alten Zeiten: das Handbuch.

Fehlende strategische Fähigkeiten

Reasoning-Modelle wie o3 können zwar gute Pläne liefern, aber keine komplexen Fortschritte über längere Zeit steuern. Sie funktionieren am besten bei gut umrissenen Aufgaben. Menschliche Intuition – also das Vorwegnehmen von Problemen oder das Priorisieren von Aufgaben – bleibt auf absehbare Zeit ein Vorteil.

Kein echtes Verständnis

Wenn man ChatGPT nach seinen Schwächen fragt, wird es sagen, dass es ihm an echtem Verständnis mangelt. Dass es aufgrund seiner statistischen Papageien-Natur nur überzeugenden und oft funktionalen Code erzeugen kann, aber alles mit einem begrenzten Verständnis der Muster und ohne echtes Verständnis. Das mag stimmen, aber Ned Batchelder hat kürzlich argumentiert, dass es aus funktionaler Sicht keine Rolle spielt, wie ein System die Ergebnisse produziert. Ein Flugzeug fliegt nicht wie ein Vogel. Aber es fliegt trotzdem.

Begrenzte Debugging- und Review-Fähigkeiten

Der Mangel an Verständnis zeigt sich vielleicht am deutlichsten beim Debugging. Meiner persönlichen Erfahrung nach konnten LLMs selbst mit dem richtigen Kontext selten die Ursache eines Fehlers finden und schlugen idiotische Lösungen vor, die auf Vermutungen basierten. Vielleicht liegt es am Training oder ein paar Milliarden Parameter mehr würden helfen, aber letztendlich sind Menschen in diesem Bereich immer noch um Größenordnungen stärker.

Natürlich treibt GitHub die Code-Review-Funktionalität voran und es sieht vielversprechend aus. Aber es wird immer wieder betont, dass es Code-Reviews nicht ersetzen wird. Es ist ein intelligenter Linter, der nach offensichtlichen Fehlern suchen kann.

Begrenzter Kontext & fehlendes Domänenwissen

LLMs versagen regelmäßig bei proprietären oder unbekannten Bibliotheken, die sie nicht kennen. Da sie zustandslos arbeiten, müssen Entwickler:innen für jedes Projekt den Kontext mühsam neu aufbauen. Gut dokumentierte APIs sind hier aktuell die beste Lösung – bis IDEs mit besseren semantischen Suchfunktionen nachziehen.

Was die Branche daraus lernen kann

So beeindruckend die Fortschritte im Bereich AI auch sind: Die Grundprinzipien erfolgreicher Softwareentwicklung haben sich nicht geändert. Langfristiges Denken, menschliche Zusammenarbeit und Erfahrung bleiben entscheidend. Die Gewinner-Teams der Zukunft werden AI intelligent integrieren und gezielt einsetzen.

Wer 100x Produktivität über Nacht verspricht, verkauft Illusionen. Erfolg bedeutet nicht, mehr Code zu schreiben – sondern den richtigen Code, auf die richtige Weise, für die richtigen Probleme. AI kann dabei helfen. Aber am Ende ist sie nur ein Werkzeug. Und wir müssen lernen, es klug zu nutzen.

Die Frage ist nicht, ob AI Entwickler:innen ersetzt – sondern: Welche Entwickler:innen AI am besten für sich nutzen.