In Gesprächen mit Engineering Leads, die selbst keine Programmierer sind, kommen Fragen wie diese ab und an:
Wenn wir Claude Code, Cursor oder Copilot für alle ausrollen, holen wir dann unsere schwächeren Teams nach oben?
Die Frage ist nachvollziehbar. In fast jeder Organisation gibt es ein paar sehr starke Entwickler, ein paar Teams mit guter Routine — und andere, die in alten Workflows feststecken. Die Mechanismen sieht man als Entwickler von Innen recht schnell. Von außen sieht es einfach so aus, als wären manche Teams langsamer als andere. KI zum Anheben der Baseline zu nutzen klingt dann plausibel, weil jeder ein besseres Werkzeug bekommt, also das Niveau für alle steigt.
Dieses Bild passt auch gut in die Vertriebsgeschichte der großen Anbieter. KI wird dort beworben wie der Netto-Fähigkeitsgewinn von Gabelstaplern in Lagern: Eine Tonne hebt ein Mensch nicht allein, das ist unmöglich, aber mit Gabelstapler schon. KI ist dann der Gabelstapler für die Codebase, womit man unfassbar neues, besser, schneller erreichen kann.
Nur funktioniert Software-Entwicklung nicht wie Palettenheben.
DORAs State of AI-Assisted Software Development 2025 beschreibt KI nicht als Gleichmacher, sondern als Verstärker. Starke Teams werden stärker. Schwache Teams werden aber nicht automatisch stark. KI verschiebt nicht alles auf der Qualitätsachse stumpf nach oben. KI-gestützte Entwicklung produziert vornehmlich schneller, aber damit auch schneller mehr von dem, was vorher schon problematisch war.
Da offenbart sich in der Umsetzung der Unterschied zwischen einer Tool-Lizenz und einer Investitionsstrategie.
Die populäre Erzählung
Die einfache Geschichte geht so: KI-Coding-Tools geben jedem Entwickler mehr Fähigkeit. Seniors profitieren, aber Juniors und schwächere Teams profitieren stärker, weil sie plötzlich Zugriff auf Wissen haben, das ihnen vorher fehlte. Produktivitätslücken schließen sich. Der Abstand schrumpft.
Anbieter haben gute Gründe, diese Geschichte zu erzählen. Das Narrativ vom angehobenen Boden der Produktivität erschließt mehr Käufer: Wer das schwächere Team nach oben holen will, hat Lizenzbedarf für die gesamte Firma, nicht nur für die Top-Performer. Das ist kein böswilliges Marketing, aber es ist strukturell verzerrt: Tools, die an den Stärken hebeln, werden als Tools verkauft, die Schwächen kompensieren.
Deshalb tauchen in Sales-Gesprächen Varianten dieser drei Sätze auf:
- „Jeder kann jetzt produktiver werden.“
- „KI demokratisiert Software-Entwicklung.“
- „Wir holen die schwächeren Teams nach oben.“
Ein Teil davon stimmt auch: Viele Entwickler werden mit KI produktiver. Aber daraus folgt nicht, dass sich Teamunterschiede einebnen.
DORAs Daten zeigen eher das Gegenteil.
DORA befragt seit Jahren Engineering-Praktiker zu Arbeitsweisen, Delivery-Kennzahlen und Teamverhalten. Der 2025er-Bericht formuliert den KI-Befund ungewöhnlich klar. Auf Seite 42 steht:
„AI‘s primary role in software development is that of an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones.“
KI ist ein Verstärker. Was gut funktioniert, wird stärker. Was dysfunktional ist, wird sichtbarer und schneller.
Das ist nicht die Randnotiz eines kritischen Beobachters. Es ist ein zentrales Finding in einem Bericht, der im Markt genau dann zitiert wird, wenn jemand ROI-Zahlen für KI-Investitionen braucht.
Bemerkenswert ist auch die Formulierung von Eirini Kalliamvakou, Principal Researcher bei GitHub, im selben Bericht auf SEite 374:
„AI functions both as a mirror and a multiplier. It shines a light on what‘s working, accelerating what‘s already in motion, but it also surfaces what needs to change.“
KI ist Spiegel und Multiplikator zugleich. KI zeigt, was schon funktioniert. Aber vor allem: sie zeigt auch, was nicht funktioniert.
Wenn der Tool-Vendor selbst sagt, sein Produkt zeige im Betrieb auf, was im Argen liegt, dann ist „flächendeckend ausrollen und abwarten“ keine Strategie, sondern Risikoexposition.
Teams mit klaren Patterns, sauberer Architektur und disziplinierter Arbeitsweise werden stärker gehebelt, weil der Agent etwas zum Einhaken findet.
Warum KI verstärkt
Der Befund ist nur nützlich, wenn man den Mechanismus versteht. Sonst bleibt „Amplifier“ ein Schlagwort.
Klare Patterns sind Anker für den Agenten. Eine Codebase mit konsistenten Namenskonventionen, kleinen PRs, nachvollziehbaren Tests und klaren Architekturgrenzen gibt dem Modell Orientierung. Der Agent erkennt das Muster und arbeitet darin weiter. In einer chaotischen Codebase ist jede Datei eine Ausnahme. Jede Abstraktion ist Sonderfall. Dann rät der Agent mehr, als er erschließt, und der Entwickler muss mehr prüfen, nicht weniger.
Was früher wie „Developer-Candy“ klang – ADRs, saubere Commit-Messages, kleine Diffs, klare Modulgrenzen; oder: klar formulierte Tickets! – wird im KI-Zeitalter zum Hebel, weil KI ohne sie schlechter wird.
Disziplin reduziert die verification tax. KI erzeugt Code, und zwar schnell. Die entscheidende Frage bleibt: stimmt der Code? Bei einem 50-Zeilen-Diff mit klarer Absicht ist diese Prüfung machbar, die verification tax bezahlbar. Bei einem 600-Zeilen-PR aus dem Agenten ist sie teuer, oder sie findet gar nicht erst statt.
Dann wird unverstandener Code gemergt, Bugs kommen später, und das Team lernt: „KI macht uns unzuverlässig.“ Das Problem war aber nicht nur das Tool. Das Problem war ein Review-System, das durch schnelleren Output überfordert wurde.
Schau dir meine Checkliste zu KI-Generiertem Code an und wie man ihn reviewbar hält.
Specs sind die Kontrollfläche. Ein Agent kann nur gut auf ein Ziel hin arbeiten, wenn das Ziel beschrieben ist. Teams, die Anforderungen vor dem Code klären, geben dem Agenten eine Prüffläche. Das geht als Ticket, ADR, Acceptance Criteria, oder knappe technische Notiz. Teams, die erst beim Implementieren herausfinden, was sie eigentlich meinen, bekommen plausibel aussehenden Output, der am Ziel vorbeigeht.
Das ist genau der Verstärker-Effekt: KI skaliert die Unklarheit, die vorher schon im System war. Betroffene Teams müssen umlernen, sich mehr Mühe in der Vorbereitung zu geben, und beispielsweise weniger auf das latente Wissen der Programmierer zu vertrauen. Was nicht geschrieben steht, existiert nicht.
DORA beschreibt die Lernphase als Tuition Cost of Transformation: Wer KI ernsthaft einführt, zahlt zuerst Lehrgeld.
- Starke Teams kommen schneller durch diesen Dip, weil ihre bestehenden Praktiken dem Agenten Halt geben.
- Schwächere Teams bleiben länger im Tal, weil KI genau die Probleme beschleunigt, die Adoption bremsen.
Der Dip ist für beide erfahrbar, aber der Unterschied ist, ob er begrenzt bleibt.
Was Entscheider daraus tun
Wenn KI ein Verstärker ist, ändern sich die Fragen vor dem Einkauf.
Wo sind wir heute stark in der Entwicklung? Nicht: „Wir machen agile“ oder „wir haben CI/CD“. Sondern konkret: In welchem Team gibt es kleine PRs, gute Reviews, klare Specs, brauchbare Tests, nachvollziehbare Entscheidungen? Dort liegt der erste Hebel. Die Versuchung ist groß, KI zuerst beim schwächsten Team einzusetzen. DORAs Daten sprechen für die Gegenrichtung: zuerst dort investieren, wo schon etwas existiert, das KI verstärken kann.
Welche Schwäche würde KI bei uns verstärken? Große PRs, unklare Tickets, inkonsistente Reviews, fehlende Tests, keine Entscheidungsdokumentation — all das sind keine neutralen Startbedingungen. Sie werden mit KI nicht automatisch besser, sondern schneller sichtbar. Eine sinnvolle Einführung adressiert deshalb eine dieser Schwächen, ändert eine konkrete Praxis, die dem Agenten bessere Orientierung gibt, und dann erst die nächste, wenn sich die Änderung einstellt. Nicht alle auf einmal, das ist nicht stemmbar.
Wer ist der Flaschenhalt im Alltagsgeschäft? Das heißt nicht „wer ist gegen KI?“ Denn Skepsis ist oft vernünftig! Die bessere Frage ist: Wer entscheidet im Alltag, was in einen PR darf? Wer schreibt oder akzeptiert Specs? Wer setzt Tooling-Policy? Wer definiert Review-Standards? Adoption scheitert selten an einer einzelnen lauten Gegenstimme. Sie scheitert häufiger an einer mittleren Entscheidungsebene, die die Teamroutine prägt, aber nicht explizit mitgedacht wird. Wenn das Team in der Praxis wirklich flach aufgebaut ist, ist die ehrliche Antwort vielleicht: „ein bisschen sind wir alle der Flaschenhals.“
Nicht zu empfehlen ist die „spray and pray“ Taktik: Lizenzen verteilen und auf Bottom-up-Adoption warten. Das ist keine Strategie.
Was du mit KI bekommst, hängt davon ab, was du schon hast
DORA findet positive Zusammenhänge zwischen KI-Nutzung und individueller Effektivität, Codequalität, Delivery-Durchsatz und Team-Performance. Gleichzeitig reduziert KI nicht automatisch Reibungsverluste oder Burnout. Und sie ist mit mehr Delivery-Instabilität verbunden. KI repariert nicht die organisatorische Verdrahtung hinter der Tastatur.
Friction, Burnout und Instabilität sind Systemeigenschaften. Sie brauchen Systeminterventionen: kleinere Batches, klarere Specs, bessere Review-Loops, brauchbare Tests, explizite Guardrails. KI beschleunigt bloß das Schreiben von Code. Sie beschleunigt nicht automatisch das Schreiben von gutem Code in einem schlecht aufgestellten System.
KI macht das Spielfeld nicht eben. Sie macht starke Teams stärker — und schwache Teams schneller chaotischer.
CTO Strategy Briefing
Die drei Fragen oben — wo seid ihr stark, welche Schwäche verstärkt KI, wer ist das operative Bottleneck — sind der Einstieg ins CTO Strategy Briefing.
In 60–90 Minuten klären wir euren Engineering-Kontext: aktuelle Toolnutzung, Teamroutinen, Risiken, Datenlage und realistische nächste Schritte. Danach bekommst du ein zweiseitiges Memo als Entscheidungsgrundlage für Führungskreis oder Geschäftsleitung. Es gibt keine Folgeverpflichtung. Wenn Warten der richtige nächste Schritt ist, steht das im Memo.
Briefing buchen — Strategie klären, bevor ihr Lizenzen skaliert.