Mehr Entwickler eingestellt. Weniger rausgekommen. Kennst du das? Dein Dev-Team liefert zu langsam. Du bekommst Budget für zwei neue Leute. Recruiting läuft, Verträge unterschrieben, die Neuen fangen an. Sechs Monate später: Es ist nicht schneller geworden. Es ist langsamer. Die Einarbeitung frisst mehr Kapazität als sie bringt.
Das klingt paradox. Ist es aber nicht. Es gibt einen Grund, warum das Einarbeiten neuer Entwickler das Team erstmal bremst statt beschleunigt. Und es gibt einen Weg, das zu ändern. Ohne weitere Leute einzustellen.
Brooks' Law: Warum mehr Leute nicht mehr Output bedeuten
1975 hat Frederick Brooks ein Buch geschrieben, das bis heute jeder Informatik-Student kennt: The Mythical Man-Month. Seine zentrale Erkenntnis:
"Adding manpower to a late software project makes it later."
Einem verspäteten Softwareprojekt mehr Leute hinzufügen macht es noch langsamer. Das gilt nicht nur für verspätete Projekte. Es gilt für jedes Dev-Team, das über Kopfzahl statt über Struktur skaliert.
Warum? Zwei Gründe.
Erstens: Einarbeitung kostet die Besten. Neue Entwickler können nicht vom ersten Tag an produktiv mitarbeiten. Sie müssen die Codebasis verstehen, die Architektur kennenlernen, die Abläufe im Dev-Team verinnerlichen. Wer bringt ihnen das bei? Die erfahrensten Leute im Team. Genau die, die eigentlich an den wichtigsten Aufgaben arbeiten sollten.
Zweitens: Kommunikation wächst schneller als das Team. Bei 5 Entwicklern gibt es 10 Kommunikationswege. Bei 7 sind es 21. Bei 10 schon 45. Jeder neue Kopf erhöht den Abstimmungsaufwand für alle anderen. Mehr Meetings, mehr Slack-Nachrichten, mehr "Kurze Frage".
Brooks hat es auf den Punkt gebracht: "Neun Frauen können kein Kind in einem Monat bekommen." Manche Aufgaben lassen sich nicht parallelisieren.
Was wirklich passiert, wenn du neue Entwickler einstellst
So weit die Theorie. Im Alltag passiert Folgendes:
Deine neuen Entwickler brauchen einen Ansprechpartner. Jemanden mit freiem Kalender, der Fragen beantwortet, Zusammenhänge erklärt, Code Reviews macht und Konzepte bespricht.
Wessen Kalender ist am vollsten? Der vom Senior. Konzepte, Reviews, Architektur, Abstimmungen mit Product Owner und Projektmanagement. Der hat keine Zeit für Einarbeitung.
Laut Markt und Mittelstand liegt die durchschnittliche Zeit bis zur vollen Produktivität bei fünf bis sechs Monaten. Fünf bis sechs Monate, in denen dein neuer Entwickler nicht nur selbst wenig Output liefert, sondern auch den Senior von seiner Arbeit abhält.
Was dann passiert: Die guten Juniors kämpfen sich mit Frust irgendwie durch. Die anderen schlagen die Zeit tot, bis aus "Ich hab gleich Zeit für dich" Realität wird. Und dein Senior? Schrubbt noch mehr Überstunden.
Bis der Headhunter schreibt: "Hast du Bock, diesen Stress nicht mehr zu haben?"
Dann hast du nicht nur das gleiche Problem wie vorher. Du hast es ohne deinen besten Entwickler.
Warum diese Abhängigkeit von einzelnen Wissensträgern ein echtes Unternehmensrisiko ist, habe ich in einem eigenen Artikel über Single Points of Failure beschrieben.
Wissenstransfer im Entwicklerteam: Hilft, aber skaliert nicht
Die üblichen Empfehlungen für Wissenstransfer im Entwicklerteam kennst du wahrscheinlich: Pair Programming, Mentoring, Code Reviews mit Lernfokus, bessere Dokumentation.
Das funktioniert. Teilweise. Aber es hat eine Grenze: Am Ende läuft alles über dieselben ein, zwei Wissensträger. Dein Senior erklärt denselben Kontext zum dritten Mal. Schreibt Dokumentation, die nach zwei Sprints veraltet ist. Sitzt in Pair-Programming-Sessions, statt an der Architektur zu arbeiten.
Klassischer Wissenstransfer ist manuell. Und manuell skaliert nicht.
Wie KI den Wissenstransfer im Dev-Team verändert
Wenn ich "KI in der Softwareentwicklung" sage, denken die meisten an Code-Generierung. An Codex oder Claude Code, der autonom Funktionen entwickelt, die unter Umständen keiner versteht. Das ist nicht das, wovon ich spreche.
Ich spreche von KI als Wissens-Multiplikator. Und genau das hebelt Brooks' Law aus.
Warum KI die Skalierungs-Gleichung verändert
Brooks' Law funktioniert, weil jeder neue Kopf den Kommunikationsaufwand für alle erhöht. Der Senior erklärt dieselben Zusammenhänge immer wieder. Das skaliert nicht.
Ein KI-Agent verändert diese Logik. Er ist rund um die Uhr verfügbar und kann mehreren neuen Entwicklern gleichzeitig helfen. Der Senior muss weiterhin reviewen. Aber er reviewt fertige Entwürfe statt bei null anzufangen. Das ist ein Unterschied von Stunden pro Woche.
Wie der Agent Wissen aufbaut
Der Agent startet mit der Codebasis. Er kennt die Struktur, die Patterns, die Abhängigkeiten zwischen Modulen.
Aber das allein reicht nicht. Dein Senior füttert den Agenten mit Wissen, das nirgendwo dokumentiert ist. Warum dieses Modul so gebaut wurde. Welche Sonderanforderung hinter dieser Abhängigkeit steckt. Das muss kein großes Projekt sein. Schon ein fünfminütiges Gespräch über einen bestimmten Code-Bereich macht den Agenten für genau diesen Bereich sofort schlauer.
Je mehr Interaktionen stattfinden, desto breiter wird die Wissensbasis. Und im Gegensatz zu klassischer Dokumentation arbeitet der Agent immer mit dem aktuellen Stand des Codes, nicht mit einem Wiki von letztem Quartal.
Was der Senior davon hat
Der Senior bleibt im Loop. Er reviewt Code, gibt Richtung vor, entscheidet bei Edge Cases. Das ändert sich nicht. Was sich ändert: Neue Entwickler kommen mit einem durchdachten Entwurf zum Review statt mit einem leeren Blatt. Der Senior prüft in zwanzig Minuten statt drei Stunden selbst zu bauen.
Mehr Reviews, ja. Aber Reviews auf einem anderen Level. Keine Grundlagen-Erklärungen mehr, keine Einführungskurse. Und die KI hat dabei keine einzige Zeile Code geschrieben.
Warum das nicht dasselbe ist wie Vibe-Coding
Kurzer Einschub, weil die Frage immer kommt: Tools wie GitHub Copilot generieren Code. Das kann hilfreich sein, bringt aber eigene Probleme mit sich. Erfahrene Entwickler verbringen teilweise mehr Zeit damit, generierten Code zu debuggen, als ihn selbst zu schreiben.
KI als Wissens-Multiplikator produziert keinen Code. Sie macht vorhandenes Wissen zugänglich. Den Kontext, den neue Entwickler brauchen, um eigenständig gute Entscheidungen zu treffen.
Laut Fraunhofer IPA helfen KI-Agenten dabei, "Wissen zugänglich zu machen, aktuell zu halten und teamübergreifend zu nutzen, ohne dass alles manuell gepflegt werden muss."
Wenn bei euch auch alles an ein, zwei Wissensträgern hängt: So lösen wir den Engpass in Dev-Teams.
Wie das in der Praxis aussieht
Bei einem unserer Kunden sollte ein erfahrener Entwickler in ein Team mit einer komplett anderen Technologie wechseln. Neue Programmiersprache, neues Framework, neue Codebasis. Normalerweise: drei bis sechs Monate Einarbeitung.
Wir haben einen KI-Agenten aufgesetzt, der die Codebasis des neuen Teams kannte. Der Entwickler konnte dem Agenten Fragen stellen und sich Konzepte in der Sprache erklären lassen, die er schon beherrschte. Statt den Senior bei jeder Frage aus der Arbeit zu reißen.
Nach zwei Monaten war er produktiv. Eigenständig Features bauen, Konzepte erarbeiten, Code Reviews bestehen. Die Seniors wurden deutlich weniger aus ihrer Arbeit gerissen.
Zwei statt sechs Monate. Kein Riesenprojekt. Ein Agent, der die Codebasis kennt, und ein Entwickler, der Fragen stellt.
Entwickler einarbeiten: 3 Schritte für diese Woche
Du erkennst dein Dev-Team in diesem Artikel? Drei Dinge, die du diese Woche tun kannst:
-
Wissensträger identifizieren. Frag dein Team: "Wer von euch weiß, wie Bereich X funktioniert?" Wenn immer derselbe Name fällt, weißt du, wo der Engpass sitzt.
-
Einarbeitungszeit messen. Wie lange braucht ein neuer Entwickler, bis er eigenständig Features liefert? Wenn die Antwort "Monate" ist, liegt es nicht am Entwickler. Es liegt am fehlenden Wissenstransfer.
-
KI-Agenten testen. Nicht gleich alles umkrempeln. Starte mit einem Bereich, in dem das Wissen bei einer Person liegt. Lass den Agenten die Codebasis scannen und einen Junior damit arbeiten. Beobachte, was passiert.
Fazit
- Mehr Entwickler einzustellen löst selten das Problem. Brooks' Law erklärt, warum: Einarbeitung und Kommunikationsaufwand fressen den Produktivitätsgewinn.
- Der Senior ist der Engpass. Jede neue Person macht seinen Kalender noch voller.
- Klassischer Wissenstransfer (Doku, Pair Programming, Mentoring) hilft, skaliert aber nicht.
- KI-Agenten als Wissens-Multiplikatoren verändern die Gleichung. Sie machen Wissen zugänglich, ohne dass der Senior jede Frage selbst beantworten muss.
Das machen wir heute. Neuer Entwickler in zwei Monaten produktiv statt sechs. Ohne den Senior aus seiner Arbeit zu reißen.
Ihr wollt neue Leute einstellen, ohne dass das Team langsamer wird? Lass uns 15 Minuten darüber reden.
