Wie es funktioniert

Das Problem, das gelöst werden musste

Ein Sprachmodell hat ein Kontextfenster. Ein echtes Software-Projekt passt nicht hinein — nicht die Anforderungen, nicht der bestehende Code, nicht beides zugleich. Wer trotzdem ein ganzes Projekt in einen Prompt legt, bekommt eine Skizze zurück, kein Programm.

Prompt Slicing ist die Antwort darauf: die Anforderungen werden nicht zusammengefasst, sondern zerlegt. Jeder TaskSlice ist klein genug, dass er vollständig in einen Prompt passt — mitsamt dem Kontext, den genau dieser Schritt braucht.

Zwei Achsen: Phasen und Slices

Die Ausführung läuft auf zwei Ebenen, die sich kreuzen. Phasen laufen nacheinander und sind durch Barrieren getrennt: eine Phase beginnt erst, wenn alle Arbeitsschritte der vorigen fertig sind. Am Ende steht ein Konsistenz-Durchgang über das Ganze. Er ist so gebaut, dass eine fehlende oder gestörte Messung nichts durchwinkt: er meldet dann rot und schickt die betroffenen Arbeitsschritte in gedeckelte Reparatur-Runden. Die Messung selbst ist zuschaltbar und im betriebenen Dienst noch nicht eingeschaltet. Ein zusätzlicher Build- und Test-Durchgang über den Gesamtstand ist zuschaltbar; im betriebenen Dienst ist er an. TaskSlices laufen innerhalb einer Phase parallel — so viele gleichzeitig, wie die Betriebsart Worker bereitstellt.

Das ist der Unterschied zwischen „schneller tippen" und „mehr gleichzeitig bauen": die Reihenfolge bleibt gewahrt, wo sie fachlich zählt, und fällt weg, wo sie nur bremst.

REQUIREMENTS: Aus der Aufgabenbeschreibung entsteht ein geprüftes Anforderungsbild — offene Punkte werden als Annahmen festgehalten und sind im Lauf sichtbar.
ARCHITECTURE: Struktur, Schnittstellen und Abhängigkeiten werden festgelegt, bevor die erste Zeile Code entsteht.
IMPLEMENTATION: Die eigentliche Arbeit: jeder TaskSlice ist genau ein AI-Prompt auf einem Worker, mit eigenem Arbeitsbaum.
RECONCILIATION (zuschaltbar, im Betrieb an): Die parallel entstandenen Teile werden gegeneinander geprüft und zusammengeführt.
TEST: Tests entstehen als eigene Arbeitsschritte, nicht als Nachgedanke.
VERIFY (zuschaltbar, im Betrieb an): Das Ergebnis wird gegen die Anforderungen geprüft — nicht gegen die Absicht, die es erzeugt hat.
DOCUMENTATION: Was gebaut wurde, wird beschrieben, solange der Kontext noch da ist.
CONSISTENCY: Ein letzter Durchgang über das Ganze: passt zusammen, was getrennt entstand?

Illustration: ein grosser gluehender Block wird auf dem Amboss in eine Reihe gleich grosser kleiner Barren zerteilt — ein Epic wird zu Stories — Ein Epic, auf den Trigger-Zustand gezogen, zerlegt sich selbst in gleich geschnittene User Stories — laufen darf jede erst, wenn ein Mensch sie einzeln freigibt.

Was ein Worker tut

Ein Worker nimmt genau einen TaskSlice entgegen, führt einen AI-Prompt aus, validiert das Ergebnis und committet es. Kein Worker sieht den Gesamtplan; er sieht seinen Schritt und den Kontext, den dieser Schritt braucht. Die Koordination liegt beim Coordinator, der den Graphen hält und die Slices über eine dauerhafte Warteschlange verteilt.

Fällt ein Worker aus, geht sein Slice nicht verloren — er wird erneut zugestellt. Bleibt ein Slice unbestätigt liegen, zählt er als Bedarf und ein Worker wird nachgezogen(zuschaltbar).

Was du während des Laufs siehst

Ein Lauf ist kein schwarzer Kasten. Im Cockpit lässt sich live mitverfolgen, was gerade passiert: welcher TaskSlice bearbeitet wird, welche Änderungen dabei entstehen und welche Zwischenschritte das Modell nimmt.

Dazu gehören auch die Kosten — nicht am Monatsende zusammengefasst, sondern je TaskSlice einzeln ausgewiesen: welcher Schritt wie viel verbraucht hat. Wer nachvollziehen will, wo die Zeit oder das Budget eines Laufs hingegangen ist, findet die Antwort im Lauf selbst, nicht in einer nachträglichen Rekonstruktion.

Am Ende steht ein Repository, kein Vorschlag

Das Ergebnis ist kein Chatverlauf, aus dem jemand Code herauskopiert. Es ist ein Git-Repository mit Historie: jeder TaskSlice hinterlässt seinen Commit, jede Phase ihren Stand. Was dort liegt, ist prüfbar — von einem Menschen, von einer Pipeline, von einem Auditor.