Der mythische KI-Monat

Was Fred Brooks uns über Coding-Agenten zu sagen hätte

Es gehört zu den stilleren Demütigungen unserer Branche, dass das präziseste Erklärungsmodell für die KI-Euphorie des Jahres 2026 ein Buch von 1975 ist.

Fred Brooks beschrieb in „The Mythical Man-Month“ die immer wiederkehrende Hoffnung auf das eine Werkzeug, die eine Methode, die eine Technologie, die Softwareentwicklung endlich um eine Größenordnung beschleunigt — und er erklärte, methodisch und unbarmherzig, warum diese Hoffnung systematisch enttäuscht wird. Damals hieß die Silberkugel Hochsprache, dann CASE-Tool, dann Objektorientierung. Heute heißt sie Coding-Agent. Der Name hat sich geändert, das Argument nicht.

Ich will Brooks hier nicht als Autorität gegen KI in Stellung bringen. Im Gegenteil: Wer ihn genau liest, findet die überzeugendste Begründung dafür, wofür KI in der Softwareentwicklung wirklich taugt — und es ist nicht das, wofür wir sie gerade fast ausschließlich bauen.

Brooks‘ unbequeme Arithmetik

Beginnen wir mit einer Zahl, die in der aktuellen Debatte erstaunlich selten auftaucht. Brooks teilte den Zeitplan eines Softwareprojekts nach seiner Erfahrung so auf: ein Drittel Planung, ein Sechstel Codierung, ein Viertel Komponententests, ein Viertel Systemtest mit allen Teilen in der Hand.

Phase	Anteil
Planung	1/3
Codierung	1/6
Komponententest und früher Systemtest	1/4
Systemtest, wenn alle Komponenten vorliegen	1/4

Das eigentliche Schreiben von Code — jene Tätigkeit, die wir gerade mit Milliarden an Rechenleistung automatisieren — machte bei Brooks etwa ein Sechstel des Projekts aus. Sechzehn, siebzehn Prozent. Spätere Erhebungen landen je nach Methodik zwischen zwanzig und dreißig.

Wer Amdahls Gesetz kennt, sieht sofort, worauf das hinausläuft. Selbst wenn eine KI das Codieren auf null beschleunigte — perfekt, fehlerfrei, instantan —, läge der maximale Gesamtgewinn bei einem Faktor von etwa 1,2.

Zwanzig Prozent schnellere Projekte.

Ein ordentlicher Produktivitätsgewinn, gewiss. Aber keine Revolution, und Lichtjahre entfernt von den Versprechen, mit denen heute Bewertungen gerechtfertigt und Stellen gestrichen werden.

Man kann den Einwand vorwegnehmen: KI hilft ja nicht nur beim Tippen, sie hilft auch beim Testen, beim Dokumentieren, beim Debuggen. Stimmt. Rechnen wir also großzügig und schreiben der KI das Codieren und die beiden Testphasen komplett gut — die Hälfte des Projekts, auf null gedrückt. Dann bleibt das eine Drittel Planung übrig, und Amdahl deckelt den Gewinn bei Faktor drei. Großzügiger geht es kaum, und selbst dieser geschönte Wert bestätigt Brooks‘ These aus „No Silver Bullet“ wörtlich: keine einzelne Entwicklung verspricht auch nur eine Größenordnung an Produktivitätsgewinn. Drei ist nicht zehn. Der Engpass ist nicht das Drittel, das wir automatisieren — es ist das Drittel, das wir nicht anfassen können.

Essenz und Akzidenz

Brooks hat dieses Argument 1986 in „No Silver Bullet“ geschärft, und die dort getroffene Unterscheidung ist das eigentliche Werkzeug, um die heutige Lage zu sezieren. Er trennt die essenzielle Komplexität von Software — das konzeptionelle Konstrukt aus Datenstrukturen, Algorithmen, Funktionsbeziehungen und, vor allem, aus dem Verständnis des Problems, das gelöst werden soll — von der akzidentellen Komplexität, also allem, was bloß mit der Repräsentation dieses Konstrukts zu tun hat. Syntax. Boilerplate. Build-Systeme. Die Mechanik des Tippens.

Seine These: Alle großen Produktivitätssprünge der Vergangenheit haben akzidentelle Komplexität abgebaut. Hochsprachen befreiten uns von der Buchführung über Register. Time-Sharing von der Wartezeit zwischen den Compiler-Läufen. IDEs von der Mechanik des Editierens und Verlinkens. Und weil die Akzidenz mit jeder Generation schrumpft, während die Essenz unberührt bleibt, kann keine Technologie, die nur an der Repräsentation ansetzt, je wieder eine Größenordnung herausholen. Das Restproblem ist schlicht zu klein geworden.

Large Language Models sind die mächtigste Maschine zum Abbau akzidenteller Komplexität, die je gebaut wurde. Sie übersetzen zwischen Repräsentationen — natürliche Sprache zu Python, Python zu Go, Legacy-Code zu Dokumentation — mit einer Geschwindigkeit und Breite, die alles Bisherige in den Schatten stellt. Aber sie tun kategorial dasselbe wie Hochsprachen und IDEs zuvor: Sie machen das Ausdrücken einer Lösung billiger. Sie machen nicht das Finden der Lösung billiger. Brooks‘ Argument trifft sie mit voller Wucht — nicht, weil die Modelle schwach wären, sondern weil sie auf der falschen Seite der Trennlinie operieren.

Der Token-Beweis

Das Schöne an der heutigen Lage ist, dass sich Brooks‘ These nicht mehr nur theoretisch begründen, sondern messen lässt — in Token. Jeder, der ernsthaft mit agentischen Coding-Tools arbeitet, kennt das Muster. Bei einer klar spezifizierten, sauber abgegrenzten Aufgabe ist der Agent brillant, fast unheimlich. Bei einer unscharfen Aufgabe beginnt ein teures Schauspiel: Der Agent rät eine Interpretation, implementiert sie, testet, scheitert, revidiert, implementiert die nächste Lesart, scheitert anders. Reasoning-Tokens verbrennen zu Hunderttausenden — nicht, weil das Problem rechnerisch schwer wäre, sondern weil der Agent per Trial and Error eine Information rekonstruieren muss, die nie aufgeschrieben wurde: was eigentlich gemeint war.

Dieser Tokenverbrauch ist kein Übergangsproblem, das die nächste Modellgeneration wegoptimiert. Er ist der Preis der fehlenden Spezifikation, ausgedrückt in Rechenleistung. Er macht etwas sichtbar, das vorher in den Köpfen der Entwickler verborgen lag. Die Branche hat Jahrzehnte gebraucht, um zu begreifen, dass „der Kunde weiß selbst nicht genau, was er will“ — auch das steht bei Brooks — kein Kommunikationsdefekt ist, sondern eine Grundeigenschaft von Softwareprojekten. Anforderungen entstehen iterativ, im Dialog, im Konflikt zwischen Fachbereichen, im Kontakt mit dem halbfertigen System. Ein Modell, das diese Anforderungen nicht kennt, kann sie nicht herbeireasonen. Es kann sie nur durchprobieren. Trial and Error ist hier keine Schwäche der KI, sondern die einzig mögliche Strategie bei fehlender Information — nur eine absurd teure Art, ein Gespräch zu ersetzen, das zwanzig Minuten gedauert hätte.

Damit wandert der Engpass exakt dorthin, wo Brooks ihn immer verortet hat: in die Spezifikation, das Design, die Entscheidung. Wer behauptet, KI mache Softwareentwicklung zehnmal schneller, behauptet implizit, Verstehen und Aushandeln seien zehnmal schneller geworden. Dafür gibt es nicht den Hauch einer Evidenz.

Der ehrliche Einwand

An dieser Stelle muss man fair sein, sonst baut man sich einen Strohmann. Das stärkste Argument der Gegenseite lautet nämlich gar nicht „KI tippt schneller“. Es lautet: KI senkt die Kosten des Explorierens so radikal, dass sich der Designprozess selbst verändert. Wenn ein Prototyp statt drei Tagen drei Minuten kostet, kann ich fünf Architekturen ausprobieren, wo ich früher eine durchdachte. Anforderungen, die sich erst im Kontakt mit dem laufenden System klären, klären sich dann eben fünfmal schneller. Das ist ein ernstzunehmender Punkt — und es ist, ironischerweise, ein zutiefst Brooks’scher: Sein berühmtes „plan to throw one away, you will anyhow“ feiert genau das Wegwerf-Prototyping, das die KI nun verbilligt.

Doch das Argument rettet die Silberkugel nicht, es verschiebt sie nur. Denn billiges Explorieren erzeugt einen neuen Engpass an derselben Stelle: bei der Bewertung. Fünf Prototypen in Minuten zu erzeugen, hilft nur, wenn ein Mensch in vertretbarer Zeit beurteilen kann, welcher der richtige ist — und diese Beurteilung ist reine essenzielle Komplexität, die kein Modell abnimmt. Schlimmer noch: Dieselbe Technologie, die fünf plausible Lösungen liefert, liefert auch fünf plausibel aussehende falsche Lösungen, und das schneller als je zuvor. Der Flaschenhals verlagert sich vom Produzieren zum Verifizieren. Wer schon einmal einen überzeugend formulierten, subtil falschen Pull Request eines Agenten reviewt hat, weiß, dass die gesparte Schreibzeit beim Prüfen mit Zinsen zurückgefordert wird. Die KI beschleunigt das Erzeugen von Optionen. Sie beschleunigt nicht das Urteil — und das Urteil war immer der teure Teil.

Die bedrohte konzeptionelle Integrität

Es gibt eine zweite, leisere Gefahr, und sie trägt bei Brooks einen Namen: konzeptionelle Integrität. Für ihn war sie „die wichtigste Erwägung im Systemdesign“ — wichtiger, als jede einzelne gute Idee umzusetzen. Lieber ein System, das eine einzige, vielleicht nicht perfekte Idee konsequent durchhält, als eines, das ein Dutzend brillanter, aber unzusammenhängender Einfälle vereint. Konzeptionelle Integrität entsteht, wenn ein Architekt — oder eine kleine, eng abgestimmte Gruppe — das ganze Konstrukt im Kopf hält und jede Entscheidung an einer einheitlichen Vorstellung misst.

Genau diese Integrität ist das, was KI-generierter Code von Natur aus untergräbt. Jede Generation ist lokal optimiert und global ahnungslos. Der Agent kennt den Ausschnitt im Kontextfenster, nicht die ungeschriebene Designphilosophie, die erfahrene Entwickler als geteiltes mentales Modell mit sich tragen. Das Ergebnis ist ein Code, der in jeder einzelnen Funktion vernünftig aussieht und im Ganzen zum stilistischen und architektonischen Flickenteppich wird: drei Arten, Fehler zu behandeln, vier Namenskonventionen, dieselbe Logik an fünf Stellen leicht verschieden umgesetzt. Es ist die Entropie eines Systems ohne Architekten, nur eben mit ungekannter Geschwindigkeit produziert. Brooks würde nicht überrascht sein. Er hat ein halbes Jahrhundert vorher beschrieben, was passiert, wenn die Zahl der Hände wächst und die einheitliche Vision fehlt.

Die falsche Zaubermaschine — und die richtige

Heißt das alles, KI sei für Softwareorganisationen eine Randnotiz? Keineswegs. Es heißt, dass wir die Produkte gerade am falschen Ende von Brooks‘ Buch entlangbauen. Fast alle Investitionen fließen in die Vision der Zaubermaschine, die fertigen, sicheren, schnellen Code ausspuckt — also in die Automatisierung des einen Sechstels. Dabei steht im selben Buch ein zweites Theorem, das einen ungleich größeren Hebel beschreibt.

Brooks‘ Law — „adding manpower to a late software project makes it later“ — beruht nicht auf einer Eigenschaft des Codierens, sondern auf einer Eigenschaft der Kommunikation. Bei n Beteiligten wachsen die Kommunikationspfade mit n(n−1)/2. Einarbeitung, Abstimmung, Statusberichte, das Synchronhalten des gemeinsamen mentalen Modells: Das ist der Kostenblock, der große Projekte erstickt. Und das ist, anders als das Lösen von Geschäftsproblemen, eine Domäne, in der heutige Sprachmodelle nachweislich stark sind. Zusammenfassen, übersetzen, dokumentieren, Inkonsistenzen zwischen Artefakten aufspüren, Kontext für Neue aufbereiten, Entscheidungen samt Begründung auffindbar halten. Nichts davon verlangt, dass das Modell das Geschäftsproblem löst. Es verlangt nur, dass es Information zuverlässig transportiert und verdichtet — und das kann es.

Eine KI, die ein Team von zwölf Leuten mit den Koordinationskosten von sechs arbeiten lässt, greift Brooks‘ Law direkt an und damit den eigentlichen begrenzenden Faktor großer Projekte. Das ist weniger fotogen als ein Agent, der im Demo-Video eine App aus dem Nichts generiert. Aber genau hier liegen die anderen fünf Sechstel der Arbeit: das Management von Softwareteams, die Pflege der konzeptionellen Integrität, das Übersetzen zwischen Fachbereich und Entwicklung, die ganze lästige, unscheinbare Koordination, die niemand gern macht und an der Projekte tatsächlich sterben.

Brooks schlug mit dem „Surgical Team“ vor, ein kleines Team von Spitzenkönnern mit Unterstützungsrollen zu umgeben — Toolsmith, Dokumentar, Administrator, Tester —, damit die wenigen, die das konzeptionelle Konstrukt im Kopf tragen, von allem anderen entlastet werden. Fünfzig Jahre später haben wir zum ersten Mal eine Technologie, die diese Unterstützungsrollen zu Grenzkosten nahe null besetzen kann. Das ist die realistische, sofort verfügbare Dividende der KI: nicht der Ersatz des Chirurgen, sondern ein OP-Team, das nichts kostet und nie müde wird.

Fazit

Die ehrliche Bilanz nach drei Jahren generativer KI in der Softwareentwicklung lautet: Die akzidentelle Komplexität fällt, schnell und spürbar. Die essenzielle Komplexität — Geschäftsprobleme verstehen, Lösungen finden, urteilen, die konzeptionelle Integrität wahren — steht so unbewegt da wie 1975. Wer das für eine vorübergehende Schwäche der Modelle hält, hat „No Silver Bullet“ nicht verstanden. Es ist keine Aussage über Technologie, sondern über die Natur von Software.

Die Konsequenz ist nicht Resignation, sondern eine andere Produktstrategie. Hören wir auf, ausschließlich die Zaubermaschine zu bauen, die das eine Sechstel automatisiert, das Brooks dem Codieren zugestand. Bauen wir Werkzeuge für die anderen fünf Sechstel — für Spezifikation, Kommunikation, Koordination, Teamführung. Dort liegt nicht nur die meiste Arbeit. Dort liegt, wenn man Brooks ernst nimmt, der einzige Hebel, der je eine Größenordnung versprochen hat. Die Silberkugel gibt es nicht. Aber es gibt ein OP-Team, das nichts kostet — und das ist, richtig eingesetzt, das ehrlichere Versprechen.

---

Bezüge: Frederick P. Brooks, „The Mythical Man-Month“ (1975, erweiterte Ausgabe 1995) — insbesondere Kap. 2 (Zeitplan-Aufteilung, Brooks‘ Law), Kap. 3 (The Surgical Team), Kap. 4 (Conceptual Integrity), Kap. 11 (Plan to Throw One Away) sowie der Essay „No Silver Bullet — Essence and Accident in Software Engineering“ (1986).