Compound Engineering: Eine AI-native Engineering-Philosophie

• Eine zinseszinseffektartige Methodik der Softwareentwicklung, bei der jede Engineering-Arbeitseinheit spätere Arbeit erleichtert, mit einer systematisierten 4-Stufen-Schleife (Planung → Umsetzung → Review → Compound) als Kern der Zusammenarbeit mit AI-Agenten
• In der iterativen Schleife sollten 80 % der Zeit von Engineers für Planung und Review und 20 % für Umsetzung und Compound aufgewendet werden
• Wird als Plugin mit 26 spezialisierten Agenten, 23 Workflow-Kommandos und 13 Skills ausgeliefert und kann in Claude Code, OpenCode und Codex installiert werden
• Acht verbreitete Annahmen der klassischen Softwareentwicklung (Code muss von Hand geschrieben werden, jede Zeile muss manuell geprüft werden usw.) werden als Glaubenssätze, die abgelegt werden müssen, dargestellt; stattdessen sollen neue Prinzipien übernommen werden, bei denen Präferenzen im System kodiert werden
• Ein umfassendes Framework, das den AI-Einführungsgrad von Entwicklern von Stufe 0 (manuelle Entwicklung) bis Stufe 5 (parallele Cloud-Ausführung) unterscheidet und Wege zum Aufstieg je Stufe sowie Erweiterungen auf Teamarbeit, Design, Research und Marketing umfasst

---

Kernphilosophie

• Das Kernprinzip ist, dass jede Engineering-Arbeitseinheit spätere Arbeit einfacher machen soll
• In traditionellen Codebasen steigt mit jeder neuen Funktion die Komplexität, sodass man nach 10 Jahren mehr Zeit damit verbringt, gegen das System zu kämpfen
• In Compound Engineering bringt eine Funktion dem System neue Fähigkeiten bei, ein Bugfix beseitigt ganze Klassen künftiger Bugs, und Muster werden in Werkzeuge überführt, sodass die Codebasis mit der Zeit leichter zu verstehen, zu ändern und ihr zu vertrauen ist

Hauptschleife: Plan → Work → Review → Compound

• Das Team von Every betreibt fünf Produkte (Cora, Monologue, Sparkle, Spiral, Every.to) hauptsächlich mit Ein-Personen-Engineering-Teams; möglich macht das diese 4-Stufen-Schleife
• Die ersten drei Stufen (Planung, Umsetzung, Review) sind allgemein üblich, aber Stufe 4, Compound, ist der entscheidende Unterschied, in dem sich die Zinseszinseffekte ansammeln
• Ob es um einen 5-Minuten-Bugfix oder die Entwicklung eines Features über mehrere Tage geht: Es wird dieselbe Schleife verwendet, nur der Zeitaufwand pro Stufe variiert

• Stufe 1: Plan (Planung)

  • Anforderungen verstehen: erfassen, was gebaut werden soll, warum und unter welchen Einschränkungen
  • Codebasis untersuchen: analysieren, wie ähnliche Funktionen arbeiten und welche Muster bereits existieren
  • Externe Recherche: Framework-Dokumentation und Best Practices der Branche prüfen
  • Lösung entwerfen: Vorgehensweise und zu ändernde Dateien festlegen
  • Plan validieren: Vollständigkeit und Konsistenz des Gesamtplans prüfen

• Stufe 2: Work (Umsetzung)

  • Isolierte Umgebung einrichten: Arbeit über Git worktree (isolierte Kopie des Repositorys) oder Branch trennen
  • Plan umsetzen: Der Agent implementiert Schritt für Schritt
  • Validierung ausführen: nach jeder Änderung Tests, Linting und Typprüfung durchführen
  • Fortschritt verfolgen und den Plan bei Problemen anpassen
  • Wenn man dem Plan vertraut, muss nicht jede einzelne Codezeile überwacht werden

• Stufe 3: Review

  • Mehrere Agenten führen parallel Code-Reviews durch
  • Gefundene Punkte werden nach Priorität als P1 (muss behoben werden), P2 (empfohlene Korrektur), P3 (Verbesserung) klassifiziert
  • Der Agent behebt Issues auf Basis des Review-Feedbacks und validiert die Korrekturen
  • Muster dokumentieren: festhalten, was schiefgelaufen ist, um Wiederholungen zu verhindern

• Stufe 4: Compound — die wichtigste Stufe

  • Traditionelle Entwicklung endet bei Stufe 3, aber in der Compound-Stufe sammeln sich Systemverbesserungen an
  • Wenn die ersten drei Stufen Funktionen produzieren, produziert Stufe 4 ein System, das Funktionen besser erstellen kann
  • Auszuführende Aufgaben:
    • festhalten, was wirksam war und was nicht und welche Erkenntnisse wiederverwendbar sind
    • per YAML-Frontmatter Metadaten, Tags und Kategorien hinzufügen, damit Inhalte durchsuchbar werden
    • neue Muster in CLAUDE.md aufnehmen und bei Bedarf neue Agenten erstellen
    • prüfen: „Kann das System dieses Problem beim nächsten Mal automatisch erkennen?“

Plugin-Struktur

• 26 spezialisierte Agenten: für Review (14), Research, Design, Workflows, Dokumentation usw., jeweils auf bestimmte Aufgaben spezialisiert
• 23 Workflow-Kommandos: Hauptschleife plus Utilities
• 13 Skills: vermitteln Domänenexpertise wie agent-native Architektur, Styleguides usw.
• Kann in Claude Code, OpenCode (experimentell) und Codex (experimentell) ohne Konfiguration installiert werden

• Dateistruktur

  • CLAUDE.md: die wichtigste Datei, die Agenten zu Beginn jeder Session lesen; speichert Präferenzen, Muster und Projektkontext
  • docs/solutions/: gelöste Probleme werden als durchsuchbare Dokumente gesammelt und bauen institutionelles Wissen auf
  • docs/brainstorms/: speichert Ausgaben des brainstorm-Kommandos
  • docs/plans/: speichert Ausgaben des plan-Kommandos
  • todos/: verfolgt Aufgaben nach Priorität und Status

Zentrale Kommandos

• /workflows:brainstorm

  • Kommando für Fälle, in denen unklar ist, was gebaut werden soll
  • Nach einer leichten Repo-Recherche werden Zweck, Nutzer, Einschränkungen und Edge Cases durch gezielte Einzelfragen präzisiert
  • Die AI schlägt einen Ansatz vor, und das Ergebnis wird in docs/brainstorms/ gespeichert und an /workflows:plan übergeben

• /workflows:plan

  • Gibt einen Implementierungsplan zurück, wenn man beschreibt, was man möchte
  • Führt drei parallele Research-Agenten aus: repo-research-analyst (Muster in der Codebasis), framework-docs-researcher (Dokumentation), best-practices-researcher (Branchenstandards)
  • Der Agent spec-flow-analyzer analysiert User-Flows und Edge Cases
  • Bei aktiviertem ultrathink-Modus wird /deepen-plan automatisch ausgeführt und mehr als 40 parallele Research-Agenten werden gestartet

• /workflows:work

  • Die Stufe, in der der Agent tatsächlich Code schreibt
  • Vier Phasen: quick start (Git worktree erstellen und Branch einrichten) → execute (taskweise Implementierung mit Fortschrittsverfolgung) → quality check (optional mehr als 5 Review-Agenten starten) → ship it (Linting ausführen, PR erstellen)

• /workflows:review

  • Eine PR wird parallel und gleichzeitig von mehr als 14 spezialisierten Agenten reviewed
  • Enthält unter anderem Security (security-sentinel), Performance (performance-oracle), Architektur (architecture-strategist), Datenintegrität (data-integrity-guardian), Codequalität (code-simplicity-reviewer), Framework-spezifische Reviewer (DHH-rails, Kieran-rails/python/typescript), Deployment-Validierung, Frontend-Race-Conditions und agent-native Reviewer
  • Die Ausgabe ist eine einzelne priorisierte Liste mit Klassifizierung in P1 (kritisch), P2 (wichtig), P3 (kleineres Problem)
  • Mit dem Kommando /resolve_pr_parallel lassen sich gefundene Punkte automatisch beheben (P1 zuerst, jede Korrektur isoliert ausgeführt)
  • Mit dem Kommando /triage können Punkte gefiltert werden, indem sie einzeln bestätigt, übersprungen oder angepasst werden

• /workflows:compound

  • Dokumentiert gelöste Probleme zur späteren Referenz
  • Startet 6 parallele Sub-Agenten: context analyzer, solution extractor, related docs finder, prevention strategist, category classifier, documentation writer
  • Erzeugt durchsuchbares Markdown mit YAML-Frontmatter

• /lfg

  • Wenn ein Feature beschrieben wird, übernimmt der Agent Planung, Implementierung und Review vollständig und liefert eine mergefähige PR
  • Verkettet die gesamte Pipeline aus plan → deepen-plan → work → review → resolve findings → browser tests → feature video → compound
  • Hält nach Genehmigung des Plans kurz an und läuft dann autonom weiter; dabei werden mehr als 50 Agenten über alle Stufen hinweg eingesetzt

8 Überzeugungen, die man ablegen sollte

• "Code muss von Hand geschrieben werden"

  • Die eigentliche Anforderung ist, guten Code zu schreiben, der wartbar ist und das richtige Problem löst; wer tippt, ist nicht wichtig

• "Jede Zeile muss manuell geprüft werden"

  • Manuelles zeilenweises Review ist nur ein Weg zur Qualitätssicherung; automatisierte Systeme, die dieselben Probleme erkennen, sind ebenfalls valide
  • Wenn man dem Ergebnis nicht vertrauen kann, sollte man das nicht dadurch kompensieren, es selbst zu machen, sondern das System korrigieren

• "Lösungen müssen von Engineers kommen"

  • Da AI Ansätze recherchieren, Trade-offs analysieren und Optionen empfehlen kann, besteht die Rolle des Engineers darin, Geschmack (taste) hinzuzufügen — zu beurteilen, welche Lösung zu dieser Codebasis, diesem Team und diesem Kontext passt

• "Code ist das wichtigste Ergebnis"

  • Das System, das Code produziert, ist wertvoller als einzelner Code
  • Wichtiger als eine herausragende Implementierung ist ein Prozess, der konstant gute Implementierungen hervorbringt

• "Code schreiben ist die Kernaufgabe"

  • Die Aufgabe von Entwicklern ist es, Wert zu liefern (ship value), und Code ist nur ein Input dazu
  • Planung, Reviews und das Trainieren von Systemen gehören ebenfalls zur Arbeit

• "Der erste Versuch muss gut sein"

  • Die Fehlerquote des ersten Versuchs liegt bei 95 %, beim zweiten immer noch bei 50 %
  • Das ist kein Scheitern, sondern ein Prozess; man sollte sich auf schnelle Iteration konzentrieren, damit der dritte Versuch schneller fertig wird als der erste

• "Code ist Selbstausdruck"

  • Code gehört dem Team, dem Produkt und den Nutzern; wenn man Code nicht als Selbstausdruck betrachtet, werden das Annehmen von Feedback, Refactoring und Qualitätsdebatten leichter

• "Je mehr man tippt, desto mehr lernt man"

  • Heute ist Verständnis wichtiger als Muskelgedächtnis
  • Ein Entwickler, der 10 AI-Implementierungen reviewt, versteht mehr Muster als ein Entwickler, der selbst 2 davon tippt

Psychologische Herausforderungen im Übergang

• Weniger Tippen fühlt sich an, als würde man weniger arbeiten: Tatsächlich erfordert das Anweisen von Agenten mehr Denken als die Implementierung selbst
• Unsicherheit bei autonomer Ausführung: Es geht nicht darum, Kontrolle aufzugeben, sondern darum, Kontrolle in Form von Einschränkungen, Regeln und Review-Prozessen zu kodieren
• Die Frage „Habe ich das überhaupt gebaut?“: Planung, Review und das Sicherstellen von Qualitätsstandards sind genau diese Arbeit; die AI übernimmt nur das Schreiben

Überzeugungen, die man annehmen sollte

• Geschmack in das System extrahieren

  • Der Geschmack von Entwicklern — etwa Namenskonventionen, Fehlerbehandlungsmuster oder Testansätze — ist meist nicht dokumentiert und existiert nur in den Köpfen erfahrener Engineers
  • Solche Präferenzen sollten in CLAUDE.md oder AGENTS.md festgehalten und durch spezialisierte Agenten und Skills für Review, Tests und Deployment ergänzt werden, damit AI selbst Code produziert, der genehmigungsfähig ist

• Die 50/50-Regel

  • 50 % der Engineering-Zeit sollten auf Feature-Entwicklung, 50 % auf Systemverbesserung entfallen
  • Traditionell sind es 90 % Features und 10 % Sonstiges, doch Investitionen wie das Erstellen von Review-Agenten, das Dokumentieren von Mustern oder der Aufbau von Test-Generatoren machen künftige Features leichter
  • Eine Investition von 1 Stunde in einen Review-Agenten spart über ein Jahr hinweg 10 Stunden Review-Zeit

• Dem Prozess vertrauen und Sicherheitsnetze aufbauen

  • Damit AI-Unterstützung skalieren kann, kann nicht jeder Mensch jede Zeile reviewen; entscheidend ist daher der Aufbau von Guardrails wie Tests, automatischen Reviews und Monitoring
  • Wenn man dem Ergebnis nicht vertrauen kann, sollte man nicht zu manuellem Review zurückkehren, sondern ein System ergänzen, das diesen Schritt vertrauenswürdig macht

• Die Umgebung agent-native gestalten

  • Alles, was ein Entwickler sehen oder tun kann, sollte auch ein Agent können: Tests ausführen, Produktionslogs prüfen, Screenshots zum Debugging nutzen, PRs erstellen usw.
  • Alles, was einem Agenten nicht erlaubt wird, muss man selbst manuell erledigen

• Parallelisierung nutzen

  • Der frühere Engpass war die menschliche Aufmerksamkeit — eine Aufgabe gleichzeitig; der neue Engpass ist Compute — also wie viele Agenten gleichzeitig laufen können
  • Mehrere Agenten und mehrere Features sollten parallel laufen, ebenso Reviews, Tests und Dokumentation

• Planung ist der neue Code

  • Das Planungsdokument ist jetzt das wichtigste Ergebnis
  • Statt erst Code zu schreiben und später zu dokumentieren, sollte man zuerst den Plan schreiben, damit Agenten ihn als Source of Truth für Generierung, Tests und Verifikation des Codes nutzen können
  • Ideen auf Papier zu korrigieren ist günstiger, als sie im Code zu korrigieren

• Zusammenfassung der Kernprinzipien

  • Jede Arbeitseinheit sollte nachfolgende Arbeit leichter machen
  • Geschmack sollte im System verankert sein, nicht im Review
  • Nicht selbst arbeiten, sondern das System lehren
  • Kein Review-Prozess, sondern Sicherheitsnetze aufbauen
  • Die Umgebung agent-native strukturieren
  • Zinseszinseffekte auf alles anwenden
  • Die Unbequemlichkeit der Delegation akzeptieren und unvollkommene, aber skalierbare Ergebnisse statt perfekter, aber nicht skalierbarer Ergebnisse wählen
  • Weniger Code schreiben und mehr Wert liefern
  • Diese Prinzipien lassen sich über Engineering hinaus auf Design, Research, Schreiben und alle Bereiche ausweiten, in denen die Kodifizierung von Geschmack und Kontext hilft

Entwicklungsstufen von Entwicklern (5-stufige Ladder)

• Stage 0: Manuelle Entwicklung

  • Code wird ohne AI Zeile für Zeile geschrieben, Recherche erfolgt mit Dokumentation und Stack Overflow, Debugging mit print-Anweisungen
  • So wurde über Jahrzehnte hinweg gute Software gebaut, aber im Jahr 2025 ist das nicht mehr schnell genug

• Stage 1: Chat-basierte Assistenz

  • Man stellt ChatGPT, Claude, Cursor usw. Fragen, erhält Code-Snippets und kopiert die brauchbaren Teile per Copy-and-paste
  • AI beschleunigt Recherche und Boilerplate-Erstellung, aber man reviewt weiterhin jede Zeile selbst und behält vollständige Kontrolle

• Stage 2: Agentische Tools + zeilenweises Review

  • Agentische Tools wie Claude Code, Cursor Composer oder Copilot Chat lesen Dateien und nehmen direkt Änderungen an der Codebasis vor
  • Man übernimmt die Rolle des Gatekeepers, der alles genehmigt oder ablehnt, was der Agent vorschlägt
  • Die meisten Entwickler bleiben auf dieser Stufe hängen und nutzen die Vorteile der AI-Delegation nicht

• Stage 3: Planung zuerst, Review auf PR-Ebene

  • Hier verändert sich alles: Anforderungen, Ansatz und Edge Cases werden in einem detaillierten Plan gemeinsam mit der AI ausgearbeitet
  • Nach der Planung implementiert die AI ohne Aufsicht, und das Ergebnis wird als PR reviewt
  • Compound Engineering beginnt hier — Planung, Implementierung und Review in jedem Zyklus trainieren das System, sodass der nächste Zyklus schneller und einfacher wird

• Stage 4: Idee → PR (einzelne Maschine)

  • Man gibt eine Idee vor, und der Agent übernimmt alles: Recherche in der Codebasis, Planung, Implementierung, Tests, Self-Review, Beheben von Problemen und Erstellen des PR
  • Die Beteiligung reduziert sich auf drei Schritte: Idee geben, PR reviewen, mergen
  • Es läuft aber weiterhin immer nur eine Aufgabe gleichzeitig auf einem Computer

• Stage 5: Parallele Cloud-Ausführung (mehrere Geräte)

  • Die Ausführung wird in die Cloud verlagert, um parallel zu arbeiten
  • Für 3 Features werden gleichzeitig 3 Agenten eingesetzt; reviewt wird, sobald die PRs fertig sind
  • Agenten können Feedback überwachen und sogar proaktiv Korrekturvorschläge machen
  • Die Rolle besteht nicht mehr darin, individuell beizutragen, sondern eine Flotte von Agenten zu dirigieren

Leitfaden zum Level-up

• 0 → 1: Zusammenarbeit starten

  • Ein Tool auswählen (Cursor with Opus 4.5 oder Claude Code usw.) und täglich nutzen
  • Vor dem Schreiben von Code die AI bitten, den bestehenden Code zu erklären, um das Verständnis zu prüfen
  • Zuerst Boilerplate delegieren wie Tests, Konfigurationsdateien, wiederholte Funktionen usw.
  • Jede Zeile reviewen und dabei lernen
  • Zinseszinseffekt-Aufgabe: Prompts, die gut funktioniert haben, fortlaufend festhalten

• 1 → 2: Agenten Zugriff gewähren

  • In den agentischen Modus wechseln und dem Agenten Zugriff auf das Dateisystem geben
  • Mit engen Änderungen an einer einzelnen Datei mit einem einzigen Ziel beginnen, etwa „Füge Tests für diese Funktion hinzu“
  • Jede Aktion genehmigen oder ablehnen und dabei ein Gefühl für Vertrauen aufbauen
  • Das Diff reviewen und sich auf die geänderten Teile konzentrieren
  • Zinseszinseffekt-Aufgabe: Eine Datei CLAUDE.md erstellen und bei Fehlern des Agenten Notizen ergänzen

• 2 → 3: Dem Plan vertrauen (zentraler Wechsel)

  • Anforderungen, Vorgehensweise und Edge Cases als expliziten Plan aufschreiben
  • Der AI erlauben, die Codebase zu lesen, Muster zu finden und einen Ansatz vorzuschlagen
  • Nach dem Erstellen des Plans die Implementierung dem Agenten überlassen und weggehen, bis sie abgeschlossen ist
  • Auf PR-Ebene reviewen statt einzelne Schritte oder Codezeilen zu prüfen
  • Zinseszinseffekt-Aufgabe: Nach jeder Implementierung dokumentieren, was im Plan gefehlt hat

• 3 → 4: Ergebnisse statt Anweisungen geben

  • Ein Ergebnis (Outcome) vorgeben, etwa „E-Mail-Benachrichtigungen für neue Kommentare hinzufügen“, und den Implementierungsweg dem Agenten überlassen
  • Da der Agent die Codebase kennt und recherchiert, liegt auch die Planung in der Verantwortung des Agenten
  • Den Ansatz vor der Implementierung reviewen, um Fehlrichtungen früh zu stoppen
  • Zinseszinseffekt-Aufgabe: Eine Bibliothek gut funktionierender ergebnisorientierter Anweisungen aufbauen

• 4 → 5: Alles parallelisieren

  • Die Ausführung in die Cloud verlagern, um Engpässe auf der lokalen Maschine zu beseitigen
  • 3 Agenten gleichzeitig 3 Features zuweisen
  • Ideen, Bugs und Verbesserungen als Queue organisieren, die der Agent der Reihe nach abarbeitet
  • Aktivieren, dass der Agent User-Feedback überwacht und proaktiv Features vorschlägt
  • Zinseszinseffekt-Aufgabe: Dokumentieren, welche Aufgaben parallel ausführbar sind und welche von Natur aus seriell sind

Drei Fragen vor der Freigabe von AI-Ergebnissen

• „Was war hier die schwierigste Entscheidung?“ — Lenkt die AI dazu, heikle Stellen und Entscheidungspunkte offenzulegen
• „Welche Alternativen hast du verworfen und warum?“ — Prüft die berücksichtigten Optionen, um Fehlentscheidungen zu erkennen
• „Wobei bist du dir am wenigsten sicher?“ — Bringt das LLM dazu, eigene Schwächen einzugestehen, antwortet darauf aber nur, wenn man direkt danach fragt

Agent-native Architektur

• Entscheidend ist, dem Agenten die gleichen Fähigkeiten wie einem Entwickler zu geben
• Wenn ein Agent keine Tests ausführen kann, muss man sie selbst ausführen; wenn er keine Logs sehen kann, muss man selbst debuggen — jede nicht gewährte Fähigkeit wird zu manueller Arbeit

• Agent-native Checkliste

  • Entwicklungsumgebung: lokale Applikation starten, Test-Suite ausführen, Linter und Type Checker ausführen, DB-Migrationen, Seed-Daten für die Entwicklung
  • Git-Arbeiten: Branches erstellen, committen, auf Remote pushen, PR erstellen, PR-Kommentare lesen
  • Debugging: lokale/Produktions-Logs einsehen (read-only), UI-Screenshots, Netzwerk-Requests untersuchen, Zugriff auf Error Tracking (Sentry usw.)

• Schrittweise Einführung von Agent-Native

  • Level 1 (grundlegende Entwicklung): Dateizugriff, Tests ausführen, Git-Commit — grundlegendes Compound Engineering möglich
  • Level 2 (vollständig lokal): Zugriff auf Browser, lokale Logs, PR-Erstellung — Stage 3~4 möglich
  • Level 3 (Produktionssichtbarkeit): Produktions-Logs (read-only), Error Tracking, Monitoring-Dashboards — proaktives Debugging durch den Agenten möglich
  • Level 4 (vollständige Integration): Ticketsystem, Deployment-Fähigkeiten, Integration externer Services — Stage 5 möglich

• Agent-native Denkweise

  • Beim Bauen von Features: „Wie wird der Agent damit interagieren?“
  • Beim Debugging: „Was muss der Agent sehen können?“
  • Bei der Dokumentation: „Kann der Agent das verstehen?“

Skip Permissions

• Das Flag --dangerously-skip-permissions von Claude Code deaktiviert Berechtigungsanfragen, die bei jeder Aktion gestellt werden
• Der absichtlich beängstigende Name soll dazu anregen, vor der Nutzung sorgfältig nachzudenken

• Wann man es nutzen sollte

  • Empfohlen: wenn es ein gutes Planungs- und Review-System gibt, wenn in einer Sandbox gearbeitet wird, wenn Geschwindigkeit wichtig ist
  • Nicht empfohlen: während des Lernens (Berechtigungsanfragen helfen beim Verständnis), bei Arbeit an Produktionscode, wenn es keinen Rollback-Mechanismus gibt

• Sicherheitsmechanismen beim Überspringen von Berechtigungen

  • Git ist das Sicherheitsnetz: Agentenarbeit wird in Git aufgezeichnet und kann mit git reset --hard HEAD~1 wiederhergestellt werden
  • Tests fangen Fehler ab: Tests vor dem Merge ausführen
  • Review vor dem Merge: Während der Implementierung werden Berechtigungen übersprungen, aber das finale Review muss dennoch erfolgen
  • Risiko mit Worktree isolieren: Riskante Arbeiten in einem isolierten Verzeichnis ausprobieren

• Produktivitätsrechnung

  • Ohne Überspringen von Berechtigungen erscheint etwa alle 30 Sekunden ein Prompt; jedes Mal „y“ einzugeben kostet Konzentration
  • Mit übersprungenen Berechtigungen lässt sich der Flow-Zustand halten, wodurch Iterationen 5- bis 10-mal schneller werden; die Zeitersparnis übersteigt das gelegentliche Rollback-Risiko deutlich

Design-Workflow

• Baby-App-Ansatz

  • Ein Wegwerfprojekt (Baby App) erstellen, in dem man frei iterieren kann, ohne sich um Tests, Architektur oder Breaking Changes zu sorgen
  • Wenn das Design überzeugt, Farben, Abstände, Typografie und Komponentenmuster extrahieren und ins eigentliche Projekt übertragen

• UX-Erkundungsschleife

  • Mehrere Versionen erstellen, Click-throughs bauen und Usern funktionale Prototypen teilen, um Feedback zu sammeln
  • Anders als Figma-Mockups sind sie tatsächlich anklickbar
  • Prototypen dienen dem Lernen; anschließend wird mit einem sauberen Plan von Grund auf neu gebaut

• Zusammenarbeit mit Designern: Compound-Flow

  • Traditioneller Flow: Designer-Mockup → Interpretation durch Entwickler → wiederholte Korrekturen
  • Compound-Flow: Figma-Mockup des Designers → Figma-Link an /plan übergeben → AI implementiert → figma-design-sync-Agent prüft, ob Implementierung und Mockup übereinstimmen → Designer reviewt die Live-Version statt Screenshots

• Designgeschmack codifizieren

  • Einige Features gemeinsam mit dem Designer umsetzen und die dabei entdeckten Muster (bevorzugte Farben, Formular-Layouts usw.) in Skill-Dateien festhalten
  • So kann die AI Designs produzieren, die dem Geschmack des Designers entsprechen, auch ohne den Designer

• Design-Agenten

  • design-iterator: Analysiert Screenshots des aktuellen Designs, wiederholt Verbesserungen und verfeinert es schrittweise
  • figma-design-sync: Holt das Design aus Figma, vergleicht es mit der Implementierung und korrigiert Unterschiede automatisch
  • design-implementation-reviewer: Prüft, ob die Implementierung den Figma-Spezifikationen entspricht, und fängt visuelle Bugs ab, bevor User sie erreichen

Vibe Coding

• Ein Ansatz für Menschen, die nur das Ergebnis wollen, nicht den Code selbst: Product Manager, Designer, persönliche Projekte usw.
• Die Leiter überspringen und direkt zu Stage 4 gehen: beschreiben, was man will → der Agent übernimmt Planung, Code, Tests, Review und PR vollständig
• Geeignet für: persönliche Projekte, Prototypen, Experimente, die Frage „Ist das möglich?“, interne Tools, UX-Erkundung
• Nicht geeignet für: Produktionssysteme mit Usern, Code, den andere warten müssen, sicherheitssensible Apps, performancekritische Systeme

• Das Vibe-Coding-Paradox

  • Vibe Coding kann paradoxerweise sogar die Fähigkeit zur Planung verbessern
  • Wenn man noch nicht weiß, was man bauen will, erstellt man einen Prototypen, sammelt User-Feedback und löscht dann alles, um mit einem sauberen Plan neu zu beginnen
  • Optimale Aufteilung: mit Vibe Coding entdecken, nach Spezifikation bauen — bei der finalen Implementierung gewinnt immer die Spezifikation

Teamzusammenarbeit

• Neue Teamdynamiken

  • Traditionell: Person A schreibt Code → Person B reviewt → Diskussion über PR-Kommentare → Genehmigung und Merge
  • Compound: Person A erstellt einen Plan → AI implementiert → ein AI-Agent reviewt → Person B reviewt das AI-Review → Merge nach menschlicher Freigabe

• Teamstandards

  • Planfreigabe: Schweigen ist keine Zustimmung, daher ist vor der Implementierung ein explizites Sign-off erforderlich
  • PR-Eigentümerschaft: Unabhängig davon, wer den Code geschrieben hat, gehört der PR der Person, die die Arbeit begonnen hat; sie trägt die Verantwortung für Planqualität, Reviews, Korrekturen und die Auswirkungen nach dem Merge
  • Fokus des menschlichen Reviews: Bei PRs, die bereits von einem AI-Review-Agenten analysiert wurden, konzentrieren sich Menschen nicht auf Syntaxfehler, Sicherheit, Performance oder Stil, sondern auf die Absicht (Intent) — „Entspricht es dem Vereinbarten?“, „Ist der Ansatz sinnvoll?“, „Gibt es Probleme in der Business-Logik?“

• Kommunikationsmuster

  • Asynchron als Standard: Um Pläne zu erstellen, zu reviewen und freizugeben, sind keine Meetings nötig; „Ich habe ein Planungsdokument erstellt, bitte kommentiert es heute noch.“
  • Explizite Übergaben: Einschließlich Status, erledigter Arbeit, verbleibender Aufgaben, Kontext und Vorgehen zur Fortsetzung

• Skalierungsmuster

  • Klare Eigentümerschaft + asynchrone Updates: Für jede Hauptfunktion gibt es eine verantwortliche Person, die plant, überwacht, reviewt, merged und das Team informiert
  • Feature Flags + kleine PRs: Je schneller alle deployen, desto häufiger werden Merge-Konflikte; daher in kleinen Einheiten deployen, häufig in Main mergen und Konflikte sofort lösen
  • Compound-Dokumente = fehlendes implizites Wissen (tribal knowledge): Nicht „Frag Sarah, sie kennt sich mit Auth gut aus“, sondern Sarah führt /compound aus und dokumentiert die Lösung, sodass jede Person danach suchen kann

Nutzerforschung

• Die Lücke zwischen Research und Entwicklung

  • Traditionell: Forschende führen Interviews → schreiben einen Bericht → der Bericht bleibt in Google Drive liegen → Entwickler sehen ihn nicht → Features spiegeln die Nutzerbedürfnisse nicht wider
  • Compound: Research erzeugt strukturierte Insights → die Insights werden als Planungskontext genutzt → AI bezieht sich bei der Planung auf die Insights → Nutzungsdaten validieren die Insights → Insights akkumulieren sich mit Zinseszinseffekt

• Research strukturieren

  • Rohnotizen aus Interviews werden in strukturiertes Markdown umgewandelt, damit AI sie nutzen kann: mit Informationen zu Teilnehmenden, zentralen Insights, Zitaten, Implikationen und Vertrauensgrad (n/5 Teilnehmende)

• Persona-Dokumente

  • Erstellung von Persona-Dokumenten mit Zielen, Frustrationen und Zitaten, auf die AI verweisen kann

• Research-basierte Planung

  • Beim Ausführen von /workflows:plan wird Research-Kontext eingebunden (Interview-Ergebnisse, Persona-Muster, aktuelle Pain Points), sodass Research-Insights direkt in Features einfließen

Extraktion von Datenmustern

• Die Art und Weise, wie Nutzer das Produkt verwenden, ist ein Hinweis darauf, was gebaut werden sollte

• Musterarten, auf die geachtet werden sollte

  • Übernutzungsmuster: Features, die viel häufiger als erwartet genutzt werden, wiederholte Besuche derselben Seite
  • Schwierigkeitsmuster: Hohe Verweildauer auf einfachen Seiten, wiederholte Versuche derselben Aktion, Schleifen aus Fehler → erneuter Versuch → Fehler
  • Umgehungsmuster: Daten an einer Stelle exportieren und an anderer Stelle wieder importieren, Copy-and-paste zwischen Bildschirmen, mehrere Tabs gleichzeitig offen halten, um Vergleiche anzustellen
  • Abbruchmuster: Abbrüche in Flows, begonnene, aber nicht abgeschlossene Features

• Vom Muster zum Feature

  • Nutzer kopieren Daten 50-mal pro Woche zwischen Tabellen per Copy-and-paste → als Feature ein „Mit Tabelle B synchronisieren“-Button
  • Nutzer erstellen „Vorlagen“-Projekte und duplizieren sie → als Feature erstklassige Template-Unterstützung

Copywriting

• Copy in die Planung aufnehmen

  • Die meisten Teams behandeln Copy als nachrangig und füllen sie erst nach dem Bau eines Features aus, aber Copy ist Teil der User Experience
  • Wenn bereits in der Planungsphase nutzerseitige Copy wie E-Mail-Betreffzeilen, Erfolgsmeldungen und Fehlermeldungen einbezogen wird, ist die Copy bei der AI-Implementierung bereits vorhanden

• Voice codifizieren

  • Prinzipien (wie ein Mensch sprechen, Fehlermeldungen sollen hilfreich sein, kurze Sätze, klare Wörter) und zu vermeidende Wörter (Invalid → didn't work, Error → erklären, was passiert ist usw.) werden als Skill-Datei festgehalten

• Copy-Review

  • Dem Prozess /workflows:review wird ein Copy-Review hinzugefügt: ein copy-reviewer-Agent, der anhand von vier Kriterien prüft: Klarheit, Hilfreichkeit, Ton und Konsistenz

Produktmarketing

• Compound-Flow

  • Ein Engineer erstellt einen Plan mit dem Produkt-Wertversprechen → AI implementiert das Feature → AI erzeugt aus dem Plan Release Notes → aus den Release Notes werden Social Posts erzeugt → mit Playwright werden automatisch Screenshots aufgenommen → der Engineer reviewt alles und veröffentlicht es gemeinsam
  • Da alles an einem Ort fließt, sind keine Übergaben nötig und es entstehen keine Lücken

• Release-Notes-Erstellung

  • Da AI den Plan, die Code-Änderungen und die Tests vollständig kennt, kann sie präzise erfassen, was genau gebaut wurde
  • Nutzermehrwert zuerst, ein konkretes Beispiel, Erwähnung von Breaking Changes, unter 200 Wörtern

• Changelog-Erstellung

  • Mit dem Befehl /changelog werden die jüngsten Merges nach Main geprüft und aus jedem Plan/PR ein ansprechendes Changelog erstellt

• Automatische Screenshots

  • Mit Playwright werden Screenshots für Marketingzwecke automatisch aufgenommen, Engineering muss nicht mehr um Screenshots gebeten werden, und das Problem veralteter Screenshots wird beseitigt