Der 8-Phasen-Workflow für KI-Agenten
Wie Benjamin Thorstensen beim OpenAI Hackathon 5.000 € gewonnen hat
Zusammenfassung des Videos von Benjamin Thorstensen (Original auf YouTube)
📌 In Kürze
Das Problem: Wer mit KI-Agenten programmiert, kennt es – nach ein paar Stunden ist mehr kaputt als gebaut. Der Agent baut funktionierende Sachen um, dreht sich bei Bugs im Kreis, und am Ende erzeugt die KI mehr Arbeit, als sie abnimmt.
Die Lösung: Ein strukturierter Workflow in acht Phasen mit bewussten Kontext-Resets und Markdown-Dateien als Gedächtnis zwischen den Phasen. Dazu zwei zentrale Konzepte: das Kontextfenster im Auge behalten („Dumb Zone") und Features in vertikalen Slices statt schichtweise bauen, damit jedes Zwischenergebnis sofort testbar ist.
Bonus: Ein Trick, mit dem auch hartnäckige Bugs zuverlässig gefixt werden – durch Selbstverifizierung des Agenten.
🗺️ Die acht Phasen auf einen Blick
| # | Phase | Ziel | Output |
|---|---|---|---|
| 1 | Brainstorm | Klarheit über das Was | Markdown-Datei |
| 2 | Align | Gemeinsames Verständnis schaffen | Markdown-Datei |
| 3 | Plan | Nächsten Vertical Slice definieren | Plan als Markdown |
| 4 | Implement | Code schreiben lassen | Funktionierender Code |
| 5 | Test | Bedienung & Feel prüfen | Feedback-Iterationen |
| 6 | Recap | Überblick behalten | Mentales Modell |
| 7 | Refactor | Code aufräumen | Sauberere Codebasis |
| 8 | Commit | Atomar committen, MD-Files löschen | Pull Request |
🔄 Loop: Nach Phase 8 geht's zurück zu Phase 3 – nächster Slice, gleicher Zyklus.
Warum die meisten KI-Agenten-Projekte scheitern
Die Situation kennt fast jeder, der schon mit KI-Agenten gearbeitet hat: Man startet motiviert, lässt den Agenten loslegen – und zwei Stunden später hat er funktionierende Sachen kaputt umgebaut, dreht sich im Kreis bei einem Bug, und am Ende steht die Frage im Raum, ob die KI eigentlich Arbeit abnimmt oder neue erzeugt.
Genau dieses Problem hat Benjamin Thorstensen gemeinsam mit seiner Frau beim OpenAI Hackathon mit einem strukturierten Workflow gelöst – und damit Platz 5 von 45 Teams sowie zwei ChatGPT Pro Abos im Gesamtwert von über 5.000 € geholt. In seinem Video beschreibt er den kompletten Workflow, das Konzept der „Dumb Zone" und einen Trick, mit dem sich auch hartnäckige Bugs zuverlässig fixen lassen.
🧠 Das Fundament: Die „Dumb Zone" verstehen
Jedes KI-Modell hat laut Thorstensen eine Smart Zone und eine deutlich größere Dumb Zone:
| Zone | Token-Bereich | Verhalten |
|---|---|---|
| 🟢 Smart Zone | 0 – ~100.000 Tokens | Modell ist scharf |
| 🔴 Dumb Zone | ab ~100.000 Tokens | Spürbarer Qualitätsabfall |
Token-Verbrauch prüfen:
- In Codex: status
- In Claude Code: /context
⚠️ Achtung bei 1M-Kontext-Modellen: Thorstensens Beobachtung – die ersten 100.000 Tokens sind exzellent, der riesige Mittelteil ist erstaunlich schwach, am Ende werden manche Modelle wieder besser.
💡 Konsequenz für den Workflow: Zwischen den Phasen bewusst Kontext-Resets machen und Zwischenergebnisse über Markdown-Dateien transportieren.
Der komplette 8-Phasen-Workflow
Phase 1 · Brainstorm 🧠
Ziel: Klarheit über das Was bekommen.
Thorstensen nutzt dafür einen eigenen Brainstorm-Skill (verfügbar in seinem GitHub-Repository), der je nach Thema die passende Brainstorming-Methode vorschlägt.
Hilfreich, wenn man: - zu viele Ideen hat und Entscheidungen treffen muss - einen Sparringspartner braucht - vor einem unklaren Problem steht
📝 Am Ende: Ergebnisse in eine Markdown-Datei speichern – die Brücke zur nächsten Phase nach dem Kontext-Reset.
Phase 2 · Align 🎯
Ziel: Gemeinsames Verständnis zwischen Mensch, Team und KI.
Laut Thorstensen der wichtigste Schritt im gesamten Workflow. Alles, was hier nicht explizit ausgesprochen wird, denkt sich die KI selbst aus – genau da entstehen später die meisten Frustrationen.
💡 Empfehlung: Der
Grill Me-Skill von Mat Pocock. Die KI interviewt den Nutzer aktiv und ausführlich, statt nach zwei Fragen sofort zu implementieren.
📝 Am Ende: Wieder als Markdown speichern.
Phase 3 · Plan 📐
Ziel: Den nächsten Vertical Slice definieren.
Hier kommt das wichtigste Software-Engineering-Prinzip dieses Workflows ins Spiel.
Was ist ein „Slice" überhaupt?
Software besteht typischerweise aus mehreren übereinanderliegenden Schichten:
┌─────────────────┐
│ UI / Frontend │ ← was der User sieht
├─────────────────┤
│ Logik / API │ ← was berechnet & entschieden wird
├─────────────────┤
│ Datenbank │ ← was gespeichert wird
└─────────────────┘
Wenn man ein Produkt in handhabbare Stücke („Slices") zerlegt, kann man das auf zwei Arten tun:
- Horizontal – Schicht für Schicht. Erst das gesamte UI für alle Features, dann die gesamte Logik, dann die Datenbank.
- Vertikal – wie ein Tortenstück senkrecht durch alle Schichten. Pro Feature alle Schichten gleichzeitig, aber eben nur für dieses eine Feature.
Konkretes Beispiel: Hotelbuchungs-App
Statt erst das ganze UI, dann die ganze Logik, dann die ganze Datenbank zu bauen, schneidet man Feature für Feature komplett durch:
| Slice | Was vertikal abgedeckt wird | Nach diesem Slice ist… |
|---|---|---|
| Slice 1 | Reservieren-Button + Buchungslogik + DB-Eintrag | …Reservieren komplett möglich |
| Slice 2 | Stornieren-Button + Storno-Logik + DB-Update | …Stornieren komplett möglich |
| Slice 3 | Bestätigungsmail + Mail-Service + Newsletter-Eintrag | …die Buchung kommuniziert sich selbst |
Jeder Slice ist nach Fertigstellung sofort benutzbar und testbar – auch wenn das Produkt insgesamt erst zu einem Drittel fertig ist.
Warum das mit KI-Agenten besser funktioniert
| Aspekt | ❌ Horizontal Slicing | ✅ Vertical Slicing |
|---|---|---|
| Vorgehen | Erst alles UI, dann Logik, dann DB | Pro Feature alle Schichten auf einmal |
| Testbarkeit | Spät – erst wenn alle Schichten fertig sind | Sofort nach jedem Slice |
| Feedback-Loop | Lang | Kurz |
| KI-Verhalten | Tendiert von selbst dazu | Muss aktiv eingefordert werden |
⚠️ Wichtig: KI-Agenten neigen ohne klare Anweisung zu horizontalem Vorgehen. Im Prompt sollte deshalb explizit stehen, dass ein Vertical Slice gebaut werden soll.
Bewährter Prompt-Einstieg:
„Schau dir die Markdown-Dokumente an, die wir kürzlich erstellt haben. Lass uns darüber sprechen, welchen Vertical Slice wir uns als Nächstes vornehmen. Stell mir Fragen, bis wir ein gemeinsames Verständnis haben."
Zwei zusätzliche Hebel:
- 🎨 UI skizzieren und der KI als Bild geben – vermeidet enorm viele Missverständnisse.
- 🧪 Testing-Strategie gemeinsam definieren – damit der Agent selbst erkennen kann, wann eine Aufgabe wirklich fertig ist.
💡 Faustregel: Wenn nur noch kosmetische Detailfragen kommen („Welche Farbe soll der Button haben?"), Plan ausgeben lassen. Drüberlesen reicht – nicht Wort für Wort analysieren.
Phase 4 · Implement ⚙️
Ziel: Plan in Code umsetzen.
Kontext-Reset, dann den Plan implementieren lassen. Während der Implementierung wird der Token-Verbrauch beobachtet.
| Agent | Automatische Compaction |
|---|---|
| Codex (OpenAI) | Funktioniert mittlerweile gut |
| Claude Code | Eher schwach – manuelles Resetten besser |
⚠️ Im Zweifel lieber einen sauberen Reset als einen schwammigen Mittelteil.
Phase 5 · Test 🧪
Ziel: Das Gefühl beim Bedienen bewerten.
Hier kommt menschliches Feedback zu dem ins Spiel, was die KI selbst nicht beurteilen kann: das Bedienerlebnis. Zu viele Buttons? Zu viele Inputfelder? Zu viel Text?
Die reine Funktionalität ist meist schon erfüllt, weil der Agent in Phase 3 die Verifikationskriterien mitbekommen hat. Jetzt geht es um Bedienbarkeit und Politur in kurzen Iterationen.
Phase 6 · Recap 🔍
Ziel: Den Überblick über das eigene Produkt behalten.
Nach mehreren „Bau noch ein Feature, bau noch ein Feature"-Iterationen verliert man sonst den Überblick darüber, was das Tool eigentlich kann.
Empfohlene Fragen an die KI:
„Wie funktioniert das, was wir gerade gebaut haben?"
„Erklär mir den Ablauf."
„Zeichne mir das Ganze als Diagramm."
⚠️ Achtung – diese Phase nicht überspringen: Wer das Denken nach und nach an die KI abgibt, hat irgendwann ein Produkt, das in eine Richtung läuft, die nicht mehr kontrollierbar ist.
Phase 7 · Refactor 🧹
Ziel: Code vereinfachen, bevor er zum Schiefen Turm wird.
KI-Agenten lieben es, komplizierten Code hinzuzufügen. Ohne aktives Gegensteuern baut die nächste Iteration auf einem immer schlechteren Fundament auf – und die KI orientiert sich an diesem Chaos.
Bewährte Refactor-Fragen:
Was wäre der kleinste Schritt, der diese Codebasis besser macht?
Kann ein neuer Entwickler den Ablauf ohne mentale Sprünge verstehen?
Welcher Refactoring-Schritt würde das Verhalten erhalten, aber die Struktur verbessern?
Phase 8 · Commit ✅
Ziel: Sauber abschließen, Aufräumen, weiter zu Phase 3.
Der Ablauf:
- Atomar committen – Anweisung an den Agenten: „Commit code atomically" (kleine, fokussierte Git-Commits).
- Markdown-Files löschen – alle Dateien aus den vorherigen Phasen entfernen.
- Push oder Pull Request – je nach Setup.
💡 Warum die MD-Files löschen? Sie waren Mittel zum Zweck und veralten, sobald der echte Code existiert. In der nächsten Iteration würde die KI sich davon verwirren lassen. Falls später noch gebraucht – sie liegen ja im vorherigen Commit.
🔄 Der Loop im Überblick
Brainstorm → Align → ┌──────────────────────────────────────────────────────┐
│ Plan → Implement → Test → Recap → Refactor → Commit │ ↻
└──────────────────────────────────────────────────────┘
Phase 1 und 2 macht man einmal pro Projekt. Phase 3 bis 8 wiederholt sich pro Feature/Slice.
❌ Was Thorstensen nicht empfiehlt: Frameworks wie Ralph Loop oder Gadget Done Loop, die diesen Zyklus automatisieren. Begründung: Die KI hat noch kein Produktgefühl. Erst durch die manuellen Iterationen wird klar, wie sich das Produkt anfühlen soll – und das lässt sich nicht im Vorhinein definieren. Im Grunde dasselbe Argument wie damals beim Wechsel vom Wasserfall- zum agilen Vorgehen.
🐛 Bonus: Hartnäckige Bugs fixen mit Selbstverifizierung
Spätestens nach zehn Iterationen tauchen Bugs auf, die einfach nicht weichen wollen. Der Trick: Die KI muss sich selbst verifizieren können – ohne dass jeder Versuch manuell getestet wird.
🔧 Effektiver Prompt:
„Ich stoße immer wieder auf folgenden Bug: [Beschreibung]. In den letzten Iterationen haben wir keinen Fix gefunden. Lass uns gemeinsam erarbeiten, wie du selbst verifizieren kannst, dass der Bug wirklich gefixt ist."
Damit bekommt der Agent eine eigene Testschleife: ausprobieren, prüfen, neu ansetzen, bis es klappt.
🔧 Variante für mittelschwere Bugs:
„Beschreibe das Problem für den nächsten Agenten und was du schon versucht hast."
Diese Beschreibung in einen frischen Chat kopieren – der saubere Kontext löst erstaunlich oft, woran der vorherige Agent gescheitert ist.
🏆 Was beim Hackathon entstanden ist: Honest Product Tester
Das Gewinner-Projekt von Benjamin und Oana Thorstensen: Honest Product Tester.
Konzept: Sechs KI-Agenten testen mit unterschiedlichen Personas eine Website: - 👔 der gestresste Manager - 🎓 die skeptische Studentin - 💻 der Techie, der alles brechen will - (plus drei weitere)
Jeder Agent bekommt seinen eigenen Browser und liefert am Ende ein Review zurück. Gebaut wurde das Tool mit dem Pi Agent von Mario Zechner.
Ergebnis: Platz 5 von 45 Teams · Zwei ChatGPT Pro Abos · Über 5.000 € Gesamtwert.
🎯 Fazit
Das wichtigste Take-away:
Es gibt nicht den einen Workflow.
Vieles in Thorstensens Vorgehen ist von anderen abgeschaut, kombiniert und neu ausprobiert. Genau das ist auch seine Empfehlung – sich das herauspicken, was funktioniert, und den eigenen Loop verfeinern.
Die wiederkehrenden Prinzipien dahinter sind aber stabil:
- ✅ Kontext bewusst managen
- ✅ Gemeinsames Verständnis vor Code
- ✅ Vertikal statt horizontal slicen
- ✅ Nie aufhören, das Produkt selbst zu verstehen
🔗 Links aus dem Video
- Skills GitHub Repository – Brainstorm- & Grill Me-Skill
- Video zum Pi Agent von Mario Zechner
- Oana Thorstensens YouTube-Kanal – Projektmanagement-Sicht auf solche Workflows
Kommentare
Noch keine Kommentare. Schreib den ersten.
Melde dich an, um zu kommentieren.