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.

---

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.

---

Projektaufnahmekriterien

Typische Reihenfolge für ein Brownfield:

Diese Schritte setzen eine Codebasis voraus, die direkt zu Sprosse 5 unter den Laborregeln überführt wird. Die vorgelagerten Entscheidungen – Codereife bewerten und unter den vier Brownfield-Modi wählen (Sanieren, Strangler-Fig, Neuaufbau) – liegen außerhalb des Labors selbst.

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.

---

Arbeitsmodus: Die operative Einheit

Die fünf Phasen

Das Labor strukturiert alle Arbeit um eine wiederkehrende fünfphasige Schleife. Der Mensch konzentriert sich an den Grenzen; der Agent läuft im Inneren.

1. Stage 1
   Kontext

   Lebendiger Arbeitskontext (CLAUDE.md / AGENTS.md, gescoptes Tooling, On-Demand-Skills), gegen das System validiert, bevor die Arbeit beginnt. Veralteter Kontext produziert selbstbewusst falsche Arbeit.

2. Stage 2
   Klärung

   Der Agent legt Annahmen offen und stellt kalibrierte Fragen. Keine Ausführung, solange materielle Mehrdeutigkeit besteht. Kostenregel: Klärungskosten ≪ Korrekturkosten.

3. Stage 3
   Ausführung

   Agent produziert, führt Tests aus, konvergiert. Der Mensch überwacht die Ausführung nicht.

4. Stage 4
   Validierung

   Risikoabgestuftes Gate (§ 4). Tests, Szenarien, Agent als Prüfer für reversible Arbeit; menschliche Genehmigung für irreversible.

5. Stage 5
   Wiederherstellung

   Wenn Validierung scheitert oder der Agent feststeckt: Rekalibrieren (neu spezifizieren, neu kontextualisieren, Brainstorming) statt debuggen. Siehe § 5.

Phase 2 (Klärung) wird in Produktions-Tooling ausgeliefert – spec-kits /speckit.clarify, Anthropics Plan-Modus und das AskUserQuestion-Tool operationalisieren sie alle als diskretes Gate. Phase 4 wird in Risikoabgestufte Validierungs-Gates detailliert; Phase 5 im Stuck-State-Protokoll.

Zwei menschliche Checkpoints

Menschliche Arbeit konzentriert sich an der vorderen Grenze (Kontext + Klärung) und der hinteren Grenze (Validierung + Wiederherstellung). Innerhalb der Schleife laufen Agenten und Evaluatoren. Das ist das operative Muster, das Sprosse 5 nachhaltig macht – die Aufmerksamkeit des Menschen ist kein Engpass für Zeile-für-Zeile-Prüfung; sie ist eine Rolle für Richtung-und-Urteil pro Schleife.

Das Muster ist diskrete Aufgabe, nicht Engineering-spezifisch

Das Labor wendet die Schleife auf Code an, aber dieselbe Form bestimmt andere diskrete Aufgabenarbeit:

Phase	Engineering	Kundendienst	Finanzoperationen
Kontext	Codebasis + CLAUDE.md	Wissensdatenbank + Kundenhistorie	Ledger + Kontenplan + Periodenregeln
Klärung	Agent fragt nach mehrdeutigen Abnahmekriterien	Agent fragt „Was will der Kunde wirklich?" vor dem Entwurf	Agent legt Mehrdeutigkeit in der Transaktionskategorisierung offen
Ausführung	PR mit Tests	Antwort + Aktionen	Entworfene Buchungssätze
Validierung	Agent-Prüfer + CI; menschliches Gate bei Produktionsdeploy	Agent-Prüfer für Ton + Richtlinie; menschliches Gate bei Erstattung über Schwellenwert	Agent-Abgleicher; menschliche Genehmigung vor Buchung
Wiederherstellung	Neu spezifizieren, wenn subtiler Bug auftaucht	Neu trainieren, wenn sich Eskalationsmuster verschieben	Neu spezifizieren, wenn ein Randfall eine Kategorielücke offenlegt

Das Substrat ändert sich; die Schleife nicht. Die Regeln des Labors – Code nicht von Menschen geschrieben oder geprüft – sind die Engineering-Instanz des breiteren Prinzips: Menschen steuern und validieren; KI führt innerhalb risikoabgestufter Gates aus.

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.

Token-Ökonomie

Wall-Clock-Zeit ist die falsche Messgröße auf Sprosse 5 – Agenten arbeiten parallel, asynchron und über Nacht. Die bindenden Metriken sind:

• Kosten pro gemergter Einheit (PR, Ticket, Transaktion). Anthropic quantifiziert den Multi-Agenten-Aufpreis: Typische Agenten verbrauchen ~4-fach die Tokens von Chat; Multi-Agenten-Systeme können ~15-fach verbrauchen (Anthropic, 2025). Kosten pro gemergter Einheit machen das sichtbar.
• KI-Bruttomarge auf Team-Ebene – erzeugter Wert relativ zu ausgegebener Inferenz. KI-native Teams behandeln Token-Kosten als erstklassige Engineering-Metrik. Siehe KI-Ökonomie bei Reife.
• Agentendurchsatz pro Dollar – gemergte Einheiten pro Dollar Inferenz. Unterscheidet Teams mit hohen Ausgaben und hohem Durchsatz von solchen mit hohen Ausgaben und niedrigem Durchsatz.

Das Labor verfolgt diese neben der Zufriedenheit. Ein Team, das Sprosse 5 erreicht, indem es teure Multi-Agenten-Schleifen für jede Aufgabe laufen lässt, kann technisch erfolgreich und gleichzeitig wirtschaftlich nicht nachhaltig sein.

Die kritischen Fähigkeiten: Spezifikation und Prozessdesign

Der Engpass des Labors liegt nicht in der Implementierungsgeschwindigkeit – sondern in der Arbeit an der vorderen Grenze. Zwei neue Fähigkeiten:

• Spezifikation – Anweisungen schreiben, die präzise genug sind, damit der Agent ohne menschliche Intervention korrekt implementiert.
• Prozessdesign für KI – die Rahmenbedingungen, Gates und Validierungsstufen zu gestalten, innerhalb derer der Agent konsistent operiert. Unterscheidet sich von Prompt-Engineering und vom Spezifikationsschreiben an sich. Siehe KI-Ausführungsstandards § Schicht 5.

Fast niemand hat beide vollständig entwickelt.

Die Schwierigkeit bei der Spezifikation: 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. Die Klärungsphase der operativen Einheit ist der strukturelle Fix – aber nur, wenn das Team sie nutzt.

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.

---

Risikoabgestufte Validierungs-Gates

Phase 4 (Validierung) der operativen Einheit ist risikoabgestuft – unterschiedliche Aktionsklassen erhalten unterschiedliche Gates. Die Dimensionen, die das Gate bestimmen, übernommen aus SAE J3016 (Fahren) als sauberstes Analogon:

• Operational Design Domain (ODD) – die Bedingungen, unter denen der Agent funktionieren soll. Außerhalb der ODD macht der Agent keine Aussagen; das Gate fällt auf den Menschen zurück.
• Fallback-Verantwortung – wer übernimmt die Aktion, wenn der Agent feststeckt oder eine verbotene Grenze trifft.
• Aufsichtsanforderung – was der Mensch während des Betriebs tun soll.
• Kontrollübergabe – wie die Befugnis zwischen Agent und Mensch wechselt.

Die drei operativen Haltungen

Ein reifes Sprosse-5-Team betreibt alle drei gleichzeitig. Beispiele:

Aktion	Gate	Begründung
Code-Merge in main (gut getestetes Repo, Agent-Prüfer)	HOOTL	Reversibel (revertierbar); Wirkungsradius durch CI begrenzt
Produktionsdeploy	HITL	Irreversibel auf Kundenwahrnehmungsebene; hohe Auswirkung
Entworfene Finanztransaktion im Buchhaltungssystem	HITL	Irreversibel (Prüfprotokoll); regulatorische Implikationen
Routine-Kundensupport-Antwort (innerhalb des Wissensdatenbank-Umfangs)	HOTL	Reversibel; Qualität überwacht; Agent-Prüfer für Ton/Richtlinie
Erstattung oder Gutschrift über Schwellenwert ausgestellt	HITL	Finanzielle Irreversibilität; Vertrauensimplikationen

Die absoluten Regeln des Labors („Code nicht von Menschen geschrieben oder geprüft") gelten weiterhin innerhalb des HOOTL-Modus. Aber Sprosse-5-Teams treten bewusst aus HOOTL heraus für irreversible Arbeit – das ist eine risikoabgestufte Designentscheidung, kein Rückschritt.

Wachsamkeitsmüdigkeit

HOTL ist operativ fragil, wenn es als passives Monitoring behandelt wird. Damit HOTL sinnvoll ist, muss der Mensch (a) Interventionsbefugnis haben (Kill-Switch, Rollback, Override) und (b) tatsächlich aufmerksam sein. Wachsamkeitsmüdigkeit ist gut dokumentiert; Teams, die alles als HOTL als Compliance-Theater kennzeichnen, stellen fest, dass ihre Aufsicht illusorisch ist. Die kognitiven Kosten anhaltender Wachsamkeit sind real (siehe Kognitive Kosten).

---

Stuck-State-Protokoll

Wenn die Validierung scheitert oder der Agent bei einem Liefergegenstand feststeckt, wird die Antwort von der Wiederherstellungsphase der operativen Einheit – und den Regeln des Labors – bestimmt.

Der Fehlermodus KI-Engpass

Auf Sprosse 5 bedeutet „im Rückstand bei einem Liefergegenstand" selten, dass die menschliche Kapazität knapp ist. Es bedeutet, dass der Agent an eine strukturelle Grenze gestoßen ist – falsche Richtung, mehrdeutige Spezifikation, subjektiver Randfall, den er allein nicht lösen kann. Cemri et al. (Why Do Multi-Agent LLM Systems Fail?, 2025) stellten fest, dass 41,8 % der Multi-Agenten-Fehlschläge Spezifikations- oder Designprobleme sind, die Neu-Spezifikation brauchen, kein erneutes Versuchen.

Rekalibrieren, nicht debuggen

Die Literatur zur intrinsischen Selbstkorrektur ist einstimmig: Ein Modell, das sich auf eine falsche Richtung festgelegt hat, wird dies nicht zuverlässig von selbst bemerken; Reflexion im selben Kontextfenster nach einer falschen Antwort verstärkt den Fehler, statt ihn zu beheben. Der Wiederherstellungs-Schritt ist, das Verständnis des Agenten wieder aufzubauen – frischer Kontext, neu artikulierte Spezifikation, Multi-Perspektiven-Brainstorm – nicht das vom Agenten produzierte Artefakt zu debuggen.

Praktisches Muster auf Sprosse 5:

1. Den Stuck-State erkennen – Iterationsgrenze erreicht; gleiches Fehlermuster wiederkehrend; vom Nutzer aufgeworfenes subjektives Problem.
2. Aufhören zu iterieren. Eine Rekalibrierungssitzung einberufen – ein oder mehrere Menschen treten mit dem Agenten in einen Dialog; das Ziel ist, die falsche Annahme offenzulegen.
3. Neu spezifizieren oder neu kontextualisieren. Abnahmekriterien verfeinern, mehrdeutige Anforderungen beheben, CLAUDE.md / AGENTS.md aktualisieren, wenn der Intent vom dokumentierten Kontext abgewichen ist.
4. Die Schleife von Kontext aus neu starten, nicht von Ausführung. Ein frischer Agentenlauf mit einer korrigierten Spezifikation übertrifft fast immer fortgesetzte Korrekturen innerhalb des ursprünglichen Kontextfensters.

Laborregel für Stuck-States

Wenn ein Laborprojekt feststeckt, die Arbeit nicht manuell zurücknehmen. Die Implementierung in menschliche Hände zurückzuholen verletzt die absoluten Regeln des Labors und ersetzt das Symptom (langsame Auslieferung) durch ein schlimmeres (das Labor demonstriert nicht mehr, wie Sprosse 5 aussieht). Die richtige Antwort ist kollektive Rekalibrierung: Mehr Menschen in die Spezifikation/Klärung einbringen, die falsche Annahme offenlegen, die Schleife neu ausführen.

Wenn die Arbeit auf Sprosse 5 wirklich nicht wiederherstellbar ist, liegt die Codereife des Projekts unter dem, was das Team betreibt – temporär auf eine niedrigere Sprosse zurückfallen und das Harness sanieren (Codereife, Brownfield-Strategie). Das ist ein legitimer Schritt; im Labor zur manuellen Codierung zurückzukehren nicht.

---

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.

---

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.

---

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 – Die Spec-zu-Ausgeliefert-Feedbackschleife muss schnell sein. Wenn eine Iteration Tage dauert, ist der Zyklus zu schwerfällig

---

Zu vermeidende Fallstricke

• Pitfall: 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.

• Pitfall: Unzureichende Spezifikationen

  Wenn der Agent schlechten Code produziert, liegt das Problem meist in der Spezifikation. Rekalibrieren (neu spezifizieren, neu kontextualisieren), bevor das Artefakt debuggt wird. Iterieren Sie an der Spezifikation, nicht am Code.

• Pitfall: Isolation

  Ein Labor, das seine Erkenntnisse nicht teilt, ist ein Hobby, kein Labor.

• Pitfall: 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.

• Pitfall: Agenten-Perfektionismus

  Das Ziel ist kein perfekter Agent. Es ist ein Agent, der Wert produziert. Iterieren.

• Pitfall: *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.

• Pitfall: "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.

• Pitfall: 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.

• Pitfall: Einen KI-Engpass als Produktivitätsproblem behandeln

  Wenn der Agent nicht ausliefern kann, ist es fast nie ein Kapazitätsproblem (der Agent hat nahezu unbegrenzte Kapazität). Es ist fast immer ein Spezifikations- oder Kontextproblem. Arbeit auf Menschen umzuverteilen ersetzt die falsche Grundursache und verletzt die Regeln des Labors. Die richtige Antwort ist Rekalibrierung (siehe § 5).

---

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