Die Delivery Levels beschreiben, wie ein Team wirklich mit KI arbeitet – nicht, welche Tools es eingekauft hat. Ein Punkt trennt jedes Level vom nächsten: wie viel Arbeit die KI von allein anfängt und wie viel Sie weiterhin für sie anfangen müssen. Unten finden Sie jedes Level in einfachen Worten, wie es sich in jeder Phase Ihrer Lieferung zeigt, und wie wir entscheiden, wo ein Team steht.
Ein Punkt trennt jedes Level vom nächsten. Nicht die Anzahl der Lizenzen, nicht die Höhe des Tool-Budgets. Nur das: wer die Arbeit anfängt.
| Level | Was die KI tut | Was die Menschen tun | In einem Wort |
|---|---|---|---|
| DL1 | Nichts | Alles | Manuell |
| DL2 | Reagiert auf Tastenanschläge | Treiben alles, KI hilft pro Aufgabe | Reaktiv |
| DL3 | Versteht den Projektkontext, trägt proaktiv bei | Treiben jede Phase, KI trägt darin bei | Kontextuell |
| DL4 | Übernimmt die Initiative über den gesamten SDLC ab einem Business-Input | Prüfen und genehmigen den proaktiven Output der KI | Kollaborativ |
| DL5 | Arbeitet autonom auf Organisationsebene | Bearbeiten Ausnahmen und genehmigen an Gates | Autonom |
Aller Code ist von Menschen geschrieben. Alle Tests sind von Menschen entworfen. Alle Dokumentation ist von Menschen verfasst. Alle Reviews werden von Menschen durchgeführt. Der klassische SDLC läuft genau so, wie er seit Jahrzehnten läuft.
1,0× Basislinie. Liefergeschwindigkeit skaliert nur mit Kopfzahl.
Entwickler nutzen KI-Tools (ChatGPT, Copilot, Cursor, Claude) nach eigenem Gutdünken. Die KI liefert Autovervollständigung, Code-Snippets, Q&A im Chat und einfache Vorschläge. Jede Aufgabe wird unabhängig behandelt. Die KI versteht Ihr Projekt nicht als Ganzes. Sie reagiert auf das, was Sie tippen – Datei für Datei, Prompt für Prompt.
Der Entwickler passt den Prompt an („korrigiere das, nutze dieses Framework, nicht diese Klasse“), statt eine Feedback-Schleife aufzubauen, die das Team teilen kann.
Ein Entwickler bittet die KI: „schreibe eine Funktion zur E-Mail-Validierung“. Die KI liefert eine generische Funktion mit einer Bibliothek, die das Projekt nicht nutzt, und Namenskonventionen, die nicht zum Projektstil passen. Der Entwickler korrigiert es manuell.
Produktivität: ~1,25× (individueller, unstrukturierter Gewinn).
Die KI kennt Ihre Architektur, Projektstandards, Service-Verbindungen und Testansätze im Detail. Sie reagiert nicht nur auf Prompts, sie trägt proaktiv bei. Betrifft ein Feature drei Services, erkennt sie die Verbindungen, erzeugt Unit- und Integrationstests für die Übergänge, meldet Konflikte vor dem Code-Review und formuliert Anforderungs-Zusammenfassungen aus Stakeholder-Input.
Das Team hat eine gemeinsame KI-Methodik: Rules-Dateien, Architekturdokumentation als KI-Kontext, strukturierte Reviews und einen dokumentierten Standard für den Einsatz von KI im Projekt.
„Implementiere den Passwort-Reset-Flow.“ Die KI weiß, dass das Projekt Express mit einem bestimmten Auth-Middleware-Muster, Prisma und Resend nutzt, und liefert die vollständige Implementierung passend zu allen Konventionen beim ersten Versuch. Das Review findet sie zu 90% korrekt; ein Folge-Prompt löst den Randfall.
Produktivität: ~2–5× (teamweit, strukturiert).
Aus einer Business-Anforderung oder einem Produktgespräch erzeugt die KI proaktiv alles: User Stories, funktionale Blöcke, Architekturvorschläge, Implementierung, Testsuiten mit Coverage-Optimierung, Deployment-Konfigurationen und Dokumentation. Der Engineer muss die KI nicht Phase für Phase steuern.
Das primäre Ergebnis des Engineers verschiebt sich von Code zu Urteilsvermögen. Er prüft die Vorschläge der KI und entscheidet: genehmigen, anpassen oder überstimmen. Die Spezifikation entsteht als KI-Entwurf; der Mensch validiert und ergänzt sie, statt sie von Null zu schreiben.
Ein PM beschreibt ein Feature im Gespräch: „Nutzer müssen ihr Passwort zurücksetzen können.“ Die KI erzeugt eine strukturierte Spezifikation mit allen Flows, Randfällen, Sicherheitsanforderungen und Rate Limiting; einen Architekturvorschlag mit den betroffenen Services; die vollständige Implementierung; eine Testsuite mit 15 Tests für Happy Path, Fehlerfälle und Sicherheit; API-Doku-Updates; und ein Migrationsskript. Der Engineer prüft die Spec („Session-Invalidierung beim Reset ergänzen“) und genehmigt den Rest. Ship.
Produktivität: ~10× (Team-Output).
Mehrere KI-Agenten orchestrieren den gesamten SDLC. Ein Agent schärft Anforderungen, einer entwirft Architektur, einer implementiert, einer testet, einer reviewt. Der Ablauf läuft von selbst. Menschen sitzen an den Gates zwischen den großen Phasen: sie genehmigen Übergänge, fangen auf, was die Agenten übersehen haben, und treffen strategische Entscheidungen.
Der Unterschied zu DL4 ist nicht die Technologie, sondern Umfang und Autonomie. Bei DL4 ist die KI ein proaktiver Mitarbeiter in einzelnen Projekten mit menschlicher Aufsicht pro Phase. Bei DL5 arbeitet die KI über die ganze Organisation, Routineaufgaben laufen autonom, und Menschen konzentrieren sich auf Ausnahmen und strategische Entscheidungen.
Ein PM erstellt ein Ticket: „Passwort-Reset ergänzen.“ Der Anforderungs-Agent erzeugt die Spec: alle Flows, Randfälle, Rate Limiting, Session-Handling. Gate 1: der Engineer prüft in 2 Minuten und ergänzt „CAPTCHA nach 3 Fehlversuchen“. Der Architektur-Agent plant die Änderungen. Der Implementierungs-Agent schreibt den Code. Der Test-Agent lässt 18 Tests laufen, einer fällt durch. Der Implementierungs-Agent behebt es, alle laufen grün. Der Review-Agent prüft die Implementierung gegen die Spec. Gate 2: der Engineer prüft den finalen PR. Genehmigt. Ship.
Produktivität: ~10–100×, je nach Ausführungsqualität.
Fast kein Team steht überall auf demselben Level. Beim Programmieren können Sie DL3 sein und beim Testen DL1. Deshalb schauen wir uns jede Phase einzeln an. Wählen Sie eine und sehen Sie, wie sie sich von Level zu Level verändert.
In 30 Minuten gehen wir Ihre sechs Phasen gemeinsam durch, ordnen Ihr Team auf der Skala ein, benennen die eine Sache, die den Rest blockiert, und zeigen Ihnen, was das nächste Level wert ist. Sie bekommen es innerhalb einer Woche schriftlich.