Die 8 Stufen der Reife im Bereich KI-Engineering: ein Rahmenkonzept für Teams

Vor ein paar Monaten veröffentlichte Steve Yegge seine „8 Stufen der KI-gestützten Entwicklung“, und es machte bei mir sofort „Klick“, als ich das las, denn genau diesen Weg hatte ich selbst durchlaufen – Schritt für Schritt, von der Autovervollständigung bis hin zum Einsatz von Agenten. Als „KI-Vertrauensgradient“ formuliert, gab es der Branche endlich ein Vokabular für etwas, das die meisten von uns bereits durchlebten, ohne einen Namen dafür zu haben. Falls du es noch nicht gelesen hast, heb es dir für später auf.

Yegges Stufen konzentrieren sich auf den einzelnen Entwickler. Und genau das ist der Punkt: Wenn du ein Entwicklerteam leitest, verwaltest du nicht nur einen Vertrauensgradienten, sondern eine ganze Verteilung davon. Da sitzt jemand, der den ganzen Tag parallele Agenten laufen lässt, neben jemandem, der KI immer noch für eine ausgefeiltere Autovervollständigung hält – und beide programmieren. Deshalb zeigt sich der 10-fache Produktivitätsschub, von dem alle reden, auf Organisationsebene so gut wie nie. Das Schwierige ist, die gesamte Organisation dazu zu bringen, sich gemeinsam vorwärts zu bewegen, ohne dass die Schnellstarter Chaos verursachen und die Nachzügler still und leise ins Hintertreffen geraten.

Also haben wir dieselben Prinzipien genommen und sie aus einem anderen Blickwinkel betrachtet: nicht den einzelnen Entwickler, den Yegge beschreibt, sondern das Team und die Organisation, in der das Team arbeitet. Acht Reifegrade, von „Niemand hat etwas entschieden“ bis hin zu „Die Fabrik läuft von selbst“.

Ein kurzes Wort zum Vokabular, da wir uns durchgehend darauf stützen. Wenn wir „Team“ sagen, meinen wir eine Gruppe von Menschen, die gemeinsam auf dasselbe Ergebnis hinarbeiten: Entwickler, ja, aber auch Produkt, Design, QA – wer auch immer nötig ist, um Software auf den Markt zu bringen. Wenn wir „Organisation“ sagen, meinen wir die Gesamtheit dieser Teams sowie die Führung, die Budgets und die Governance, die darüber stehen.

Und hier kommt der Teil, der dies zu einer SDLC-Geschichte macht und nicht nur zu einer Entwicklergeschichte: Beim neuen Softwareentwicklungszyklus geht es nicht nur um Entwickler. Es geht um das gesamte Team. Die alten Grenzen zwischen Produkt, Design und Entwicklung verschwimmen zunehmend. Ein Produktmanager kann jetzt im Handumdrehen einen funktionierenden Prototyp programmieren, anstatt eine dreiseitige Spezifikation zu schreiben, die niemand liest. Ein Designer kann echtes HTML und CSS ausliefern, nicht nur ein Designsystem und eine Figma-Datei zur Weitergabe. Genau dieser Wandel ist der springende Punkt, und deshalb reicht es nicht mehr aus, nur in Kategorien einzelner Entwickler zu denken.

Lass uns erst mal die ganze Karte auflegen, bevor wir sie durchgehen.

Phase 1: Das Vakuum

Die Unternehmensleitung hat noch keine klare Position bezogen; höchstens hat sie ein paar Lizenzen gekauft und es dabei belassen. Entwickler entwickeln Gewohnheiten ohne Leitplanken: Sie programmieren in irgendeinem offenen Chatfenster, es gibt keine gemeinsamen Kontextdateien, keine Agent-Einrichtung und keine verwalteten API-Schlüssel. Das ist eine Lernphase, und ich finde das in Ordnung: Die Leute entwickeln ein Gespür dafür, was diese Modelle können und was nicht. Dieses Gespür ist im Moment der eigentliche Gewinn. Verwechsle Schweigen nicht mit Untätigkeit. Deine Entwickler haben sich bereits selbst entschieden.

Phase 2: Die Abdrift

In Phase 1 ging es darum, was die Organisation noch nicht entschieden hatte; in Phase 2 geht es darum, was Einzelne selbst entschieden haben. Ein Entwickler lässt still und leise Agenten einen großen Teil seiner Arbeit erledigen, wobei er auf einen persönlichen Vorrat an Prompts, benutzerdefinierten Skills und eine sorgfältig abgestimmte AGENTS.md zurückgreift, die er auf seinem eigenen Rechner speichert. Die Person neben ihm hat seit zwei Jahren nichts geändert, und niemand macht darauf aufmerksam, weil individuelle Abweichungen schon immer als normal galten. Dies ist die letzte Phase, in der Untätigkeit noch keine Folgen hat. Sobald die Abweichung sichtbar wird – und das wird sie –, wird sie zu einem Problem auf Teamebene.

Phase 3: Die Inseln

Die Kluft, die früher zwischen Einzelpersonen bestand, verläuft nun zwischen ganzen Teams und zeigt sich im Lieferplan, wo sie für alle sichtbar ist. Ein Team hat AGENTS.md-Dateien geteilt, MCP-Server vernetzt und wiederverwendbare Skills entwickelt. Sein Durchsatz steigt sprunghaft an. Das Team nebenan programmiert immer noch wie vor zwei Jahren. Was als Tooling-Lücke beginnt, verhärtet sich zu Unmut, und das ist viel schwerer zu beheben.

Phase 4: Die Wette auf Standardisierung

Die erste Phase, die echtes Engagement der Führungsebene erfordert, ist, dass KI zu einer Fähigkeit wird, die man bewusst aufbaut. Hier sind drei Dinge entscheidend: Kontext-Engineering wird zu einer expliziten Aufgabe, mit gemeinsam genutzten AGENTS.md-Dateien und einer kuratierten Bibliothek aus Skills und Prompts in den Repos, sodass das Team sein Wissen einmalig kodiert, anstatt dass jeder Entwickler der KI dieselben Lektionen beibringt. Sicherheit und Governance haben Vorrang vor Skalierung: SSO und SCIM, Secret Scanning, PR-Gates, die auf der Ausgabe von Agenten basieren, Audit-Protokolle und eine genehmigte Liste von Modellen und Tools hinter einem Gateway – all das muss eingerichtet sein, bevor die Leute auf Hochtouren loslegen. Und die Schulung ist ein fortlaufender Prozess, kein einmaliger Workshop, der in der Regel um die Vorreiter aus Phase 2 herum aufgebaut wird.

Phase 5: Die Neugestaltung des Workflows

In Phase 4 werden die Tools aktualisiert; in Phase 5 wird die Arbeitsumgebung neu gestaltet, wodurch sich die Art und Weise ändert, wie die Arbeit tatsächlich erledigt wird. „Spec-first“ wird zum Standard: Die Spezifikation befindet sich im Repo als Einstiegspunkt für den Agenten, und ein Agent kann anhand eines vagen Tickets genauso wenig arbeiten wie ein Junior-Entwickler. Die Code-Review verlagert sich von Zeile-für-Zeile-Prüfung hin zu risikobasierten Fragen: Stimmt das mit der Spezifikation überein? Beweisen die Tests das? Wie groß ist der Schaden, wenn es falsch ist? CI-Gates behandeln von Agenten eröffnete PRs genau wie die von Menschen, und die Evaluierungen laufen direkt neben den Unit-Tests ab. Rechne mit einem Produktivitätsrückgang, während sich die Rolle vom Programmieren hin zum Überprüfen und Koordinieren verlagert; das ist normal. Achte auf Qualität, nicht nur auf Geschwindigkeit: Mehr Code mit geringerer Qualität ist keine Geschwindigkeit, sondern bedeutet, dass Probleme früher auftreten.

Phase 6: Das Betriebssystem

Phase 5 hat die Arbeitsweise eines Teams verändert; Phase 6 verändert, woraus ein Team besteht und wie sich Teams koordinieren. Ein Sprint umfasst vielleicht drei Entwickler und fünf Agentenplätze, und der Entwickler ähnelt nun eher einem Produktmanager als einem Programmierer: Er schreibt Spezifikationen, diskutiert mit der KI darüber und überprüft die Tests. TDD wird zur Notwendigkeit, nicht mehr nur zu einem „Nice-to-have“: Agenten optimieren darauf, Tests zu bestehen, sodass eine schwache Testsuite ausgenutzt wird – und du merkst es erst, wenn es in der Produktivumgebung passiert. Parallele Agenten, die in isolierten Sandboxes laufen, können in einem einzigen Sprint mehr Rechenleistung verbrauchen als ein Viertel der Hosting-Kosten, sodass Token-Budgets und Observability pro Lauf nicht mehr optional sind. Und der gemeinsame Kontext wird zur echten Infrastruktur (Projektgedächtnis, Fähigkeiten, Prompt-Bibliotheken, MCP-Server), die als Team-Assets gepflegt und teamübergreifend koordiniert wird.

Phase 7: Die intelligente Fabrik

Die Weiterentwicklung aus Stufe 6 ist die Frage, wer den Stift in der Hand hält. Die Agenten schreiben und liefern nun ganze Arbeitseinheiten, fast ohne menschliches Zutun, und der Mensch wechselt von der Rolle des Lenkers in die des Aufsehers. Die meisten Teams sind immer noch mit „Babysitting“ beschäftigt: Agenten werden von einem Terminal auf dem Laptop eines Mitarbeiters gestartet, laufen lokal in einer Schleife und öffnen PRs von einem Entwicklungsrechner aus – ohne gemeinsame Laufzeitumgebung und ohne zentrale Aufzeichnung darüber, was gelaufen ist und warum. Genau dieses Detail der lokalen Maschine ist das Einzige, was diese Phase von der nächsten unterscheidet.

Stufe 8: Die autonome Fabrik

Agenten wandern von Laptops auf eine gemeinsam genutzte Infrastruktur um, mit geplanten Ausführungen in Sandbox-Umgebungen sowie zentralisierten Protokollen und Traces – so läuft eine Migration, die früher ständige Überwachung erforderte, über Nacht und meldet ihre Ergebnisse am Morgen. Wiederkehrende Aufgaben werden zu vollwertigen Prozessen (Aktualisierung von Abhängigkeiten, Sicherheitspatches, Testausweitung) mit definierten Erfolgskriterien und automatischer Eskalation, wenn etwas fehlschlägt. Die Bewertung wird zum Produkt: Das Wissen, das früher in den Köpfen der Menschen steckte, befindet sich nun in den Konfigurationen der Agenten, ihren Fähigkeiten und den Testsuiten, die jeden Merge prüfen – einmal kodiert und automatisch durchgesetzt. Deine Standards stecken nicht mehr in irgendjemandes Kopf. Sie stecken im System

Ein paar ehrliche Vorbehalte

Keine Organisation befindet sich eindeutig auf einer einzigen Stufe. Ihr werdet einige Teams auf Stufe 6 entdecken und andere, die noch fest auf Stufe 1 stehen. Die Zahl ist ein Schwerpunkt, kein Etikett, das ihr jedem anheftet.

Außerdem solltest du keine Stufen überspringen. Wenn du direkt auf autonome Agenten setzt, ohne dass die zugrunde liegende Governance, die Tests und der gemeinsame Kontext vorhanden sind, wirst du einfach nur zu einem weiteren gescheiterten Projekt. Aber es gibt noch einen subtileren Grund, eine Stufe nach der anderen zu durchlaufen: Jede Stufe bringt ihre ganz eigenen Schwierigkeiten mit sich, und genau diese Schwierigkeiten sind die Lektion. Die Reibung zwischen einem schnellen und einem langsamen Team ist es, die ein Unternehmen zur Standardisierung treibt. Die mühsame Arbeit, die Ergebnisse der Agenten Zeile für Zeile zu überprüfen, ist es, die ein Team davon überzeugt, den Arbeitsablauf neu zu gestalten. Überspringst du den Schmerz, verlierst du den Grund, weiterzumachen: Nichts spricht so sehr für die nächste Stufe wie die Tatsache, dass die aktuelle langsam wehtut.

Und bleib den ganzen Weg über skeptisch. Der Hype drumherum ist laut; die Beweise dafür sind viel leiser. Behandle also jedes Versprechen hier, einschließlich unserer, mit Vorsicht.

Fazit

Die Frage ist nicht, ob man KI einführen soll. Die meisten Teams haben das bereits getan. Die eigentliche Frage ist, ob das zugrunde liegende System gut genug ist, um es weiter auszubauen.

Denn genau das ist KI: ein Verstärker. Davon bin ich überzeugt. Sie beschleunigt das, was bereits vorhanden ist – die guten wie die schlechten Praktiken gleichermaßen. Die Organisationen, bei denen wir beobachtet haben, dass sie an Tempo gewinnen, ohne an Qualität einzubüßen, haben alle dieselbe Grundlage: klare Zuständigkeiten für Services, umfassende Tests, dokumentierte Services und automatisierte Standards. Nichts davon ist neu. Wir predigen diese Best Practices schon seit Jahren. KI hat es nur unmöglich gemacht, ihr Fehlen zu ignorieren.

Die autonome Fabrik ist das Ziel, auf das das alles hinausläuft. Der schwierigste Teil werden nicht die Agenten selbst sein: Es wird darum gehen, ihnen genug zu vertrauen, um sie von den einzelnen Laptops zu nehmen und auf einer gemeinsamen Infrastruktur laufen zu lassen. Man baut das genauso auf, wie man es schon immer getan hat – mit Belegen. Eine Bewertung, eine wiederkehrende Aufgabe, eine verifizierte Bereitstellung nach der anderen.