10 KiB
8. Vertikale Slices und Komplexität
„Mach Billing komplett: Schema, Services, REST, UI, Admin, Docs.“ Nach einer Stunde: unreviewbarer Diff, DoD erst am Ende denkbar. Agents scheitern seltener an zu wenig Tokens als an zu viel gleichzeitiger Komplexität.
These 6: Haltet die Komplexität der Aufgaben so gering wie möglich. Vertikale Slices sind der Schlüssel.
8.1 Horizontal vs. vertikal
{width=90%}
Horizontaler Schnitt (häufig problematisch)
Der horizontale Schnitt klingt produktiv: „Mach die komplette Billing-Schicht: DB-Schema, Repositories, Services, REST, UI, Admin, Docs, Metriken.“ Viele Dateien, viele Fehlermodi, DoD erst am Ende prüfbar, Diff unreviewbar — und der Context muss „alles gleichzeitig“ halten. Reviewer und Agent teilen dasselbe Problem: Niemand sieht früh, ob der Kern funktioniert.
Vertikaler Slice (empfohlen)
Der vertikale Slice klingt bescheidener: „Slice 1: POST /invoices erzeugt eine Invoice in DB inkl. Happy-Path-Test. Keine UI. Keine Payments.“ End-to-End dünn, aber fertig. DoD früh grün. Lernen aus Slice 1 fließt in Slice 2. Context bleibt im Sweet Spot.
Nicht jeder Slice braucht UI. „Vertikal“ heißt durch die nötigen Schichten für einen nutzbaren Outcome, nicht „immer Frontend“. Manchmal ist der dünnste Pfad nur API + Persistenz — und das ist ein vollwertiger Slice. Wer „vertikal“ mit „muss UI haben“ verwechselt, schneidet künstlich auf und holt Komplexität zurück.
8.2 Was Komplexität für Agents teuer macht
Zwei Tickets, ähnliche Zeilenzahl: Ticket A ist ein Rename mit grüner Suite — der Agent liefert in einer Session. Ticket B ist „klein“, aber drei unklare API-Grenzen und flaky CI — nach zwei Stunden Diff-Matsch und keiner DoD, die je grün wurde. Die Tabelle sortiert, warum B teurer war.
| Faktor | Wirkung auf den Agent |
|---|---|
| Anzahl paralleler Goals | Zielkonflikte, Lost-in-the-Middle |
| Unbekannte Codepfade | Mehr Explore-Dumps |
| API-Verträge + Migration | Risiko + längere Plans |
| Flaky / langsame Tests | Verifizierbarkeit leidet |
| Inkonsistente Patterns im Repo | Modell mischt Stile |
| Exotischer Stack | Weniger zuverlässiger Agent-Output / mehr Korrektur (These 7) |
Komplexität ist nicht nur „LOC“. Interaktion × Unsicherheit × Nebenbedingungen zählt. Ein kleines Feature mit drei unklaren Grenzen und flaky CI kann teurer sein als ein großer, aber klarer Rename mit grüner Suite.
8.3 Komplexitätsbudget
Gib jedem Agent-Task ein Budget — explizit oder als Team-Default. Ein brauchbares Standard-Slice-Budget sieht so aus:
{width=90%}
- 1 primäres Outcome
- ≤ ~5–10 Kern-Dateien ideal (Richtwert, kein Dogma)
- 1–2 Verify-Kommandos
- Keine neue Infrastruktur, außer der Slice ist Infrastruktur
- Session-Ziel: im Context-Sweet-Spot bleiben
Sprengt der Task das Budget → schneiden, nicht „länger chatten“. Mehr Turns ohne schmaleren Scope füllen nur das Window (Kap. 3–4). Das Budget ist kein Dogma gegen große Epics — es ist die Einheit, in der Epics geliefert werden. Wenn die Nadel im Rot steht, ist der nächste Hebel Scope, nicht „stärkeres Modell“.
8.4 Wie man schneidet
Vier Praktiken decken die meisten Fälle ab. Welche passt, hängt vom Risiko ab — nicht vom Ticket-Titel.
1. Walking Skeleton
Zuerst der dünnste Pfad, der echt läuft (Request → Domain → Persistenz → Response), dann die Substanz. Du bekommst früh ein Orakel und einen Diff, den man reviewen kann. Alles andere ist Veredelung auf grünem Fundament.
2. Riskiest assumption first (manchmal)
Wenn das Risiko die externe API ist: erst Adapter + Contract-Test, dann UI-Politur. Sonst veredelst du eine Annahme, die später platzt — und der schöne Button sitzt auf Sand.
3. Happy Path → Edge Cases
Slice 1 Happy Path grün. Slice 2 Validierung und Fehler. Nicht beides in einem Prompt vermischen, wenn es den Diff verdoppelt und die DoD unklar macht. Edge Cases in denselben Context zu quetschen fühlt sich effizient an und endet oft in Fix-Kaskaden.
4. Read-only Explore-Slice
Manchmal ist „Map the payment flow and write HANDOFF“ der erste Slice — ohne Code-Änderung. Das ist valide und spart Execute-Müll. Explore aus Kap. 7 darf ein eigenes Lieferobjekt sein; nicht jeder Slice muss Code ändern.
8.5 Beispiel: Feature in drei Slices
Epic: Nutzer können Rechnungen als PDF exportieren.
| Slice | Outcome | DoD (Auszug) |
|---|---|---|
| 1 | GET /invoices/:id/pdf Happy Path |
Integrationstest 200 + Content-Type; Auth analog bestehend |
| 2 | Fehlerpfade (404, Auth-Kante) | Integrationstests Fehlercodes |
| 3 | Button in Detail-UI | E2E oder Component-Test; nur dieser Button |
Default ist der dünnste nutzbare Pfad (Walking Skeleton, 8.4). Ein Renderer/Adapter-Schnitt mit Contract-Test ohne HTTP lohnt nur, wenn Library oder Layout die riskanteste Annahme ist: dann als gekennzeichneter Minipfad vor Slice 1, nicht als Default-Slice-1.
Avoid that: Ein Prompt „PDF export complete with UI and email and storage and virus scan“. Spätere Slices gehören in die Ausschlüsse von Slice 1 — nicht in denselben Context als „optional mitmachen, wenn du Zeit hast“. Was nicht ausgeschlossen ist, wird der Agent oft „freundlich“ mitziehen — und der Diff explodiert.
8.6 Aufgabenformulierung und Slices
Vertikale Slices und Kapitel 14 greifen ineinander: Ziel = Outcome des einen Slices; Ausschlüsse = spätere Slices explizit out of scope; DoD = für diesen Slice prüfbar. Zu restriktives Micro-Management innerhalb des Slices bleibt falsch — der Agent soll den Slice lösen, nicht 40 Tastenanschläge nachtippen. Der Schnitt steuert Komplexität; die Formulierung steuert Freiheit innerhalb des Schnitts.
8.7 Wann größerer Scope ok ist
Größerer Scope ist nicht verboten — er braucht Voraussetzungen: erfahrener Agent-Workflow, exzellente Tests, klares Pattern im Repo; mechanische Migration (Rename) mit starker Testbasis; Modell und Stack extrem „in distribution“ (These 7). Fehlt eine dieser Stützen, frisst der große Scope zuerst den Context, dann die Reviewbarkeit.
Selbst dann: lieber serielle Slices in einer Session-Serie als ein monströser Context. Größe der Arbeit ≠ Größe des Context-Fensters. Ein Epic kann groß sein; der Context pro Session sollte es selten sein.
8.8 Anti-Patterns
| Anti-Pattern | Problem | Fix |
|---|---|---|
| Big-Bang-Agent | Unreviewbar | Slices |
| „Nur schnell alles“ | Rot + Nacharbeit | Budget |
| Horizontale Schichten-Tickets | Lange Integration rot | Vertikal schneiden |
| Slice ohne DoD | Nie fertig | Kap. 10 |
| Slice-Überreste im Context | Drift | Handoff/neue Session |
Der letzte Punkt wird oft unterschätzt: Nach Slice 1 den Context nicht „mitlaufen“ lassen, bis Slice 3 im selben Matsch endet. Handoff oder neue Session ist Teil des Schnitts.
8.9 Schnitt-Workshop (15 Minuten)
Stand-up: „Billing PDF export — Agent, leg los.“ Zehn Minuten später: Schema, UI-Button, E-Mail und Virus-Scan im selben Prompt. Der Workshop darunter ist die Gegenprobe — fünfzehn Minuten vor dem ersten Agent-Turn.
{width=90%}
Für jedes Epic-Ticket:
- Outcome des Epics in einem Satz
- Liste der Schichten, die berührt werden (UI, API, DB, Jobs, …)
- Dünnster Pfad, der echten Nutzen liefert
- Slice 1 = dieser Pfad mit DoD
- Rest als nummerierte Slices + jeweils Ausschlüsse im Prompt von Slice 1
Wenn Slice 1 nicht in einer Session mit Sweet-Spot-Context schaffbar scheint: noch dünner schneiden. Fünfzehn Minuten Workshop sparen oft Stunden Agent-Ping-Pong.
8.10 Abhängigkeit von Tests und Observability
Vertikale Slices brauchen Orakel. Ohne Tests am Schnitt wird „fertig“ politisch — und der autonome Loop aus Kap. 10 hat nichts zu messen.
Priorität:
- Slice 0: Test/Repro/Contract wo nötig
- Slice 1: Verhalten
- Später: Telemetrie, Docs, Polish
Agents multiplizieren gute Testpyramiden — und multiplizieren auch deren Abwesenheit. Fehlen Orakel und Hygiene im ganzen Repo, ist das ein Low-Maturity-Regime — Reihenfolge und Stop-Regeln: Kapitel 21.
8.11 Slices in Ticketsystemen
Schlechte Aufteilung: „Backend-Task“, „Frontend-Task“, „QA-Task“.
Bessere Aufteilung: „Slice: User can download invoice PDF (API+auth+test)“, dann „Slice: Button + empty state“.
Der Agent bekommt nutzbare Inkremente, nicht Organisations-Silos. Tickets, die nur Abteilungsgrenzen spiegeln, erzwingen horizontale Schnitte — und dann wundert man sich über die Agent-Ergebnisse.
Key Takeaways
- Vertikal = dünner nutzbarer Outcome, nicht „immer inkl. UI“.
- Budget sprengen → schneiden, nicht länger chatten.
- Spätere Slices gehören in die Ausschlüsse.
- Ohne Orakel ist der Slice Theater (Kap. 10).
Praktische nächste Schritte
- Nächstes großes Agent-Ticket in 2–4 Slices mit je eigener DoD zerlegen.
- Spätere Slices unter „Ausschlüsse“ des ersten Prompts schreiben.
- Team-Default-Budget (Dateien/Goals/Verify) festlegen.
- Weiter: Kapitel 9, dann Kapitel 10.