Dünne Slices verhindern, dass /sdd-flow meine Kapazität sprengt

Ein riesiger Scheißhaufen

Ich dachte, ich hätte spec-driven development mit Claude Code gemeistert und wäre im Grunde zu einem agentischen Coding-Superhelden geworden. Das war, bis mein Ehrgeiz die Kapazität überstieg. Agentisches Coding ist unglaublich mächtig geworden, aber es erfordert nach wie vor, dass ein Entwickler engmaschig die Aufsicht behält — besonders in komplizierteren Szenarien.

Vor ungefähr sechs Monaten habe ich dieses SDD-Development-Workflow-Plugin gebaut, um einen Research-Plan-Implement-Zyklus auf Softwareprojekte anzuwenden. Aus meiner Erfahrung damit lernte ich, es weiter zu verfeinern — ich fügte zusätzliche Review-Phasen und Schritte hinzu, die Unvollkommenheiten automatisch korrigierten. Es funktionierte so gut, dass ich dachte, ich könnte den Prozess noch stärker automatisieren, was mich dazu brachte, den /sdd-flow Skill zu erstellen. Damit konnte ich Features einfach auf einen Schlag durchdrücken (ich verwende "auf einen Schlag" hier etwas locker, weil es durchaus Klärungsschritte und Reviews gibt). Das funktionierte gut, bis meine Projekte komplizierter wurden und "auf einen Schlag" bedeutete, zu viele Anforderungen und Erwartungen auf einmal zu handhaben. Kurz gesagt: Ich hatte den Kool-Aid getrunken und geglaubt, dass KI liefern kann.

Die Tatsache, dass ich mehrere Projekte parallel entwickelte, hat das Durcheinander, in dem ich mich befand, nur noch verschlimmert. Ich wurde ein bisschen überwältigt, und das führte dazu, dass ich vernünftige Praktiken missachtete und ungeduldig und unachtsam wurde. Ich wollte ehrlich gesagt einfach nur an einen Endstand kommen. Ich wurde irrational auf das Liefern fixiert. Und ich habe definitiv geliefert. Nach drei Wochen Entwicklung und einer Woche Debuggen und dem Versuch, das Projekt wieder auf Kurs zu bringen, habe ich eine wichtige Lektion geliefert. Ich habe die Grenzen des agentischen Codings und die Fähigkeiten von KI-Modellen neu entdeckt — zusammen mit meinen eigenen menschlichen Grenzen.

Dünnere Slices

Also trat ich ein paar Schritte zurück und bewertete meinen Entwicklungsprozess — sowohl die Teile, die ich persönlich steuerte, als auch die Teile, die der Agent übernahm.

Das Erste, was es zu beheben galt, war, wie Coding-Agenten typischerweise eine mehrschichtige App aufbauen. Sie zaubern eine ganze Schicht hervor, bevor sie zur nächsten übergehen. Nehmen wir eine App mit einem Frontend und einem Backend. Der Agent liefert das gesamte Frontend — normalerweise eine breite Palette an Funktionalität — und geht dann zum Backend über. Man kann mehrere Zyklen durchlaufen, bevor irgendetwas davon end-to-end testbar ist.

Das nächste Problem war, ironischerweise, dass ich schlechtere Ergebnisse erzielte, obwohl die App gründlich mit Unit- und End-to-End-Tests abgedeckt war. Weil ich mich zu sehr darauf als Qualitätssicherung verließ, übersprang ich das persönliche Review. Unter Druck nahm ich den einfachen Weg und tippte einfach den nächsten Prompt ein, würfelte und spielte weiter. Das war dumm.

Auf der Suche nach einer Lösung, um besser zu beeinflussen, wie ein Coding-Agent liefert, und um mein eigenes Verhalten zu korrigieren, dachte ich darüber nach, wie ich ein solches Projekt normalerweise entwickeln würde, wenn ich die Arbeit "auf die alte Art" machen würde — vor GenAI. Bei einer funktionsreichen Anwendung oder sogar einem komplizierten Feature würde man sich darauf konzentrieren, mit einem ganz spezifischen Slice erfolgreich zu sein. Man würde ihn von Anfang bis Ende durchentwickeln, alle verschiedenen Schichten vom Backend bis zum Frontend verbinden, sodass es so schnell wie möglich etwas gibt, das ein menschlicher Nutzer testen kann.

Dieser Ansatz der vertikalen Slice-Entwicklung, auf Coding-Agenten angewendet, würde:

1. Den Agenten zwingen, sich stärker zu fokussieren.
2. Es mir leichter machen, das Gelieferte zu testen und zu reviewen.
3. Mir helfen, besser nachzuverfolgen, was geliefert wird, und Abweichungen schneller zu korrigieren.

Der letzte Punkt ist wichtig, weil er auf ein weiteres Verhalten zurückverweist, das ich angehen musste. Ich war so auf Geschwindigkeit fokussiert und durch frühere Erfolge so ermutigt, dass ich zu viel und zu schnell entwickelte. Ich musste langsamer werden.

In Slices zu entwickeln macht es mir leichter, die Arbeit zu verdauen und bei gründlicheren Reviews zu bleiben. Statt eines Research-→-Spec-→-Implement-Zyklus pro Feature wird das Feature vorab in vertikale Slices zerlegt. Du behältst den Geschwindigkeitsvorteil innerhalb eines Zyklus (keine manuellen Übergaben zwischen Phasen), gewinnst aber den Oversight-Vorteil zurück. Du reviewst etwas, das klein genug ist, um es wirklich zu verstehen und sich die Zeit dafür zu nehmen. Das passt viel besser dazu, mehrere Projekte parallel mit Coding-Agenten zu entwickeln.

Softwareentwicklung ist persönlich. Das ist es, was zu meinem Stil, meinen Einschränkungen und meiner Erfahrung passt.

Wieder in Kontrolle

Also wurden von den drei Projekten, die ich parallel entwickelte, tatsächlich zwei verschickt. Das dritte, komplizierteste Projekt — das, das dieses ganze Überdenken ausgelöst hat — habe ich die Toilette runtergespült. Es war so ein Chaos und ich hatte so wenig Vertrauen darin, dass ein Neuanfang sinnvoller war. Außerdem konnte ich damit beginnen, alles, was ich hier besprochen habe, auszutesten.

Ich bin sehr zufrieden mit den Ergebnissen — sowohl mit dem Verhalten des Agenten als auch mit dem, wie ich selbst gezwungen bin, mich zu verhalten. Die Anwendung hat jetzt einen fokussierteren Satz an anfänglichen Features. Ich habe einen besseren Überblick darüber, was ich tue und wie ich sie weiterentwickeln kann.

Dieses Gefühl der Kontrolle hat mir erlaubt, wieder an zwei anderen Projekten parallel zu arbeiten. Drei scheint meine magische Zahl zu sein. Aber ich führe sie jetzt in einem vernünftigeren, gesünderen Rhythmus.

Herauszoomen — Die größere Implikation

Coding-Agenten sind keine fertigen Produkte, die du einfach konsumierst. Sie können für viele Szenarien out of the box funktionieren, aber gleichzeitig müssen sie für viele kompliziertere Szenarien angepasst und auf deine Entwicklungsweise zugeschnitten werden. Du musst an einen Punkt kommen, an dem du verstehst, wie die Dinge für dich und für einen Agenten während eines Entwicklungszyklus fließen.

Es gibt einige sehr lautstarke Menschen, die teilen, was für sie funktioniert — mich eingeschlossen. Es ist wichtig, eine Vielzahl von Standpunkten und Erfahrungen zu berücksichtigen. Das hilft, deine eigenen persönlichen Versuche zu nähren, aber letztendlich kommt es darauf an, dass du all diese Informationen synthetisierst und herausfindest, was für dich funktioniert, zu deinem Stil passt und mit deinen Prozessen übereinstimmt. Das erfordert Investition und Experimentieren.

Dieser Prozess, die richtige Ausrichtung zu finden, beinhaltet ein bisschen informelle "Vibe"-Evaluierungen. Um das Meiste aus diesen Tools herauszuholen und den größten Hebel zu haben, braucht man etwas Wissenschaftlicheres. Glücklicherweise gab es in letzter Zeit einige neue Releases, die es leicht machen, ordentliche Evals durchzuführen und umfassendes Tracing zu erfassen, um zu identifizieren, wo dein Coding-Agent versagt und wo er verbessert werden kann. Mehr dazu in einem kommenden Post.

In der Zwischenzeit: Denk daran, dass ein agentisches Coding-Tool als Vorschlaghammer beginnt. Passe den Griff deinen Händen an. Mach einen Schraubenzieher daraus, wenn der Job Präzision erfordert. Form diese wunderbare und beängstigende Technologie weiterhin auf deine eigenen Ziele hin.

Den Slice-Modus verwenden

Der Skill benötigt ein Flag, um die Entwicklung in vertikalen Slices zu starten: /sdd-flow delivery_mode: per-slice

Dieser Skill gehört zum agent-engineering Plugin.