Das KI-Labor

Eine hochmoderne Engineering-Umgebung, in der Spezifikationen hineingehen und Software herauskommt.

Engineering-Umgebung – Sprosse 5 (Autonome Produktion)

Das KI-Labor ist eine parallele Betriebsumgebung, die auf die höchste Sprosse KI-getriebener Entwicklung abzielt. Es experimentiert mit neuen Arbeitsweisen und dient als Testumgebung für Praktiken, Agenten und Workflows, die dann im gesamten Engineering angewendet werden. Das Labor operiert außerhalb der Standard-Betriebsverfahren des Engineerings. Es hat seine eigenen Regeln.

---

Zwei Reifegrads­skalen

Dieses Dokument verwendet zwei unterschiedliche Skalen, die im Referenzrahmenwerk definiert sind: die Organisationsskala (Level 1–3, unternehmensweit anwendbar) und die Engineering-Skala (Sprosse 0–5, spezifisch für die Softwareentwicklung). Vollständige Definitionen und Abnahmekriterien finden Sie im Rahmenwerk.

Das Labor zielt auf Sprosse 5. Engineering außerhalb des Labors strebt nach organisationalem Level 3 (Sprosse 4–5).

Der schwierigste Übergang ist die Verschiebung von Sprosse 3 zu Sprosse 4: akzeptieren, dass man den Code nicht mehr liest, und darauf vertrauen, dass Szenarien das Ergebnis validieren. Es ist zuerst eine psychologische Veränderung, bevor es eine technische ist. Die meisten Ingenieure stagnieren bei Sprosse 3, weil das Loslassen der Kontrolle über den Code gegen alle professionellen Instinkte verstößt.

---

1. Absolute Regeln

Zwei Regeln definieren das Labor. Sie sind keine Bestrebungen – sie sind Zulassungsbedingungen.

Der Mensch definiert die Architektur, Rahmenbedingungen und Zufriedenheitsszenarien. KI produziert den Code, führt die Tests durch und konvergiert zur Lösung. Wenn Sie Code Zeile für Zeile schreiben oder lesen, arbeiten Sie nicht im Arbeitsmodus des Labors.

---

2. Projektaufnahmekriterien

Typische Reihenfolge für ein Brownfield:

1. Die implizite Spezifikation extrahieren – Das bestehende System IST die Spezifikation. Niemand hat jemals die tausend impliziten Entscheidungen dokumentiert, die sich über Jahre von Patches, Hotfixes und Workarounds angesammelt haben, die dauerhaft wurden. Diese Extraktion ist die schwierigste und menschlichste Arbeit beim Übergang. Sie erfordert die Menschen, die wissen, warum dieses Modul diese Ausnahme hat, warum dieser Dienst so aufgeteilt wurde, warum dieser Wert so konfiguriert ist. KI kann helfen zu dokumentieren, was das System tut (Spezifikationen aus Code generieren). Aber absichtliche Verhaltensweisen von historischen Unfällen zu unterscheiden, bleibt menschliches Urteil.
2. End-to-End-Szenarien schreiben, die das aktuelle erwartete Verhalten beschreiben, basierend auf der in Schritt 1 extrahierten Spezifikation
3. Überprüfen, dass die Szenarien im bestehenden Code bestehen
4. Von diesem Punkt an werden alle Änderungen vom Agenten vorgenommen, validiert durch Szenarien
5. Iterieren: Jede übergeführte Komponente erhöht die Sprosse-5-Abdeckung des Projekts

Was NICHT ins Labor gehört

• Jedes Projekt, dessen Entwicklung mit traditionellen Praktiken fortgeführt wird (Mensch schreibt oder prüft Code)
• Projekte, deren Lieferbedingungen null Lernrisiko tolerieren

Regel: Die Eintrittsbedingung ist nicht die Abwesenheit von bestehendem Code – es ist die Verpflichtung, dass alle neuen Arbeiten den Regeln des Labors folgen.

---

3. Arbeitsmodus: Nicht-interaktive Entwicklung

Der Zyklus

1. Der Mensch schreibt die Spezifikation (Architektur, Rahmenbedingungen, Szenarien)
2. Der Agent produziert den Code
3. Szenarien validieren das Ergebnis
4. Der Mensch bewertet die Zufriedenheit und iteriert bei Bedarf an der Spezifikation

Der Mensch greift nicht in die Ausführung ein. Der Mensch greift in Definition und Bewertung ein.

Szenarien vs. Tests

• Tests: Validierungen, die im Code gespeichert sind. Anfällig für Manipulation durch Agenten – ein Agent kann einen Test umschreiben, damit er besteht. Nützlich, aber unzureichend.
• Szenarien: End-to-End-Nutzerreisen, die das erwartete Verhalten aus der Nutzerperspektive beschreiben. Schwerer zu umgehen. Das Labor bevorzugt Szenarien.

Wenn Menschen den Code nicht mehr lesen, verlieren Unit-Tests einen entscheidenden Vorteil: die Fähigkeit des Ingenieurs, Randfälle aus seinem Wissen über die Implementierung zu identifizieren. In einem undurchsichtigen Ausführungsmodell bleibt nur die End-to-End-Verhaltensvalidierung zuverlässig, weil sie nicht vom Wissen über interne Details abhängt.

Zufriedenheitsmetrik

Das Labor misst Erfolg nicht binär (Tests grün / rot). Es misst Zufriedenheit: „Über alle beobachteten Trajektorien durch alle Szenarien hinweg – welcher Anteil befriedigt den Nutzer?"

Wenn die Zufriedenheit unzureichend ist, liegt das Problem in der Spezifikation, nicht im Agenten. Iterieren Sie an der Spezifikation, nicht am Code.

Die kritische Fähigkeit: Spezifikationen für einen Agenten schreiben

Der Engpass des Labors liegt nicht in der Implementierungsgeschwindigkeit – sondern in der Spezifikationsqualität. Eine Spezifikation zu schreiben, die präzise genug ist, damit ein Agent sie korrekt ohne menschliche Intervention implementiert, ist eine neue Fähigkeit. Fast niemand hat sie entwickelt.

Die Schwierigkeit: Wenn ein Mensch eine mehrdeutige Spezifikation erhält, füllt er die Lücken mit Urteilsvermögen, Kontext oder einer Slack-Nachricht mit der Frage „Meinten Sie X oder Y?" Der Agent baut, was Sie beschrieben haben. Wenn die Beschreibung mehrdeutig ist, füllt die Software die Lücken mit maschinellen Annahmen statt mit Kundenintuition.

Diese Fähigkeit wird durch Praxis entwickelt:

• KI-Kliniken sollten Spezifikationsreviews beinhalten: „Hier ist meine Spezifikation, hier ist was der Agent produziert hat, hier ist, was in der Spezifikation gefehlt hat"
• Pair-Sessions sollten an Spezifikationsübungen arbeiten, nicht nur an Code-Übungen
• Jede fehlgeschlagene Iteration ist ein Signal über die Spezifikation, nicht den Agenten – dokumentieren, was die Spezifikation nicht klar genug formuliert hat

Das Ziel des Labors ist nicht nur, Software durch Agenten zu produzieren. Es ist, Ingenieure zu entwickeln, die mit der Präzision spezifizieren können, die Agenten verlangen.

---

4. Bewusste Naivität

Das größte Hindernis für Sprosse 5 ist nicht technischer Natur – es sind Gewohnheiten.

Erfahrene Ingenieure haben tiefe Reflexe: Code auf eine bestimmte Weise strukturieren, Zeile für Zeile prüfen, Tests selbst schreiben, manuell refaktorieren. Diese Reflexe waren Stärken in der traditionellen Entwicklung. Im Labor sind sie Hindernisse.

Bewusste Naivität bedeutet:

• Traditionelle Entwicklungskonventionen entfernen und sehen, was ohne sie standhält
• Systematisch fragen: „Warum tue ich das? Das Modell sollte es stattdessen tun."
• Akzeptieren, dass Ansätze, die nach traditionellen Maßstäben „naiv" oder „falsch" erscheinen, in einer KI-nativen Umgebung korrekt sein können
• Aufgaben, die historisch als zu teuer galten (vollständige Service-Replikate bauen, Tausende von Szenarien schreiben), als Routine behandeln, wenn KI-Ausführungskosten es ermöglichen

Die permanente Frage des Labors:

“

Warum tue ich das? Das Modell sollte es stattdessen tun.

Wenn die Antwort lautet „weil ich es immer so gemacht habe", ist das genau der Grund, es zu ändern.

---

5. Unterstützungsfunktion

Das Labor ist nicht vom Rest des Engineerings isoliert. Es dient ihm.

Das Labor produziert:

• Dokumentierte Arbeitsmuster: wie man für einen Agenten spezifiziert, wie man Szenarien schreibt, wie man Zufriedenheit bewertet
• Wiederverwendbare oder anpassbare Agenten
• Konkreten Beweis, dass Sprosse 5 bei echten Projekten funktioniert
• Ehrliches Feedback – was funktioniert und was noch nicht funktioniert

Das Labor teilt über:

• KI-Kliniken: regelmäßige Sitzungen, kurzes Format. „Hier ist was wir versucht haben, hier ist was passiert ist."
• Dokumentation: jedes entdeckte Muster und Anti-Muster wird dokumentiert
• Labor/Nicht-Labor-Pairing: Ein Labor-Mitglied arbeitet vorübergehend mit einem Nicht-Labor-Ingenieur zusammen, um Praktiken zu übertragen

Ein Labor, das nicht teilt, ist nutzlos. Teilen ist genauso wichtig wie Produzieren.

---

6. Laborkultur

Das Labor hat eine eigene Kultur, die sich vom Rest der Organisation unterscheidet:

• Obligatorische Neugier – die Frage „Was wäre wenn wir... versuchen würden" ist immer willkommen
• Aggressive Überwachung – Labor-Mitglieder bleiben auf dem neuesten Stand der KI-Modellentwicklungen. Wenn ein neues Modell oder Tool erscheint, testet das Labor es schnell und bewertet, ob es ein Wendepunkt ist. Warten, bis Dinge „reifen", ist mit dem Labor unvereinbar.
• Kühnheit in Methoden, Rigorosität bei Verpflichtungen – das Labor treibt Grenzen voran, wie wir arbeiten: welche Tools wir einführen, welche Workflows wir neu erfinden, welche „naiven" Ansätze wir testen. Aber vertragliche, wirtschaftliche, rechtliche und Sicherheitsverpflichtungen gegenüber Kunden bleiben nicht verhandelbar. Kühnheit gilt für die Mittel, nicht für die Garantien.
• Hohes Risiko, niedrige Einsätze – Labor-Projekte werden so gewählt, dass sie Scheitern tolerieren. Nutzen Sie das, um Risiken einzugehen, die Sie anderswo nicht eingehen würden
• Radikale Transparenz – Misserfolge werden mit genauso viel Detail geteilt wie Erfolge. Ein dokumentierter Misserfolg hat mehr Wert als ein stiller Erfolg
• Führung bedeutet das Team zu heben – Im Labor wird Führung nicht an der Einzelleistung gemessen. Führende sind diejenigen, die den Rest des Teams besser machen: die ihre Entdeckungen teilen, ihre Muster dokumentieren, ihre Kollegen entblocken und ihr Fachwissen in reproduzierbare Praktiken umwandeln. Ein brillanter Ingenieur, der seine Methoden für sich behält, ist keine Laborführungskraft.
• Iterationsgeschwindigkeit – Der Zyklus Spezifikation → Agent → Szenario → Bewertung muss schnell sein. Wenn eine Iteration Tage dauert, ist der Zyklus zu schwerfällig

---

7. Zu vermeidende Fallstricke

• Zu alten Gewohnheiten zurückkehren – der Reflex, „den Code manuell zu prüfen, nur um sicher zu sein", ist genau das, was das Labor verbietet. Wenn die Szenarien bestehen, ist der Code durch die Szenarien validiert.
• Unzureichende Spezifikationen – wenn der Agent schlechten Code produziert, liegt das Problem in der Spezifikation. Iterieren Sie an der Spezifikation, nicht am Code.
• Isolation – ein Labor, das seine Erkenntnisse nicht teilt, ist ein Hobby, kein Labor.
• Zu früh zu kritische Projekte – das Labor hat eine hohe Risikotoleranz. Stecken Sie kein Projekt hinein, dessen Scheitern einen Kunden oder einen Vertrag gefährdet.
• Agenten-Perfektionismus – das Ziel ist kein perfekter Agent. Es ist ein Agent, der Wert produziert. Iterieren.
• Brownfield ohne Spezifikationsextraktion – ein bestehendes Projekt zu übergehen, ohne zuerst die implizite Spezifikation zu extrahieren und Szenarien zu schreiben, die das aktuelle Verhalten schützen, ist Fliegen ohne Netz. Die Extraktion ist die schwierigste Arbeit – unterschätzen Sie sie nicht.
• „Halb-Labor"-Brownfield – wenn ein Teil der Arbeit an einem Brownfield-Projekt im traditionellen Modus erledigt wird, „weil es für diesen Teil schneller ist", ist das Projekt nicht im Labor. Die Regeln sind absolut, auch wenn es unbequem ist.
• Die Sechs-Monats-Mauer – KI-getriebene Projekte ohne starke menschliche Beteiligung (Spezifikationen, Szenarien, Architektur) akkumulieren strukturelle Schulden, die nach etwa sechs Monaten explodieren. KI-generierter Code ohne klare Rahmenbedingungen ist oft weniger strukturiert und weniger wartbar. Die Szenarien und Spezifikationen des Labors sind genau die Abwehr gegen diese Mauer – sie erzwingen vorgelagerte Rigorosität, die verhindert, dass Schulden sich still ansammeln.

---

8. Lebenszyklus

Dieser Lebenszyklus entspricht dem organisationalen Transformationspfad: Phase 1 entspricht dem Level-2→3-Übergang (6–12 Monate auf der Organisationsskala).

---

Zusammenfassende Regel

“

Warum tue ich das? Das Modell sollte es stattdessen tun.

---

← Zurück zur Startseite · Das Referenzrahmenwerk · KI-Ausführungsstandards · Glossar