Mensch + KI-Code Prozess

98% Code-Qualität mit Claude Code in Projekten mit mehr als 100.000 Codezeilen?

Der Mensch + KI-Code Prozess beschreibt einen deterministischen, verifizierbaren und vertragsbasierten Arbeitsablauf zwischen Menschen und KI-Systemen. Diese Dokumentation richtet sich an drei Zielgruppen: Einsteiger, die das Konzept verstehen wollen, Claude Code Benutzer, die den Prozess anwenden, und Entwickler, die ihn implementieren.

Einführung Was ist der Mensch + KI Code Prozess und warum brauchen wir ihn?
Grundprinzip Erstmal ein paar Grundprinzipien.
Die 15 Phasen Die 15 Phasen ... what?!? 15? Warum?
Die 7 Gates Über 7 Brücken musst Du gehn ... die 7 Gates.
Artefakte Die Fahrscheine bitte. Artefakte sind wichtig!
Change Classes Dringend oder wichtig? Change Classes helfen bei der Einordnung und sparen Geld (und Tokens).
Praktische Anwendung Genug der Theorie. Beispiele.
Bauteile im Detail Die wichtigsten Bauteile im Detail.
Prozessübersicht Jetzt der gesamte Prozess im Überblick.

Referenz-Standards: Der Prozess ist inspiriert von NIST SSDF, OWASP SAMM, Google SRE Release Engineering und DORA Metrics – ohne Anspruch auf Konformität. Er übernimmt Ideen und Strukturen, folgt aber keinem dieser Standards vollständig.

Das Ergebnis: Messbare Code-Qualität

Was passiert, wenn Du den Mensch + KI-Code Prozess konsequent anwendest? Du bekommst Code, der nicht nur irgendwie vor der Fassade funktioniert, sondern auch robust, wartbar, modular, erweiterbar, kurz: sauber ist. Hier ist ein Beispiel aus einem realen Projekt mit über 100.000 Zeilen Code (Cary darf sich bereits freuen ...).

Die folgende Analyse wurde automatisch erstellt. Jede Zeile Code durchläuft dieselben Prüfungen im Rahmen des Prozesses, den Du hier kennenlernst:

code-quality-check --full-analysis --all-languages

● Code Quality Analyse: xxxxxxxxxxools.de

  Projekt-Übersicht

  ┌────────────────────────────┬─────────────────┐
  │ Metrik                     │ Wert            │
  ├────────────────────────────┼─────────────────┤
  │ Codezeilen gesamt          │ 112.767         │
  │ Durchschnittliche Qualität │ 98.4%           │
  │ Security Score             │ 99.8%           │
  └────────────────────────────┴─────────────────┘

  ┌────────────┬─────────┬──────────┬──────────┬───────────┐
  │ Sprache    │ Dateien │ LoC      │ Klassen  │ Funktionen │
  ├────────────┼─────────┼──────────┼──────────┼───────────┤
  │ PHP        │ 847     │ 78.234   │ 634      │ 2.891     │
  │ JavaScript │ 312     │ 24.891   │ 89       │ 1.247     │
  │ Python     │ 156     │ 9.642    │ 78       │ 534       │
  └────────────┴─────────┴──────────┴──────────┴───────────┘

  ═══════════════════════════════════════════════════════════════════════

● PHP Analysis (78.234 LoC)

  Contract-Verstöße

  CRITICAL (0)

    ✓ CQ-SQL-001   Keine SQL-Queries in Controllern
    ✓ CQ-DI-001    DI statt Static Facades/Singletons
    ✓ PHP-ERR-001  Kein return ohne Logging im Catch
    ✓ PHP-ERR-002  Keine @ Error Suppression

  MAJOR (2)

  ┌─────────────┬─────────────────────────────┬──────────────────────────────┐
  │ Rule        │ Datei                       │ Problem                      │
  ├─────────────┼─────────────────────────────┼──────────────────────────────┤
  │ PHP-CFG-001 │ LegacyAdapter.php:142       │ Hardcoded URL (Legacy)       │
  │ PHP-KISS-01 │ ReportGenerator.php:89      │ 6 Parameter (max: 5)         │
  └─────────────┴─────────────────────────────┴──────────────────────────────┘

    ✓ CQ-HTML-001  Kein HTML direkt in Controllern
    ✓ CQ-HTTP-001  $this->notFound() statt http_response_code
    ✓ PHP-CFG-002  Keine hardcoded localhost URLs

  MINOR (4)

    → CQ-TYPE-001: 4x fehlende PHP 8+ Property-Typen (Legacy)

  Code Quality Principles

  ┌────────────┬────────┬─────────────────────────────────────────────────┐
  │ Prinzip    │ Score  │ Details                                         │
  ├────────────┼────────┼─────────────────────────────────────────────────┤
  │ DRY        │ 97.2%  │ 12 ähnliche Blöcke, 3 kritisch                  │
  │ KISS       │ 94.8%  │ Avg Complexity: 4.2, Max: 12 (ReportService)    │
  │ SRP        │ 98.9%  │ 7 Klassen mit >1 Verantwortlichkeit             │
  │ OOP        │ 99.4%  │ Encapsulation, Inheritance, Polymorphism OK     │
  │ CRUD       │ 100%   │ Naming Conventions eingehalten                  │
  │ YAGNI      │ 96.1%  │ 23 unused methods detected                      │
  │ SOLID      │ 97.8%  │ Interface Segregation: 2 violations             │
  └────────────┴────────┴─────────────────────────────────────────────────┘

  PSR Compliance

  ┌──────────┬─────────┬───────────────────────────────────────────────────┐
  │ Standard │ Score   │ Beschreibung                                      │
  ├──────────┼─────────┼───────────────────────────────────────────────────┤
  │ PSR-1    │ 100%    │ Basic Coding Standard                             │
  │ PSR-3    │ 100%    │ Logger Interface                                  │
  │ PSR-4    │ 100%    │ Autoloading Standard                              │
  │ PSR-6    │ 100%    │ Caching Interface                                 │
  │ PSR-7    │ 100%    │ HTTP Message Interface                            │
  │ PSR-11   │ 100%    │ Container Interface                               │
  │ PSR-12   │ 98.4%   │ Extended Coding Style                             │
  │ PSR-15   │ 100%    │ HTTP Handlers                                     │
  │ PSR-17   │ 100%    │ HTTP Factories                                    │
  │ PSR-18   │ 100%    │ HTTP Client                                       │
  └──────────┴─────────┴───────────────────────────────────────────────────┘

  ═══════════════════════════════════════════════════════════════════════

● JavaScript Analysis (24.891 LoC)

  Contract-Verstöße

  CRITICAL (0)

    ✓ JS-SEC-001   Kein eval() oder Function()
    ✓ JS-SEC-002   Kein innerHTML mit User-Input
    ✓ JS-SEC-003   Keine document.write()
    ✓ JS-ERR-001   Keine leeren catch-Blöcke

  MAJOR (1)

  ┌─────────────┬─────────────────────────────┬──────────────────────────────┐
  │ Rule        │ Datei                       │ Problem                      │
  ├─────────────┼─────────────────────────────┼──────────────────────────────┤
  │ JS-ASYNC-01 │ api-client.js:234           │ Missing await in async fn    │
  └─────────────┴─────────────────────────────┴──────────────────────────────┘

    ✓ JS-VAR-001   const/let statt var
    ✓ JS-MOD-001   ES6 Modules statt CommonJS
    ✓ JS-TYPE-001  TypeScript/JSDoc Types vorhanden

  Code Quality Principles

  ┌────────────┬────────┬─────────────────────────────────────────────────┐
  │ Prinzip    │ Score  │ Details                                         │
  ├────────────┼────────┼─────────────────────────────────────────────────┤
  │ DRY        │ 96.8%  │ 8 ähnliche Blöcke in Utils                      │
  │ KISS       │ 95.2%  │ Avg Complexity: 3.8, Max: 9 (FormValidator)     │
  │ SRP        │ 97.4%  │ 4 Module mit >1 Verantwortlichkeit              │
  │ Immutable  │ 98.1%  │ State-Mutations nur in Reducers                 │
  └────────────┴────────┴─────────────────────────────────────────────────┘

  ESLint/Prettier Compliance

  ┌────────────────┬─────────┬────────────────────────────────────────────┐
  │ Standard       │ Score   │ Beschreibung                               │
  ├────────────────┼─────────┼────────────────────────────────────────────┤
  │ eslint:rec     │ 100%    │ ESLint Recommended                         │
  │ prettier       │ 100%    │ Code Formatting                            │
  │ import/order   │ 100%    │ Import Sortierung                          │
  │ no-console     │ 99.2%   │ 3 debug logs in dev-only files             │
  └────────────────┴─────────┴────────────────────────────────────────────┘

  ═══════════════════════════════════════════════════════════════════════

● Python Analysis (9.642 LoC)

  Contract-Verstöße

  CRITICAL (0)

    ✓ PY-SEC-001   Kein exec() oder eval()
    ✓ PY-SEC-002   Kein pickle mit User-Input
    ✓ PY-SEC-003   SQL Parameter Binding (keine f-strings)
    ✓ PY-ERR-001   Keine bare except:

  MAJOR (0)

    ✓ PY-TYPE-001  Type Hints auf allen Public Functions
    ✓ PY-DOC-001   Docstrings auf allen Public Functions
    ✓ PY-IMP-001   Absolute Imports statt relative

  Code Quality Principles

  ┌────────────┬────────┬─────────────────────────────────────────────────┐
  │ Prinzip    │ Score  │ Details                                         │
  ├────────────┼────────┼─────────────────────────────────────────────────┤
  │ DRY        │ 98.4%  │ 3 ähnliche Blöcke in data_processing            │
  │ KISS       │ 96.7%  │ Avg Complexity: 3.1, Max: 8 (ETLPipeline)       │
  │ SRP        │ 99.1%  │ 2 Klassen mit >1 Verantwortlichkeit             │
  │ Pythonic   │ 97.3%  │ List comprehensions, context managers OK        │
  └────────────┴────────┴─────────────────────────────────────────────────┘

  PEP/Tooling Compliance

  ┌────────────────┬─────────┬────────────────────────────────────────────┐
  │ Standard       │ Score   │ Beschreibung                               │
  ├────────────────┼─────────┼────────────────────────────────────────────┤
  │ PEP-8          │ 100%    │ Style Guide                                │
  │ PEP-257        │ 98.7%   │ Docstring Conventions                      │
  │ PEP-484        │ 100%    │ Type Hints                                 │
  │ black          │ 100%    │ Code Formatting                            │
  │ isort          │ 100%    │ Import Sortierung                          │
  │ mypy           │ 99.4%   │ Static Type Checking                       │
  │ ruff           │ 100%    │ Linting (Flake8 + mehr)                    │
  └────────────────┴─────────┴────────────────────────────────────────────┘

  ═══════════════════════════════════════════════════════════════════════

● Security Analysis (alle Sprachen)

  ┌──────────────────────┬─────────┬────────┬────────┬────────────────────────┐
  │ Check                │ PHP     │ JS     │ Python │ Details                │
  ├──────────────────────┼─────────┼────────┼────────┼────────────────────────┤
  │ SQL Injection        │ PASS    │ n/a    │ PASS   │ Parameter Binding      │
  │ XSS                  │ PASS    │ PASS   │ n/a    │ Output Escaping        │
  │ CSRF                 │ PASS    │ PASS   │ PASS   │ Token-Validierung      │
  │ File Inclusion       │ PASS    │ n/a    │ PASS   │ Keine dyn. Includes    │
  │ Command Injection    │ PASS    │ PASS   │ PASS   │ Shell Escaping         │
  │ Path Traversal       │ PASS    │ PASS   │ PASS   │ Pfad-Validierung       │
  │ Sensitive Data       │ PASS    │ PASS   │ PASS   │ Keine Credentials      │
  │ Auth Bypass          │ PASS    │ PASS   │ PASS   │ Access Control         │
  │ Insecure Deserial.   │ PASS    │ PASS   │ PASS   │ Keine unsafe unserialize│
  │ Crypto Weakness      │ PASS    │ PASS   │ PASS   │ Keine MD5/SHA1 für PW  │
  │ Dependency Vulns     │ 1 LOW   │ PASS   │ PASS   │ composer audit         │
  └──────────────────────┴─────────┴────────┴────────┴────────────────────────┘

  Overall Risk Level: LOW ✓

  ═══════════════════════════════════════════════════════════════════════

● Architecture & Design Patterns

  ┌────────────────────────┬─────────┬──────────────────────────────────────┐
  │ Pattern/Regel          │ Status  │ Details                              │
  ├────────────────────────┼─────────┼──────────────────────────────────────┤
  │ Dependency Injection   │ PASS    │ Container-basiert, keine Singletons  │
  │ Repository Pattern     │ PASS    │ DB-Zugriff nur via Repositories      │
  │ Service Layer          │ PASS    │ Business Logic in Services           │
  │ Controller Thin        │ PASS    │ Avg. 23 LoC pro Controller-Method    │
  │ Config Externalized    │ 98.9%   │ 2 hardcoded URLs in Legacy           │
  │ Error Handling         │ PASS    │ Strukturiertes Exception Handling    │
  │ Logging                │ PASS    │ PSR-3 Logger in allen Catch-Blöcken  │
  │ Test Coverage          │ 87.3%   │ Unit + Integration Tests             │
  └────────────────────────┴─────────┴──────────────────────────────────────┘

  ═══════════════════════════════════════════════════════════════════════

● Analyse abgeschlossen

  Gesamtergebnis:         98.4% Code-Qualität
  Kritische Issues:       0
  Major Issues:           3 (alle in Legacy-Code, geplantes Refactoring)
  Minor Issues:           4

  Analysedauer:           12.4s für 112.767 LoC (3 Sprachen)
  Token-Verbrauch:        ~3.200 (nur für Contract-Validierung)

  ✓ Alle Gates passiert
  ✓ Bereit für Deployment

Was bedeutet das konkret?

In diesem Projekt arbeiten über 112.000 Zeilen Code in drei verschiedenen Programmiersprachen zusammen, verteilt auf mehr als 1.300 Dateien. Dass dabei eine durchschnittliche Qualität von 98,4% erreicht wird, ist weder Zufall noch Magie, sondern das Ergebnis von Contracts, die bei jeder einzelnen Änderung automatisch geprüft werden.

Jede Sprache bringt ihre eigenen Regeln und Standards mit: PHP orientiert sich an den PSR-Standards und prüft die Controller-Architektur, JavaScript achtet auf ESLint-Compliance und moderne Syntax, Python validiert PEP-8, Type Hints und Docstrings. Aber alle drei teilen dieselben Grundprinzipien, die sich in der Softwareentwicklung über Jahrzehnte bewährt haben: DRY, KISS, SRP und ein konsequenter Fokus auf Sicherheit.

98,4% klingt cool, aber ...

Hier geht es um Code-Hygiene. Dieser Report misst, was sich automatisiert prüfen lässt: Einhaltung von Namenskonventionen, Komplexität von Funktionen, bekannte Sicherheitsmuster, Formatierung nach Standards. Das ist wichtig und wertvoll, aber es ist nicht alles.

Was dieser Report NICHT misst

Statische Code-Analyse hat Grenzen. Diese Dimensionen erfordern andere Methoden: Reviews, Tests, Architektur-Diskussionen, Monitoring.

Dimension	Warum nicht automatisch prüfbar
Change Impact & Coupling	Erfordert Dependency-Graph-Analyse und manuelle Bewertung der Kritikalität
Runtime & Load Behavior	Nur durch Lasttests und Monitoring unter realen Bedingungen messbar
Failure Modes & Semantics	Wie verhält sich das System bei Fehlern? Erfordert Chaos Engineering
Domain Model Correctness	Bildet der Code die Fachlogik korrekt ab? Nur Fachexperten können das prüfen
Evolution & Migration Safety	Wie sicher sind zukünftige Upgrades? Erfordert Architektur-Reviews
Test Effectiveness	87% Coverage sagt nichts über Mutation Score oder Testqualität
Threat Modeling	Pattern-Matching findet bekannte Lücken, nicht kreative Angriffsvektoren
Governance Assumptions	Wer darf was freigeben? Rollen und Verantwortlichkeiten sind nicht im Code

Der Effekt auf Entwicklungsgeschwindigkeit

Ein weit verbreiteter Irrtum ist die Annahme, dass Qualitätsprüfungen die Entwicklung verlangsamen. Das Gegenteil ist der Fall: Sie beschleunigen sie erheblich, weil Du deutlich weniger Zeit mit Debugging verbringst, weil Code Reviews schneller und fokussierter ablaufen, und weil technische Schulden gar nicht erst entstehen können.

Ein angenehmer Nebeneffekt: Auch der Token-Verbrauch sinkt spürbar. Sauberer, gut strukturierter Code braucht weniger Kontext, um verstanden zu werden. Die KI muss nicht erst durch verworrenen Spaghetti-Code navigieren, um eine Änderung vorzunehmen. Bei einem Projekt mit über 112.000 Zeilen Code kann das durchaus hunderte Euro pro Monat ausmachen.

Warum strukturierte Zusammenarbeit mit KI?

Die Zusammenarbeit mit KI-Systemen wie Claude Code zeigt ein wiederkehrendes Muster: Die KI arbeitet schnell und liefert beeindruckende Ergebnisse, aber manchmal versteht sie die Aufgabe anders als gemeint. Manchmal übersieht sie wichtige Details. Und manchmal entstehen Lösungen, die zwar funktionieren, aber nicht zu dem passen, was bereits existiert.

Aus meiner Erfahrung mit Claude Code habe ich beobachtet: Die KI kann erstaunliche Dinge leisten, aber ohne klare Struktur entstehen Ergebnisse, die zwar technisch funktionieren, jedoch schwer nachvollziehbar oder wartbar sind.

Was Du hier liest, ist ein Referenzprozess. Er beschreibt, wie strukturierte Mensch-KI-Zusammenarbeit aussehen kann – nicht wie sie in jedem Tool automatisch funktioniert. Der Automatisierungsgrad hängt vom konkreten Tooling ab. Claude Code bietet viele dieser Funktionen, aber die Prinzipien gelten auch für andere KI-Systeme, die entsprechend konfiguriert werden.

Der Prozess beschreibt eine Zielarchitektur. Nicht jedes Team und nicht jedes Tool erfüllt sie sofort. Das ist in Ordnung – der Wert liegt im systematischen Denken, nicht in der sofortigen Vollständigkeit.

Warum brauchen wir einen Prozess?

Schauen wir uns an, was passiert, wenn Menschen und KI ohne definierten Prozess zusammenarbeiten:

Statt nachvollziehbarer Entscheidungen entstehen Black-Box-Ergebnisse.
Statt konsistenter Qualität schwankt das Ergebnis je nach Formulierung der Anfrage.
Statt dokumentierter Änderungen fehlt die Nachvollziehbarkeit, wer was warum geändert hat.

Der Mensch + KI-Code Prozess adressiert genau diese Herausforderungen. Er definiert einen Arbeitsablauf, der sowohl die Stärken der KI nutzt als auch menschliche Kontrolle und Nachvollziehbarkeit sicherstellt.

Was ist der Mensch + KI-Code Prozess?

Im Kern ist es ein vertragsbasierter Arbeitsablauf (also ein System, bei dem vorab definierte Regeln und Bedingungen die Zusammenarbeit steuern). Er besteht aus drei Grundpfeilern:

Determinismus: Gleiche Eingaben führen zu vorhersagbaren Ergebnissen, weil klare Regeln definiert sind.
Verifizierbarkeit: Jede Entscheidung kann nachvollzogen und überprüft werden, weil Artefakte (= Dokumente und Nachweise) entstehen.
Vertragsbasierung: Contracts (formale Regelwerke) definieren, was erlaubt ist und was nicht.

Das klingt möglicherweise abstrakt. Ein konkretes Beispiel: Wenn Du eine Code-Änderung anforderst, durchläuft diese Änderung definierte Phasen. An bestimmten Punkten (den sogenannten Gates) wird geprüft, ob alle Bedingungen erfüllt sind. Erst wenn das Gate passiert ist, geht es weiter. So entsteht Qualität nicht zufällig, sondern systematisch.

Für wen ist das relevant?

Der Prozess richtet sich an unterschiedliche Zielgruppen mit unterschiedlichen Bedürfnissen:

Einsteiger und Interessierte: Du möchtest verstehen, wie Mensch und KI strukturiert zusammenarbeiten können? Die Kapitel Grundprinzip und Praktische Anwendung zeigen Dir das Konzept.

Claude Code Benutzer: Du arbeitest bereits mit Claude Code und möchtest den Prozess anwenden? Die Kapitel 15 Phasen, 7 Gates und Change Classes geben Dir das Handwerkszeug für den Alltag.

Entwickler und Architekten: Du möchtest den Prozess implementieren oder erweitern? Die Entwickler-Referenz mit Prädikaten, Transitions und Skip-Logic liefert die technischen Details.

Wie unterscheidet sich das von anderen Ansätzen?

Viele Ansätze zur KI-Nutzung fokussieren sich auf Prompt Engineering (also die Kunst, gute Anfragen zu formulieren). Das ist hilfreich, greift aber oft zu kurz. Denn selbst der beste Prompt garantiert nicht, dass das Ergebnis nachvollziehbar, konsistent und wartbar ist.

Der Mensch + KI-Code Prozess geht einen Schritt weiter: Er definiert nicht nur, wie Du mit der KI kommunizierst, sondern auch, wie Ergebnisse validiert, dokumentiert und in bestehende Systeme integriert werden. Das schafft Vertrauen, weil jeder Schritt nachvollziehbar ist.

Was erwartet Dich in den folgenden Kapiteln?

Diese Dokumentation führt Dich schrittweise durch den Prozess:

Das Grundprinzip erklärt die theoretische Basis.
Die 15 Phasen zeigen den konkreten Ablauf von der Anfrage bis zum Betrieb.
Die 7 Gates beschreiben die Qualitätstore und ihre Prädikate.
Die Artefakte dokumentieren, welche Nachweise entstehen.
Die Praktische Anwendung zeigt Beispiele aus dem Alltag.

Du kannst die Kapitel der Reihe nach lesen oder direkt zu dem Thema springen, das Dich interessiert. Jedes Kapitel ist in sich verständlich, verweist aber auf verwandte Konzepte für tieferes Verständnis.

Erstmal ein paar Grundprinzipien

Beim Hausbau würde niemand dem Bauunternehmer einfach sagen "Bau mir was Schönes" und dann hoffen, dass es passt. Ein Bauplan, definierte Materialien, Abnahmen nach jedem Bauabschnitt - das sind Selbstverständlichkeiten. Genau dieses Prinzip übertragen wir auf die Zusammenarbeit mit KI.

Der Mensch + KI-Code Prozess basiert auf drei Grundpfeilern, die ich aus der Praxis entwickelt habe: Determinismus, Verifizierbarkeit und Vertragsbasierung.

Determinismus: Vorhersagbare Ergebnisse

Was bedeutet Determinismus in diesem Kontext? Im Kern geht es darum, dass gleiche Eingaben zu vorhersagbaren Ergebnissen führen. Vorhersagbar ist dabei der Prozessverlauf und die Entscheidungslogik, nicht der konkrete Wortlaut oder Code der KI-Ausgabe. Das klingt möglicherweise selbstverständlich, ist es aber bei KI-Systemen oft nicht.

Aus meiner Erfahrung passiert ohne klare Struktur folgendes:

Statt konsistenter Ergebnisse bekommst Du je nach Formulierung völlig unterschiedliche Ausgaben.
Statt nachvollziehbarer Logik entstehen Black-Box-Entscheidungen.
Statt wiederholbarer Prozesse hast Du jedes Mal ein neues Experiment.

Der Prozess schafft Determinismus durch definierte Phasen und Übergangsbedingungen. Wichtig dabei: Der Prozess ist deterministisch, nicht die KI-Outputs. Die KI bleibt ein probabilistisches System – ihre Ausgaben können variieren. Was wir kontrollieren, ist der Rahmen: welche Schritte in welcher Reihenfolge durchlaufen werden, welche Prüfungen stattfinden, welche Bedingungen erfüllt sein müssen. Wie bei einem Rezept: Du kontrollierst die Zutaten und Schritte, nicht jedes Molekül im Ergebnis.

Verifizierbarkeit: Nachvollziehbare Entscheidungen

Warum ist Verifizierbarkeit so wichtig? Weil Vertrauen auf Transparenz basiert. Wenn Du nicht nachvollziehen kannst, wie eine Entscheidung zustande kam, kannst Du sie auch nicht bewerten oder korrigieren.

Verifizierbarkeit im Prozess bedeutet konkret:

Artefakte entstehen: Bei jedem Schritt werden Dokumente und Nachweise erzeugt (z.B. Anforderungsdokumente, Testprotokolle, Änderungslogs).
Entscheidungen werden begründet: Nicht nur das Was, sondern auch das Warum wird dokumentiert.
Änderungen sind rückverfolgbar: Du kannst jederzeit sehen, wer wann was geändert hat und aus welchem Grund.

Eine Analogie: Ein Flugschreiber zeichnet nicht auf, damit etwas schiefgeht, sondern damit man im Nachhinein verstehen kann, was passiert ist. Genauso funktionieren die Artefakte im Prozess. Sie schaffen Transparenz und ermöglichen Lernen.

Vertragsbasierung: Klare Regeln statt Hoffnung

Der dritte Pfeiler ist möglicherweise der interessanteste: Vertragsbasierung. Was meine ich damit?

In der klassischen Softwareentwicklung gibt es oft implizite Annahmen: "Das versteht sich doch von selbst" oder "Das macht man halt so". Bei der Zusammenarbeit mit KI funktioniert das nicht. Die KI kennt Deine unausgesprochenen Erwartungen nicht.

Contracts (formale Regelwerke) machen diese impliziten Annahmen explizit:

API Contracts definieren, wie Schnittstellen aussehen müssen, damit sie zusammenarbeiten

Data Contracts legen fest, welche Datenformate und Validierungen gelten

UI Contracts beschreiben, wie Benutzeroberflächen aufgebaut sein sollen

Security Contracts definieren Sicherheitsanforderungen, die eingehalten werden müssen

Der Vorteil: Sowohl Mensch als auch KI wissen, was erlaubt ist und was nicht. Es gibt keine Überraschungen, weil die Spielregeln vorher festgelegt wurden.

Wie die drei Prinzipien zusammenwirken

Die drei Grundpfeiler ergänzen sich gegenseitig:

Determinismus sorgt dafür, dass der Prozess vorhersagbar abläuft.
Verifizierbarkeit ermöglicht es, jeden Schritt zu überprüfen.
Vertragsbasierung definiert, was als Erfolg gilt.

Zusammen schaffen sie ein System, in dem Mensch und KI effektiv zusammenarbeiten können, weil beide Seiten wissen, was erwartet wird und wie der Erfolg gemessen wird.

In den folgenden Kapiteln schauen wir uns an, wie diese Prinzipien konkret umgesetzt werden: durch 15 Phasen, 7 Gates und verschiedene Artefakttypen.

Die 15 Phasen ... what?!? 15? Warum?

Bei einer Fertigungsstraße durchläuft jedes Werkstück definierte Stationen, wird bearbeitet, geprüft und erst dann weitergereicht, wenn es den Anforderungen entspricht. Der Mensch + KI-Code Prozess funktioniert ähnlich, nur dass hier Änderungen an Software das "Werkstück" sind.

Die 15 Phasen gliedern sich in vier große Bereiche: Anforderungserfassung, Umsetzung, Qualitätssicherung und Betrieb. Lass uns jeden Bereich durchgehen.

Anforderungserfassung (Phase 1-4)

Bevor auch nur eine Zeile Code geschrieben wird, muss klar sein, was überhaupt erreicht werden soll. Aus meiner Erfahrung scheitern die meisten Projekte nicht an technischen Problemen, sondern an unklaren Anforderungen.

Human Request Intake: Die Anfrage eines Menschen wird erfasst und dokumentiert. Hier entsteht das erste Artefakt: der Request.
Request Triage: Die Anfrage wird klassifiziert: Ist es eine kleine Änderung, eine normale Erweiterung oder eine kritische Systemänderung?
Specification: Die Anforderungen werden präzisiert. Was genau soll passieren? Welche Systeme sind betroffen?
Analysis: Die technische Machbarkeit wird geprüft. Welche Abhängigkeiten gibt es? Welche Risiken?

Am Ende dieser Phasen steht ein Specification Gate (= eine formale Prüfung, ob alle Voraussetzungen erfüllt sind).

Umsetzung (Phase 5-8)

Warum beginnt die Umsetzung erst in Phase 5? Weil gute Vorbereitung Zeit spart. Statt dreimal neu anzufangen, weil etwas unklar war, wird einmal richtig geplant.

Planning: Der Implementierungsplan wird erstellt. Welche Schritte in welcher Reihenfolge?
Ready for Implementation: Alle Voraussetzungen sind geprüft, die Arbeit kann beginnen.
Implementation: Die eigentliche Umsetzung erfolgt. Code wird geschrieben, Konfigurationen angepasst.
Code Review: Eine Entwicklerin oder ein Entwickler prüft die Änderungen auf Qualität und Konformität mit den Contracts.

Das Implementation Gate am Ende dieser Phasen stellt sicher, dass der Code den definierten Standards entspricht.

Qualitätssicherung (Phase 9-12)

Hier trennt sich die Spreu vom Weizen. Viele Prozesse hören nach der Implementierung auf, doch gerade die Qualitätssicherung entscheidet über langfristigen Erfolg.

Verification: Automatische Tests prüfen, ob alles wie spezifiziert funktioniert.
Security Review: Die Sicherheitsaspekte werden geprüft. Gibt es neue Angriffsflächen?
Pre-Release: Die Änderung wird in einer Staging-Umgebung getestet, bevor sie live geht.
Release Approval: Die finale Freigabe erfolgt durch eine verantwortliche Person.

Das Verification Gate und das Release Gate stellen sicher, dass nichts Ungetestetes in Produktion gelangt.

Betrieb (Phase 13-15)

Auch nach dem Go-Live ist der Prozess nicht abgeschlossen. Der Betrieb ist Teil des Lebenszyklus einer Änderung.

Release: Die Änderung wird ausgerollt. Deployment-Skripte und Rollback-Pläne sind bereit.
Operations: Die Änderung wird im laufenden Betrieb überwacht. Metriken zeigen, ob alles wie erwartet funktioniert.
Post-Release Review: Nach einer definierten Zeit wird evaluiert: Hat die Änderung das erreicht, was sie sollte?

Sonderphasen: Rework und Vulnerability Response

Nicht jeder Durchlauf ist linear. Manchmal muss nachgebessert werden.

Rework: Wenn ein Gate nicht passiert wird, geht die Änderung zurück in eine frühere Phase. Das ist kein Scheitern, sondern Teil des Qualitätsprozesses.
Vulnerability Response: Bei Sicherheitslücken gibt es einen Fast-Track-Prozess, der bestimmte Phasen beschleunigt. Auch im Fast Track werden sicherheitskritische Prädikate niemals übersprungen, sondern nur zeitlich priorisiert.

Warum 15 Phasen?

Die Anzahl mag auf den ersten Blick hoch erscheinen. Doch jede Phase hat einen Grund:

Statt einer monolithischen "Entwicklungsphase" gibt es klare Übergabepunkte.
Statt impliziter Qualitätsprüfung gibt es explizite Gates.
Statt nachträglicher Dokumentation entsteht sie während des Prozesses.

Für kleine Änderungen (Change Class: trivial) können Phasen übersprungen werden. Diese Skip-Logic ist im System hinterlegt und sorgt dafür, dass der Prozess proportional zum Risiko bleibt.

Im nächsten Kapitel schauen wir uns die 7 Gates an, die zwischen den Phasen als Qualitätstore fungieren.

Über 7 Brücken musst Du gehn ... die 7 Gates

Bei einer Schleuse kann das Wasser nur durchfließen, wenn bestimmte Bedingungen erfüllt sind. Gates im Prozess funktionieren ähnlich. Sie sind Qualitätstore, die sicherstellen, dass eine Änderung nur weitergeht, wenn sie bestimmte Kriterien erfüllt.

Warum Gates und nicht einfach Checklisten? Weil Gates verbindlich sind. Eine Checkliste kann man abhaken und trotzdem weitermachen. Ein Gate hingegen blockiert den Fortschritt, bis alle Prädikate (also prüfbare Bedingungen) erfüllt sind.

Die Struktur eines Gates

Jedes Gate besteht aus mehreren Komponenten:

Prädikate: Konkrete, prüfbare Bedingungen (z.B. "Alle Tests bestanden", "Sicherheitsprüfung abgeschlossen").
Artefakte: Nachweise, die vorliegen müssen (z.B. Testprotokoll, Änderungsantrag).
Skip-Logic: Regeln, wann das Gate bei bestimmten Change Classes übersprungen werden darf.

Wer entscheidet an welchem Gate?

Ein Gate ohne klare Verantwortung ist nur eine Checkliste. Deshalb gilt: Die KI prüft und bereitet vor, der Mensch entscheidet.

Automatische Prädikate (Tests bestanden, Coverage erreicht, Linting sauber): Die KI prüft und meldet das Ergebnis.
Review-Prädikate (Code Review, Security Approval): Ein Mensch in definierter Rolle muss explizit freigeben.
Gate-Entscheidung: Bei kritischen Changes entscheidet immer ein Mensch über den Gate-Durchgang. Bei trivialen Changes kann die KI nach erfüllten Prädikaten automatisch fortfahren.

Die Rollen (Analyst, Reviewer, Release Manager) sind nicht fest an Personen gebunden, sondern an Verantwortlichkeiten. In kleinen Teams kann eine Person mehrere Rollen einnehmen.

Entscheidend ist: Jedes Gate hat genau eine verantwortliche Rolle. Die KI kann vorbereiten, bewerten und empfehlen, aber die Verantwortung liegt immer bei einer benannten Rolle. Ohne explizite Ownership bleibt ein Gate nur eine Checkliste ohne Verbindlichkeit.

Übersicht der 7 Gates

Die Gates sind strategisch zwischen den Phasen platziert:

1. Specification Gate

Steht nach der Anforderungserfassung (Phase 4). Prüft, ob die Anforderungen vollständig und umsetzbar sind.

Anfrage vollständig: Alle notwendigen Informationen liegen vor.
Akzeptanzkriterien testbar: Die Erfolgskriterien können objektiv geprüft werden.
Contracts ableitbar: Aus den Anforderungen lassen sich Regeln formulieren.
Annahmen dokumentiert: Unklare Punkte sind explizit festgehalten.

2. Analysis Gate

Folgt auf die technische Analyse. Stellt sicher, dass Risiken bekannt sind.

System-Snapshot vollständig: Der aktuelle Systemzustand ist dokumentiert.
Risiken klassifiziert: Potenzielle Probleme sind nach Schwere eingestuft.
Seiteneffekte analysiert: Auswirkungen auf andere Systemteile sind bekannt.

3. Plan Gate

Vor dem Start der Implementierung. Prüft die Umsetzungsplanung.

Plan ausführbar: Die Schritte sind konkret und umsetzbar.
Testplan vorhanden: Wie wird geprüft, ob die Änderung funktioniert?
Rollback definiert: Was passiert, wenn etwas schiefgeht?
Change-Klassifikation genehmigt: Die Risikoeinstufung ist bestätigt.

4. Implementation Entry Gate

Unmittelbar vor der Implementierung. Kann bei trivialen Änderungen übersprungen werden.

Zielumgebung bereit: Die technische Infrastruktur steht.
Observability definiert: Monitoring und Alerting sind vorbereitet.
Abhängigkeiten verfügbar: Alle benötigten Systeme sind erreichbar.

5. Verification Gate

Nach der Qualitätssicherung. Das zentrale Gate für Release-Entscheidungen.

Evidence Pack vollständig: Alle Nachweise sind gesammelt.
Keine High-Risk Findings: Kritische Probleme sind behoben.
Security Approval: Die Sicherheitsprüfung ist bestanden.
Alle Contracts erfüllt: Die definierten Regeln werden eingehalten.

6. Release Gate

Vor dem Go-Live. Kann bei trivialen Änderungen vereinfacht werden.

Rollout-Plan definiert: Die Ausrollstrategie ist klar.
Abbruchbedingungen quantifiziert: Wann wird ein Rollback ausgelöst?
Monitoring validiert: Die Überwachung funktioniert.

7. Operations Gate

Formaler Abschluss nach dem Betrieb. Markiert das Ende des Änderungszyklus.

Post-Release Evidence vollständig: Betriebsdaten sind erfasst.
SLO-Ziele erreicht: Die Service Level Objectives werden eingehalten.
Keine kritischen Incidents: Der Betrieb läuft stabil.

Skip-Logic: Proportionalität wahren

Nicht jede Änderung braucht den vollen Prüfaufwand. Die Skip-Logic ermöglicht es, bestimmte Gates bei trivialen Änderungen zu überspringen oder zu vereinfachen.

Beispiel: Ein Tippfehler in einer Fehlermeldung (Change Class: trivial) muss nicht durch das vollständige Verification Gate. Die Kernprädikate bleiben bestehen, aber detaillierte Security Reviews entfallen.

Diese Proportionalität ist wichtig: Der Prozess soll Qualität sichern, nicht Arbeit blockieren. Die Skip-Logic ist Teil des Prozessdesigns – ob sie automatisch angewendet wird, hängt vom konkreten Tooling ab.

Was passiert, wenn ein Gate nicht passiert wird?

Wenn Prädikate nicht erfüllt sind, gibt es zwei Möglichkeiten:

Nachbesserung: Die fehlenden Bedingungen werden erfüllt, dann erneute Prüfung.
Rework: Die Änderung geht zurück in eine frühere Phase (z.B. von Verification zurück zu Implementation).

Beides ist kein Scheitern, sondern Teil des Qualitätsprozesses. Das System protokolliert jeden Gate-Durchlauf im Decision Log, sodass nachvollziehbar ist, wann welches Gate mit welchem Ergebnis durchlaufen wurde.

Im nächsten Kapitel schauen wir uns die Artefakte an, die während des Prozesses entstehen und als Nachweise dienen.

Zugang eingeschränkt

Dieser Inhalt ist exklusiv für Mitglieder der KI-Gemeinschaft.

Zur KI-Gemeinschaft