Arbeitsweise · KI-Engineering
KI ist in meinem Entwicklungsprozess ein austauschbarer Worker. Spezifikation, Arbeitskontext, Workflow-State, technische Prüfungen und Freigaben sollen möglichst außerhalb des Modells kontrolliert werden.
Die Seite beschreibt das Entwicklungsmodell. Der konkrete Implementierungs- und Teststand wird weiterhin je Repository geprüft.
Sechs Verantwortlichkeiten
1 · Spec
Soll, Invarianten, Contracts und Akzeptanzkriterien.
2 · Context
Nur die für die Aufgabe relevanten Regeln, Dateien, Skills und Nachweise.
3 · Harness + State
Scope, Klassifikation, Autorisierung, Schritt, Resultate und Stop-Gründe.
4 · Worker
Lokaler oder externer Worker passend zu Aufgabe und Risiko.
5 · Verify
Tests, Contracts, Laufzeit- und Berechtigungsprüfungen.
6 · Evidence
Versionsbezogene Aussage darüber, was tatsächlich geprüft wurde.
Spec und Context
Fachliches Soll und Akzeptanzkriterien bilden den Anker. Code bleibt direkt bearbeitbar; entscheidend ist, dass Spezifikation, Code und Tests nicht still auseinanderdriften.
Der Worker erhält nur den für die Aufgabe nötigen Kontext. Scout, Implementer und Reviewer können deshalb mit getrennten Arbeitskontexten arbeiten: Suchbereich und Evidenzpflicht für den Scout, freigegebener Plan und betroffene Dateien für die Implementierung, Diff, Kriterien und Tests für den Review.
State, Autorisierung und Routing
Chat-Historie ist kein verlässlicher Workflow-State. Der Lauf hält deshalb relevante Zustände wie Scope, Planreferenz, Kritikalität, Autorisierungsstatus, aktuellen Schritt, Resultate und Stop-Grund explizit fest.
- Authorization: Darf die konkrete Arbeit ausgeführt werden?
- Qualification: Welche Ausführungsklasse und welcher Worker reichen aus?
- Execution: Was wurde tatsächlich verändert und geprüft?
Grundsatz ist das kleinste ausreichend leistungsfähige Modell. Unsicherheit, neue Risiken oder Schutzgrenzen können die Klasse anheben; fehlt eine Voraussetzung, soll der Ablauf stoppen statt still auf einen ungeeigneten Fallback auszuweichen.
Menschliche Gates bleiben für neue Architekturentscheidungen, sensible Außenwirkung, irreversible Änderungen, Konflikte zwischen Anforderungen und Release-Freigaben vorgesehen.
Gezielte Verifikation und Evidence
Tests richten sich nach betroffenen Eigenschaften und Fehlerklassen: schnelle Syntax- und Unit-Prüfungen, gezielte Tests, Cross-App-Contracts und – wenn Änderung oder Risiko es erfordern – eine vollständige Suite. Bei Berechtigungen gehören positive und negative Fälle zusammen.
Ein früherer PASS bleibt nur gültig, solange seine Grundlage unverändert ist. Änderungen an Datenbankschema, Migrationen, Abhängigkeiten, Bootstrap, Berechtigungsmodell oder zentralen Contracts können einen Nachweis veralten lassen.
- PASS: ausgeführt und erfolgreich
- FAIL: ausgeführt und Anforderung verletzt
- NOT_RUN: bewusst nicht ausgeführt
- STALE: vorhandener Nachweis für den aktuellen Stand nicht mehr gültig
Evidence belegt definierte Eigenschaften für einen bestimmten Stand – nicht Fehlerfreiheit oder pauschale Rechtskonformität.
Nachvollziehbarkeit und Grenzen
Ein Lauf soll rekonstruierbar sein: Task, Soll, Worker-Klasse, State-Übergänge, geänderte Dateien, Tests und Evidence. Dafür müssen keine vollständigen Gesprächshistorien, Secrets oder unnötigen personenbezogenen Inhalte dauerhaft gespeichert werden.
Risiken bleiben bei falscher oder unvollständiger Spezifikation, Spec Drift, ungeeignetem Kontext, nicht getesteten Fehlerklassen und Modellfehlern. Der Harness soll deshalb nicht „Vertrauen in KI“ erzeugen, sondern verhindern, dass Modellfehler automatisch zur Freigabe werden.
Kurzform: Spec vor Code · relevanter Kontext statt maximaler Kontext · expliziter State statt Chat-Historie · kleinster geeigneter Worker · menschliche Gates wo nötig · Evidence statt Modell-Selbstvertrauen.