Strukturiert statt Vibe-Coding: Deterministisches Vorgehen in nichtdeterministischen Systemen

Warum nichtdeterministische Agenten ein doppelt deterministisches Gegengewicht erzwingen – Functional Programming auf der technischen und ein rigoroser Prozess auf der prozessualen Achse.

1. Das Problem: Nondeterminismus als Systemeigenschaft

Agentische Systeme sind keine deterministischen Maschinen. Derselbe Prompt erzeugt verschiedene Ausgaben, dieselbe Aufgabe führt zu unterschiedlichen Lösungswegen. Das ist keine Fehlfunktion, sondern eine Systemeigenschaft.

"An LLM is nondeterministic — there is no sure or consistent output for a given input. Although the output is based on probabilities and isn't purely random, the user doesn't get to see what those probabilities are." — Jay Alammar & Maarten Grootendorst: Common Sense Guide to AI Engineering, S. 34

Der erste Artikel dieser Serie hat daraus eine Konsequenz für den Code abgeleitet: Wenn der Agent nichtdeterministisch ist, muss der Code, den er aufruft und generiert, umso deterministischer sein – das ist die Begründung für Functional Programming als Grundlage.

Dieser Artikel erweitert die Schlussfolgerung um eine zweite Dimension: Nicht nur der Code muss deterministisch sein, sondern auch das Vorgehen. Je mehr Nichtdeterminismus ein System produziert, desto mehr Determinismus muss der Mensch und sein Prozess als Gegengewicht einbringen. Der Nichtdeterminismus verschwindet nicht – er wird durch ein deterministisches Rahmenwerk eingehegt.

2. Vibe-Coding: Warum es radioaktiver Müll ist

Vibe-Coding bezeichnet die Praxis, einen Prompt abzusetzen, den generierten Code zu übernehmen und weiterzumachen – ohne Plan, ohne atomare Commits, ohne Review. Der Code "funktioniert irgendwie", also wird er akzeptiert. Das Vorgehen orientiert sich am Gefühl ("Vibe"), nicht an einer nachvollziehbaren Struktur.

Das Ergebnis ist nicht nur Müll, sondern radioaktiver Müll: Er sieht zunächst brauchbar aus, strahlt aber unsichtbar weiter. Wissen geht verloren, Entscheidungen sind nicht rekonstruierbar, und die Folgekosten akkumulieren mit jedem weiteren Schritt.

❌ Vibe-Coding: Fortschritt ohne Spur

• Prompt absetzen, Code übernehmen, weitermachen.
• Keine atomaren Commits – Änderungen vermischen sich.
• Kein Review – niemand prüft die Entscheidung.
• Kein nachvollziehbarer Plan – das "Warum" existiert nur im Kopf, bis es vergessen ist.
• Erfolg wird am Gefühl gemessen, nicht an reproduzierbaren Zuständen.

✅ Strukturiertes Vorgehen: Jeder Schritt ist eine Spur

• Verfeinerter Plan vor der Umsetzung.
• Jedes Ticket ist ein atomarer, reviewbarer Commit.
• Review als Gate vor der Integration.
• Entscheidungen sind im Commit, im Ticket und im Plan dokumentiert.
• Erfolg wird an nachvollziehbaren, wiederherstellbaren Zuständen gemessen.

Der entscheidende Unterschied liegt nicht in der Geschwindigkeit, sondern in der Nachvollziehbarkeit. Vibe-Coding erzeugt Zustände, die niemand mehr erklären kann – und damit Wissen, das nie existiert hat.

Fallstudie: 6 Wochen im Vibe-Wahn

Sechs Wochen lang läuft die Entwicklung durchgehend im Vibe-Modus. Über drei Sprints werden Dutzende Tickets "abgeschlossen" – nach außen wirkt es wie Höchst-Output. Jeder Sprint-Review zeigt grüne Häkchen.

Gearbeitet wird mit dem Chat-Abo von Claude.ai statt mit einem API-Key – entgegen den Projektrichtlinien. Die Folge: kein sichtbares Kostensignal. Bei API-Nutzung wäre der exponentiell steigende Tokenverbrauch früh aufgefallen und hätte die wachsende Komplexität sichtbar gemacht. Steigende Tokenkosten pro Aufgabe sind ein Frühindikator für zunehmende Degeneration – dieses Warnsignal fehlt vollständig.

Mit der Zeit stockt der Fortschritt. Änderungen, die früher Minuten brauchten, kosten jetzt Stunden. Die entscheidende Beobachtung: Der Moment, in dem das Problem bemerkt wird, ist nicht der Anfang, sondern das Ende. Die Degeneration hat längst stattgefunden; sie wird erst sichtbar, als sie nicht mehr zu ignorieren ist.

Es folgt die Rückabwicklung. Schritt für Schritt wird zurückgerollt – und man landet faktisch am Ausgangspunkt. Die sechs Wochen Arbeit sind quasi verloren.

Radioaktiv ist dieser Zustand, weil sich nicht mehr erklären lässt, was passiert ist. Es gibt keine atomaren Commits, kein Review, keinen nachvollziehbaren Plan – hinzu kommt ein Richtlinienverstoß, der von Anfang an hätte vermieden werden müssen. Zurück bleibt kein verwertbares Wissen, sondern ein nicht rekonstruierbarer Zustand.

Genau diese Eskalation verhindern die beiden Achsen des Determinismus: Functional Programming und ein rigoroser Prozess mit atomaren Commits, Review-Gate und frühzeitigen Signalen.

3. Die zwei Achsen des Determinismus

Determinismus entsteht nicht an einer einzigen Stelle. Er braucht zwei sich ergänzende Achsen: eine technische (wie der Code aufgebaut ist) und eine prozessuale (wie gearbeitet wird).

Die technische Achse ist das Thema der bisherigen Serie: Pure Functions und Immutability machen das Verhalten einer Funktion vorhersagbar, Kategorien und Funktoren geben Transformationen formale Garantien, und Monaden als Protokoll kapseln Effekte deterministisch. FP-Patterns für Agent-Systeme setzen diese Bausteine zu konkreten Architekturen zusammen.

Monaden sind dabei das wirksamste Werkzeug: Sie verlagern Komplexität aus dem Kontrollfluss in Datenstrukturen. Statt try/except und verstreuter if/else-Ketten kapselt eine Result-Monade Erfolg und Fehler in einem expliziten, komponierbaren Typ. Der Effekt bleibt sichtbar und nachvollziehbar – genau das Gegenteil von verstecktem State.

Die technische Achse allein genügt jedoch nicht. Auch perfekt funktionaler Code kann im Vibe-Modus zu radioaktivem Müll werden, wenn niemand dokumentiert, warum er entstanden ist. Deshalb braucht es die zweite Achse.

4. Die prozessuale Achse: Ein rigoroser Prozess

Die prozessuale Achse beantwortet die Frage: Wie kommt eine Änderung kontrolliert ins System? Die Antwort ist eine kurze, harte Kette ohne Abkürzungen.

Begriffsklärung: Card vs. Ticket, Review durch den PO-Agent

Um eine Doppelbenennung zu vermeiden, wird hier konsequent zwischen zwei Ebenen unterschieden:

• Card bezeichnet die lokale Arbeitseinheit auf dem Kanban-Board (im Sinne von iKanbanAi). Der Begriff grenzt sie bewusst vom Jira-Ticket ab, das in vielen Organisationen die übergeordnete, grobgranulare Anforderung beschreibt. Eine Card ist feiner: genau ein atomarer, reviewbarer Zustand.
• Review meint hier ausdrücklich die Prüfung der Card durch den PO-Agent – nicht ein klassisches Code-Review unter Menschen, sondern das automatisierte Gate, das ein PO-Agent vor der Integration durchläuft.

1. Plan – Das Vorhaben wird als Plan formuliert, bevor Code entsteht.
2. Verfeinerung durch den PO – Der Product Owner schärft den Plan, zerlegt ihn in Cards und stellt sicher, dass jede Card eigenständig sinnvoll ist.
3. Card als kleinste Einheit – Jede Card (das lokale Pendant zum Jira-Ticket, nur feiner) beschreibt genau einen abgeschlossenen Zustand.
4. Card = atomarer Commit – Eine Card entspricht einem atomaren Commit: ein abgeschlossener, reviewbarer Zustand, nicht mehr und nicht weniger.
5. Review der Card durch den PO-Agent als Gate – Kein Zustand wird integriert, bevor die Card nicht durch das Review-Gate des PO-Agents gegangen ist.

Die Gleichung Card = atomarer Commit ist der Kern. Sie erzwingt, dass jede Änderung für sich genommen verständlich, prüfbar und rückrollbar ist. Geht etwas schief, betrifft das Zurückrollen genau einen Commit – nicht sechs Wochen vermischter Arbeit.

Kanban macht diesen Fluss sichtbar: Jede Card wandert durch klar definierte Spalten, der Work-in-Progress bleibt begrenzt, und Stockungen werden sofort erkennbar. Werkzeuge wie iKanbanAi übertragen dieses Prinzip auf die Zusammenarbeit mit Agenten – der nichtdeterministische Agent arbeitet innerhalb eines deterministischen, visualisierten Rahmens.

Der Prozess ist bewusst rigoros: Er lässt keine Ausnahme zu, weil jede Ausnahme die Tür zum Vibe-Coding wieder öffnet. Gerade weil der Agent in hohem Maße variabel ist, muss der Rahmen unverhandelbar sein.

5. Wissenserhalt: Der eigentliche Gewinn

Der wahre Wert dieses Vorgehens ist nicht sauberer Code, sondern konserviertes Wissen. Plan, Card und atomarer Commit bilden zusammen eine lückenlose Spur des "Warum":

• Der Plan hält fest, welches Ziel verfolgt wurde.
• Die Card hält fest, welche konkrete Entscheidung getroffen wurde.
• Der atomare Commit hält fest, wie sie umgesetzt wurde – isoliert und reviewbar.
• Das Review durch den PO-Agent stellt sicher, dass die Entscheidung über die Card hinaus geprüft und verstanden wurde.

Damit wird das Kernproblem des Vibe-Codings direkt adressiert. Vibe-Coding verliert Wissen, weil das "Warum" nur flüchtig im Kopf existiert und mit dem nächsten Prompt überschrieben wird. Ein strukturierter Prozess externalisiert dieses Wissen in dauerhafte Artefakte. Selbst wenn ein Zustand zurückgerollt werden muss, bleibt die Spur erhalten: Man weiß, was versucht wurde und warum es nicht funktioniert hat.

Nachvollziehbarkeit ist das Gegenmittel zur Radioaktivität. Ein Zustand, der erklärbar ist, strahlt nicht weiter.

6. Zusammenfassung & Checkliste

Nichtdeterministische Agenten erzwingen ein doppelt deterministisches Gegengewicht. Functional Programming sichert die technische Achse, ein rigoroser Prozess die prozessuale. Erst beide zusammen verhindern, dass scheinbarer Fortschritt in einen Totalverlust umschlägt.

Checkliste: Determiniertes Vorgehen mit Agents

Technische Achse (FP): - [ ] Pure Functions: gleicher Input → gleicher Output, keine Seiteneffekte. - [ ] Immutability: keine versteckte Mutation gemeinsamer Daten. - [ ] Explizite Signaturen als Vertrag zwischen Mensch und Agent. - [ ] Monaden statt verstreutem Kontrollfluss (Effekte explizit kapseln).

Prozessuale Achse (Kanban/Commits): - [ ] Plan existiert, bevor Code entsteht. - [ ] Plan durch den PO verfeinert und zerlegt. - [ ] Jede Card (lokal, feiner als das Jira-Ticket) = ein atomarer, reviewbarer Commit. - [ ] Review der Card durch den PO-Agent als unverhandelbares Gate. - [ ] Kanban visualisiert den Fluss; Frühwarnsignale (z. B. Tokenkosten) sind sichtbar.

Diese Checkliste ist die Klammer über die gesamte Serie. Die Artikel 01–04 begründen und vertiefen die technische Achse; dieser Artikel ergänzt die prozessuale. FP allein reicht nicht, und ein Prozess allein reicht nicht. Erst die Kombination macht die Arbeit mit nichtdeterministischen Agenten reproduzierbar – und bewahrt das Wissen, das sonst verloren geht.

Quellen

• Jay Alammar & Maarten Grootendorst: Common Sense Guide to AI Engineering, S. 34
• Eric S. Raymond: The Cathedral and the Bazaar, S. 30
• Scott Wlaschin: Domain Modeling Made Functional, S. 72
• David J. Anderson: Kanban: Successful Evolutionary Change for Your Technology Business, S. 15