Software-Entwicklung mit KI-Agenten: Die 5-Skill-Pipeline, die ich nutze

Ich habe einen Sonntag mit einem Laravel-Feature verloren, das vier Stunden hätte dauern sollen.

Nicht weil der Code schwer war. Der Code war einfach. Ich habe den Sonntag verloren, weil ich Claude Code schreiben ließ, bevor ich die Fragen beantwortet hatte, die das Design hätten prägen sollen. Mitten im zweiten Prompt wurde mir klar, dass der Agent eine Eins-zu-viele-Beziehung angenommen hatte, die eine Viele-zu-viele-Beziehung sein musste, dreißig Tests gegen den falschen Vertrag generiert hatte und sich nun selbstbewusst immer tiefer in die falsche Abstraktion hineinrefaktorisierte. Bis zum Abendessen hatte ich den Branch auf seinen ersten Commit zurückgesetzt und eine leere Datei geöffnet.

Das ist der Fehlermodus der Software-Entwicklung mit KI-Agenten, den niemand auf die Marketingseite schreibt. Der Agent schreibt bereitwillig alles, was du verlangst. Er wird dich nicht davon abhalten, das Falsche zu verlangen. Und weil jeder neue Chat ohne Erinnerung an den letzten beginnt, wartet derselbe Fehler am Montagmorgen wieder auf dich — es sei denn, etwas in deinem Workflow erzwingt die Entscheidungen, bevor der Code beginnt.

Ein paar Wochen nach diesem verlorenen Sonntag sah ich einen Ingenieur namens John Lindquist genau die Pipeline durchgehen, die er verwendet, um dies zu vermeiden — aufgebaut auf fünf eng abgegrenzten Skills, die in einer festen Reihenfolge laufen. Es machte Klick. Ich baute meinen eigenen Workflow um dieselben fünf Skills herum neu auf, testete ihn an drei Projekten im April, und der Unterschied war die Art von Unterschied, über die ich vor sechs Monaten gelacht hätte, wenn mir jemand davon erzählt hätte. Weniger Code umgeschrieben. Mehr Features ausgeliefert. Weniger verlorene Sonntage.

Das ist die Pipeline. Fünf Skills, die Reihenfolge, in der sie laufen, was jeder von ihnen tatsächlich unter der Haube macht, und die Teile, die in den Demos nicht auftauchen.

Das eine mentale Modell, das verändert, wie du Agenten einsetzt

Zuerst das mentale Modell, dann die Skills. Überspringe diesen Teil, und der Rest des Artikels sind nur Befehle.

Der Agent ist kein Junior-Ingenieur, der im nächsten Sprint besser wird. Der Agent ist ein gedächtnisloser Experte — ein Senior-Ingenieur ohne Erinnerung an gestern, ohne Wissen über deine Codebasis, das nicht ins aktuelle Kontextfenster eingefügt wurde, und ohne die Fähigkeit, in drei Tagen eine Nachfrage zu stellen. Jede Sitzung ist der erste Arbeitstag.

Das klingt nach einem Nachteil. Tatsächlich ist es die Einschränkung, die die Pipeline funktionieren lässt. Weil der Agent kein Gedächtnis hat, muss jede Entscheidung explizit gemacht werden. Jede Annahme muss aufgedeckt werden. Jede Anforderung muss irgendwo dauerhaft festgehalten werden, in einer Datei, die die nächste Sitzung lesen kann. Die Pipeline, die ich gleich durchgehe, ist im Grunde nur ein System zur Erzeugung dieser dauerhaften Artefakte in der richtigen Reihenfolge.

Dahinter steckt eine tiefere Idee aus Frederick P. Brooks' The Design of Design. Brooks beschreibt Ingenieurwesen als die Erkundung eines Entwurfsbaums — jede Entscheidung verzweigt sich in weitere Entscheidungen, und man versteht den Entwurf erst wirklich, wenn man die Äste weit genug verfolgt hat, um zu sehen, welche in Sackgassen enden und welche sich öffnen. Die meisten gescheiterten Softwareprojekte entstehen, weil der Baum zu früh abgeschnitten wurde. Man hat sich auf ein Blatt festgelegt, bevor man den Stamm verstanden hat.

Ein gedächtnisloser Agent schneidet den Baum an der allerersten Verzweigung ab, es sei denn, etwas zwingt ihn, weiterzugehen. Dieses Etwas ist der erste Skill in der Pipeline.

Skill 1: Grill Me — Befrage die Idee, bevor du codest

Der Grill-Me-Skill ist das kontraintuitivste Element auf der Liste. Man würde denken, der erste Schritt mit einem KI-Agenten sei: gib einen Prompt ein und schau zu, wie er Code schreibt. Grill Me macht das Gegenteil. Du gibst dem Agenten eine grobe Idee — drei Sätze, einen Absatz, einen halb geformten Feature-Wunsch — und er interviewt dich.

Das Interview ist um Brooks' Entwurfsbaum herum strukturiert. Der Agent identifiziert jeden Entscheidungspunkt, den deine Idee impliziert, aber nicht auflöst, und geht sie einen nach dem anderen mit dir durch. Für ein kleines Feature stellt er vielleicht sechzehn Fragen. Für etwas Komplexes — ein Multi-Tenant-Abrechnungssystem, eine Content-Pipeline mit verzweigten Workflows, eine neue Authentifizierungsoberfläche — habe ich ihn dreißig bis fünfzig Fragen generieren sehen, bevor er zufrieden war. Die meisten dieser Fragen sind solche, die ich mir selbst hätte stellen sollen und nicht gestellt habe.

So sah eine Grill-Me-Sitzung bei einem realen Projekt letzten Monat aus. Ich sagte ihm, ich wolle „Team-Arbeitsbereiche" zu einem SaaS-Dashboard hinzufügen. Er kam zurück mit:

1. Gehört ein Arbeitsbereich einem einzelnen Benutzer oder einem Team?
2. Wenn einem Team, kann ein Benutzer gleichzeitig mehreren Teams angehören?
3. Erben Arbeitsbereiche Berechtigungen von der übergeordneten Organisation oder definieren sie ihre eigenen?
4. Was passiert mit den Ressourcen eines Arbeitsbereichs, wenn dessen Eigentümer die Organisation verlässt?
5. Wird die Abrechnung des Arbeitsbereichs in die Rechnung der Organisation aufgenommen oder separat abgerechnet?

Ich war im Begriff, Claude mit „füge Team-Arbeitsbereiche zum Dashboard hinzu" zu prompten. Hätte ich das getan, hätte der Agent fünf versteckte Annahmen für mich getroffen, Code gegen diese Annahmen geschrieben, und ich hätte die Abweichung bei Frage 4 entdeckt — in der Produktion, wenn jemand ein Team verließ. Der Grill machte die Annahmen sichtbar, bevor eine einzige Codezeile existierte.

Das Muster ist jedes Mal dasselbe. Die meisten Fragen fühlen sich im Nachhinein offensichtlich an, und genau deshalb lohnt es sich, sie ans Licht zu bringen — Fragen, die im Nachhinein offensichtlich sind, sind die Fragen, die wir überspringen, weil unser Gehirn uns sagt, dass wir die Antwort bereits kennen. Der Agent hat diesen Bias nicht. Er geht einfach den Baum durch.

Man kann die Ausgabe als Transkript betrachten, aber das Transkript ist nicht das Ergebnis. Das Ergebnis ist das geteilte Verständnis — ein Zustand, in dem du und der Agent sich über jede folgenreiche Entscheidung einig sind, die das Feature impliziert. Sobald du das hast, übernimmt der nächste Skill.

Skill 2: Schreibe ein PRD — Fixiere geteiltes Verständnis in dauerhafter Form

Die Interview-Ausgabe stirbt in dem Moment, in dem das Chat-Fenster geschlossen wird. Das ist die Gedächtnislos-Agenten-Steuer, die ich vorhin erwähnt habe. Der Schreibe-ein-PRD-Skill löst dieses Problem in einem einzigen Zug: Er konvertiert das Grill-Me-Transkript in ein Product Requirements Document, formatiert für einen KI-Leser, und reicht es als Issue im Projekt-Tracker ein — meist als GitHub Issue.

Drei Dinge fallen an der Struktur dieses Skills auf.

Erstens: Er ist für den nächsten Agenten geschrieben, nicht für dich. Ein traditionelles PRD liest sich wie ein Verkaufsdokument. Dieses PRD liest sich wie eine Funktionssignatur mit Prosa. Jede Anforderung ist testbar. Jede Einschränkung ist explizit. Jede Entwurfsentscheidung aus dem Grill ist mit der Begründung dahinter festgehalten. Die nächste Sitzung hat keinen Zugriff auf deine Erinnerung, warum du Viele-zu-viele statt Eins-zu-viele gewählt hast — aber sie hat Zugriff auf das PRD, und das PRD wird es ihr sagen.

Zweitens: Es lebt im Issue-Tracker. Nicht in einem docs/-Ordner, nicht in Notion, nicht in einen Chat eingefügt. Der Grund ist wichtig: Der Issue-Tracker ist der Ort, an dem jedes andere Tool — Menschen, Agenten, CI, nachgelagerte Skills — nach der Quelle der Wahrheit für dieses Feature suchen wird. Das PRD irgendwo anders abzulegen, erzeugt eine Abspaltung in der Entwurfsgeschichte, die dich in sechs Wochen verfolgen wird.

Drittens: Es legt dich fest. Sobald das PRD auf GitHub steht, hast du ein Gespräch in ein Artefakt verwandelt. Dein zukünftiges Ich kann es nachlesen. Zukünftige-Claude kann es nachlesen. Ein Teamkollege, der nächste Woche zum Projekt stößt, kann es nachlesen. Das Gespräch mit seinen verzweigten Abschweifungen und halb geformten Gedanken ist weg. Was überlebt, ist der aufgelöste Entwurf.

Früher tat ich PRDs als etwas ab, das Produktmanager schrieben, um ihr Gehalt zu rechtfertigen. Als ich sah, wie ein gedächtnisloser Agent durch ein komplexes Feature flog, mit einem knappen einseitigen PRD als einzigem Kontext-Input, änderte sich diese Meinung vollständig. Das PRD ist keine Bürokratie. Es ist das Arbeitsgedächtnis des Agenten zwischen Sitzungen.

Skill 3: PRD zu Issues — Vertikale Schnitte statt horizontaler Schichten

Hier ist der Punkt, an dem die meisten KI-Workflows auseinanderfallen. Du hast ein PRD. Du gibst es dem Agenten. Der Agent beschließt, „das Feature zu implementieren." Fünfundvierzig Minuten später hast du dreihundert Zeilen halbfertiger Abstraktion und keine funktionierende Software.

Die Lösung ist der PRD-zu-Issues-Skill, und er entlehnt direkt einem Muster, das Andy Hunt und Dave Thomas in The Pragmatic Programmer als Tracer Bullets bezeichneten. Ein Tracer Bullet ist ein vertikaler Schnitt — eine dünne, durchgängige Implementierung, die jede Schicht des Systems von der UI bis zur Datenbank berührt, eine kleine Sache komplett durchführt und beweist, dass der Entwurf end-to-end funktioniert, bevor eine einzelne Schicht vollständig ausgebaut ist.

PRD zu Issues nimmt das PRD und zerlegt es in vertikale Schnitte, jeder auf einen einzelnen Tracer Bullet beschränkt. Für das Team-Arbeitsbereiche-Feature, das ich vorhin erwähnt habe, teilte der Skill das PRD in vier Issues auf:

1. Issue 1 (keine Blocker): Erstelle das workspace-Model, die Migration und einen einzelnen Endpoint, der einem authentifizierten Benutzer erlaubt, einen Arbeitsbereich für sich selbst zu erstellen. UI: ein Button. Tests: Model-Erstellung, Endpoint gibt 201 zurück, Button sendet die richtige Payload.
2. Issue 2 (blockiert durch Issue 1): Füge Mehrfachmitgliedschaft hinzu — erlaube einem Benutzer, mehreren Arbeitsbereichen anzugehören, mit einer workspace_user-Verknüpfungstabelle und einem Arbeitsbereich-Umschalter in der Navigationsleiste.
3. Issue 3 (blockiert durch Issue 1, parallel zu Issue 2): Füge die Berechtigungsvererbungsregeln aus dem PRD hinzu. Reine Domänenlogik mit eigener Testsuite.
4. Issue 4 (blockiert durch Issues 2 und 3): Füge die Abrechnungsaggregationslogik und die Rechnungspositionsgenerierung hinzu.

Zwei Dinge fallen an dieser Zerlegung auf. Erstens: Issue 1 ist für sich genommen ein vollständiges, funktionierendes Feature — wenn du nach Issue 1 aufhörst, hast du auslieferbare Software. Das ist das Tracer-Bullet-Versprechen: Jeder Schnitt ist end-to-end nutzbar. Zweitens: Der Abhängigkeitsgraph ist explizit. Issues 2 und 3 können parallel laufen, was bedeutet, dass ich zwei Agenten starten kann, einen pro Issue, und sie gleichzeitig arbeiten, ohne sich gegenseitig zu behindern.

Diese Parallelisierung ist der Durchbruch, den die meisten Teams noch nicht verinnerlicht haben. Wenn du aufhörst, Agenten als einen einzelnen Arbeiter zu betrachten, und anfängst, sie als einen Pool von Arbeitern mit expliziten Abhängigkeiten zu sehen, verändert sich der Durchsatz einer Entwicklungssitzung grundlegend. Ich habe das übergreifende mentale Modell dafür in der Agent-Swarm-Architektur für Claude Code aufgeschrieben — PRD zu Issues ist das konkrete Artefakt, das Schwarm-artiges Arbeiten sicher statt chaotisch macht.

Das andere, was PRD zu Issues verhindert, ist der schlimmste Fehlermodus des KI-Ingenieurwesens: die Horizontale-Schicht-Falle. Ohne vertikale Schnitte neigt ein Agent dazu, zuerst alle Models zu bauen, dann alle Controller, dann alle Views, dann alle Tests. Auf halbem Weg hast du eine vollständige Datenschicht, die nichts nutzt, eine UI, die gegen den falschen Vertrag gemockt ist, und null funktionierende Software. Mit vertikalen Schnitten hast du immer ein funktionierendes System; du hast nur ein kleineres funktionierendes System als das endgültige Feature.

Skill 4: TDD — Red, Green, Refactor (und warum der Refactor wehtut)

Jetzt hast du das PRD, du hast die Issues, und du bist bereit, Code zu schreiben. Hier übernimmt der TDD-Skill, und hier beginnt die Pipeline zu offenbaren, wie sich KI-Agenten tatsächlich unter Druck verhalten.

Der TDD-Skill führt den klassischen Red/Green/Refactor-Zyklus durch, aber angepasst für Agenten:

1. Red: Der Agent schreibt einen fehlschlagenden Test für das nächste Verhalten im aktuellen Issue. Test ausführen. Bestätigen, dass er aus dem richtigen Grund fehlschlägt. (Dieser Unterschritt ist wichtig — Agenten schreiben manchmal einen Test, der aus dem falschen Grund fehlschlägt, und du findest das erst zwei Stunden später heraus, wenn „bestanden" nicht das bedeutet, was du dachtest.)
2. Green: Der Agent schreibt den minimalen Code, der erforderlich ist, damit der Test besteht. Test ausführen. Bestätigen, dass er besteht.
3. Refactor: Der Agent verbessert den Code, ohne das Verhalten zu ändern. Test ausführen. Bestätigen, dass er immer noch besteht.

Schritte 1 und 2 funktionieren hervorragend mit Agenten. Claude ist ausgezeichnet darin, fokussierte Tests zu schreiben, ebenso ausgezeichnet darin, minimale Implementierungen zu schreiben, die diese Tests bestehen lassen. Als ich ihn das erste Mal in zwanzig Minuten durch eine Laravel-Serviceklasse rasen sah, mit jeder Methode abgedeckt durch einen Test, der geschrieben wurde, bevor die Methode existierte, hatte ich wirklich das Gefühl, dass ich meinen Job ein Jahrzehnt lang falsch gemacht hatte.

Schritt 3 ist, wo die Probleme liegen.

Hier kommt der ehrliche Teil dieses gesamten Artikels. KI-Agenten sind zutiefst unwillig, ihren eigenen Code zu refaktorisieren, innerhalb desselben Kontexts. Das Muster sieht so aus: Du schreibst einen grünen Test, der Agent schreibt den minimalen Code, du sagst ihm, er soll refaktorisieren, und er gibt denselben Code zurück mit einem Kommentar, der sagt „das ist bereits gut strukturiert." Er lügt nicht. Aus seinem eigenen Kontext heraus sieht der Code tatsächlich gut aus. Das Problem ist, dass der Agent seit einer Stunde auf seine eigene Logik starrt und die Perspektive verloren hat, die nötig ist, um den Code-Geruch zu erkennen.

Der Workaround, der für mich funktioniert — und den der TDD-Skill einbaut — ist, den Refactor-Schritt in eine frische Agentensitzung auszulagern. Neues Kontextfenster. Keine Geschichte des Schreibens des ursprünglichen Codes. Du gibst der neuen Sitzung den fehlschlagenden-dann-bestehenden Test und die grüne Implementierung, und bittest um Refactoring. Ohne den Originalautor-Bias ist der Agent bereit, den Code auseinanderzunehmen. Der Test gibt ihm einen Vertrag, gegen den er refaktorisieren kann. Das Refactoring ist fertig. Du committst.

Das ist der Moment, den viele Leute übersehen, wenn sie sagen „KI kann kein echtes TDD." Doch, sie kann — aber nur, wenn du jede Phase des Red/Green/Refactor-Zyklus als eine separat abgegrenzte Agentensitzung behandelst, nicht als ein einzelnes Gespräch. Der Skill erzwingt diese Abgrenzung. Das Prinzip ist dasselbe, das ich in warum präzises Prompten besser ist als cleveres Prompten behandelt habe — der Agent ist nur so gut wie der Kontext, den du ihm gibst, und das schließt den Kontext ein, den du ihm nicht gibst.

Es gibt eine zweite subtile Sache, die der TDD-Skill handhabt. Er weigert sich, den Agenten den Red-Schritt überspringen zu lassen. Wenn du einen Agenten einen Test gegen bestehenden Code schreiben lässt, schreibt er einen Test, der beim ersten Durchlauf besteht — und du hast keine Ahnung, ob der Test tatsächlich das Verhalten prüft, das dir wichtig ist. Der Skill blockiert dies, indem er den Fehlschlag-zuerst-Zustand erzwingt. Du gehst nicht weiter, bis der Test aus einem Grund fehlschlägt, den du benennen kannst.

Skill 5: Codebase-Architektur verbessern — Wenn die Pipeline zurückschleift

Die vier obigen Skills bringen dir ein funktionierendes Feature. Sie verhindern allein jedoch nicht, dass deine Codebasis verrottet. Über fünf oder zehn Features hinweg sammelt sich die Art von struktureller Schuld an, die in keinem einzelnen PR auftaucht, aber langsam jedes zukünftige Feature schwieriger macht. Der fünfte Skill ist es, der diese Abdrift auffängt.

Codebase-Architektur verbessern unterscheidet sich von den anderen. Er läuft nicht innerhalb der linearen Pipeline — er läuft periodisch, zwischen Feature-Zyklen, als ein Aufräumdurchlauf. Seine Aufgabe ist es, die aktuelle Codebasis zu betrachten und gezielte Refactorings vorzuschlagen, und die besten davon in neue Issues umzuwandeln, die oben in die Pipeline zurückkehren.

Die Art, wie er funktioniert, ist anders als alles andere im Workflow. Der Skill startet drei oder mehr parallele Sub-Agenten, jeder mit dem Auftrag, ein radikal anderes Schnittstellendesign für den Bereich der Codebasis vorzuschlagen, der refaktorisiert wird. Drei Sub-Agenten, weil einer nur den Status quo bestätigen würde und zwei in eine binäre Entscheidung verfallen würden — drei ist die kleinste Zahl, die echte Alternativen erzwingt.

Ich habe das letzten Monat auf einem Content-Pipeline-Modul ausgeführt, das unordentlich geworden war. Die drei Sub-Agenten kamen zurück mit:

• Vorschlag A: Eine rein funktionale Pipeline aus komponierbaren Schritten, jeder eine reine Funktion über einer typisierten Payload.
• Vorschlag B: Ein Event-getriebenes Design mit einer Queue und einer Reihe unabhängiger Consumer.
• Vorschlag C: Eine traditionelle Serviceklassen-Hierarchie mit einer Basisklasse und drei konkreten Strategien.

Der übergeordnete Agent evaluierte dann alle drei gegen die tatsächlichen Einschränkungen der Codebasis — Testabdeckung, Deployment-Form, das bestehende Datenmodell — und empfahl eine Hybridlösung aus A und B: rein funktionale Schritte intern, dispatcht auf die bestehende Queue-Infrastruktur. Keiner der drei reinen Vorschläge war die richtige Antwort. Die Hybridlösung war es. Und ich wäre allein nie auf die Hybridlösung gekommen, weil mein Kopf seit Monaten an der bestehenden Serviceklassen-Struktur festhing.

Die Ausgabe des Skills ist ein RFC, ebenfalls als GitHub Issue eingereicht. Der RFC beschreibt das vorgeschlagene Refactoring, die Alternativen, die erwogen und verworfen wurden, die Begründung für die Empfehlung und den vorgeschlagenen inkrementellen Migrationspfad. Sobald der RFC genehmigt ist, kehrt er bei Schritt 1 in die Pipeline zurück — du Grill-Me'st den Refactoring-Vorschlag, schreibst ein PRD dafür, zerlegst ihn in Issues und TDD'st ihn.

Dieser Zyklus ist der Teil, der am schwierigsten zu kommunizieren ist, ohne ihn laufen zu sehen. Die Pipeline ist nicht wirklich linear. Sie ist eine Schleife. Features gehen durch 1→2→3→4. Periodische Architekturverfeinerungen gehen durch 5→1→2→3→4. Über ein Quartal hinweg wächst die Codebasis in eine Richtung, die du gewählt hast, statt in eine Richtung abzudriften, die sie selbst gefunden hat.

Die Zeitachse — Wie ein reales Feature die Pipeline durchläuft

Lass mich durchgehen, wie das zeitlich tatsächlich aussieht, für das Team-Arbeitsbereiche-Feature, auf das ich ständig verweise, damit die Abstraktion Form bekommt.

Montagmorgen, 45 Minuten. Ich führe Grill Me mit der groben Idee aus. Zweiundzwanzig Fragen. Ich beantworte sie. Am Ende der Sitzung ist der Entwurfsbaum weit genug durchlaufen, dass ich das Feature in einem einzigen Absatz ohne Vorbehalte beschreiben kann.

Montagmorgen, 20 Minuten. Ich führe Schreibe ein PRD aus. Der Skill generiert das Dokument aus dem Grill-Transkript, ich prüfe es, ändere zwei Sätze und reiche es als GitHub Issue ein. Issue #341.

Montagmorgen, 15 Minuten. Ich führe PRD zu Issues aus. Es zerlegt #341 in die vier Sub-Issues, die ich oben beschrieben habe, mit dem angehängten Abhängigkeitsgraphen. Issues #342, #343, #344, #345.

Montagnachmittag bis Dienstag. Ich führe TDD für Issue #342 aus (der grundlegende Schnitt). Etwa vier Stunden insgesamt. Red, Green, Refactor für jedes Verhalten. Ich halte den Refactor-Schritt in einem separaten Kontextfenster. Issue geschlossen.

Mittwoch. Ich starte zwei parallele TDD-Sitzungen, eine für #343 und eine für #344. Es sind bewusst unabhängige Issues. Etwa drei Stunden jeweils, parallel in separaten Fenstern laufend. Beide geschlossen.

Donnerstagmorgen. Ich führe TDD für #345 aus, die Abrechnungsaggregation. Etwa fünf Stunden, weil die Testoberfläche breiter ist. Bis Ende des Tages geschlossen.

Freitag. Ich führe Codebase-Architektur verbessern gegen das Arbeitsbereich-Modul aus. Die drei Sub-Agenten schlagen drei Strukturen vor. Der übergeordnete Agent empfiehlt ein kleines Refactoring, um die Berechtigungsprüfungslogik in ein reines Modul zu extrahieren. RFC eingereicht als Issue #346. Ich entscheide, dass es sich lohnt, führe die Schleife erneut aus und liefere das Refactoring bis Freitagnachmittag aus.

Gesamtdauer: etwa dreißig Stunden fokussierter Arbeit über fünf Tage, für ein Feature, das ich auf zwei Wochen geschätzt hätte, bevor ich diese Pipeline zu nutzen begann. Der Grund für die Kompression ist nicht, dass die Agenten schneller tippen als ich. Das tun sie — aber Tippen war nie der Engpass. Der Grund ist, dass die Pipeline fast alle Nacharbeitszyklen eliminiert hat, die vorher die mittleren drei Tage der Woche aufgefressen haben.

Der ehrliche Teil — Wo diese Pipeline versagt

Ich habe dir erzählt, was funktioniert. Der Artikel verdient dein Vertrauen nur, wenn ich dir auch sage, wo er bricht.

Die Pipeline setzt voraus, dass du während Grill Me gute Antworten geben kannst. Wenn du nicht artikulieren kannst, was du tatsächlich willst, legen die Fragen nur die Lücke offen. Der Skill ist kein Ersatz für Nachdenken — er ist ein Erzwingungsmechanismus für Nachdenken. Ich habe Entwickler gesehen, die versucht haben, Grill Me als Methode zu nutzen, um „herauszufinden, was sie wollen", mitten in einer Sitzung, und das Ergebnis ist ein Transkript voller „ich weiß nicht, was denkst du?", was ein PRD ergibt, das effektiv die Präferenzen des Agenten sind, als die des Benutzers verkleidet. Dieses PRD wird dann der Vertrag, an den jeder nachgelagerte Agent gebunden ist, und du entdeckst bei Issue #4, dass die Präferenzen des Agenten nicht deine waren.

Das TDD-Refactoring-Problem löst sich nicht vollständig, selbst mit einer frischen Sitzung. Manchmal schaut der neue Agent den Code an und produziert eine marginale Bereinigung, die das tiefere strukturelle Problem verfehlt. Das Muster, bei dem ich gelandet bin: Ich führe das Refactoring zweimal durch, in zwei separaten frischen Sitzungen, und betrachte beide. Wenn sie übereinstimmen, committe ich. Wenn sie sich widersprechen, liegt das eigentliche Refactoring meist in der Unstimmigkeit, und ich wähle entweder das bessere der beiden oder gebe beide an einen dritten Agenten zur Versöhnung. Das ist langsamer als mir lieb ist.

Parallele Issues sind nicht wirklich kostenlos. Wenn ich zwei TDD-Sitzungen parallel auf unabhängigen Issues laufen lasse, teile ich meine eigene Aufmerksamkeit — und das ist der wahre Preis, nicht die Agenten-Rechenleistung. Der Abhängigkeitsgraph in PRD zu Issues verhindert, dass die Agenten sich gegenseitig im Code behindern, aber er kann nicht verhindern, dass ich schlecht zwischen Kontexten wechsle. Daher beschränke ich mich auf zwei parallele Sitzungen. Drei überfordern mich.

Der Architektur-Skill kann über-refaktorisieren. Als ich Codebase-Architektur verbessern das erste Mal gegen ein gesundes Modul laufen ließ, generierte er drei ernsthafte Refactoring-Vorschläge für Code, der kein Refactoring brauchte. Der Skill neigt dazu, Arbeit zu finden. Du bist die Bremse. Wenn keiner der drei Vorschläge die Codebasis wesentlich verbessert, ist die richtige Antwort, das Refactoring zu überspringen und den Skill in zwei Monaten erneut auszuführen. Disziplin zählt hier mehr als bei jedem anderen Schritt.

Skill-Länge ist nicht Skill-Qualität. Die zwei besten Skills in dieser Pipeline — Grill Me und PRD zu Issues — sind kurz. Vielleicht hundert Zeilen jeweils. Die Skill-Autoren, die ich die schlechtesten Ergebnisse produzieren sah, sind diejenigen, die Skill-Länge als Maßstab für Gründlichkeit verwenden. Präzision darin, wann ein Skill auslöst und was er produziert, ist weitaus wichtiger als wie viel Instruktionstext er enthält. Ich habe dieses Muster in wie Claude Skills tatsächlich einen Workflow steuern behandelt — dasselbe Prinzip gilt hier, doppelt.

Wie dies verändert, was ein Ingenieur den ganzen Tag tut

Tritt einen Schritt von den fünf Skills zurück. Die Arbeitsform, die die Pipeline hervorbringt, unterscheidet sich grundlegend von dem, was ich 2024 getan habe, und es lohnt sich, laut auszusprechen, was sich verändert hat.

Ich schreibe weniger Code. Ich schreibe mehr Verträge. Das PRD ist ein Vertrag. Die Issues sind Verträge. Die Tests sind Verträge. Die RFCs sind Verträge. Die eigentliche Implementierung ist zunehmend etwas, das ein Agent gegen einen von mir verfassten Vertrag produziert, und mein Zeitaufwand pro Feature hat sich stark in Richtung der vertragsschreibenden Seite verschoben.

Ich denke mehr in Entscheidungsbäumen, weniger in Syntax. Die ersten drei Skills in der Pipeline drehen sich alle darum, den Entwurfsbaum aufzulösen, bevor Code existiert. Die zwei danach handeln davon, sauber gegen den aufgelösten Baum zu arbeiten. Nachdem ich dieses Muster erkannt hatte, begannen sich auch meine Ingenieur-Gewohnheiten außerhalb der Pipeline zu verschieben — ich ertappe mich mitten in einem Gespräch über ein Feature dabei, die Art von Fragen zu stellen, die Grill Me stellt, bevor überhaupt ein Tool läuft.

Ich verlasse mich auf Parallelismus in einer Weise, die ich früher nie getan habe. Zwei gleichzeitige TDD-Sitzungen auf unabhängigen Issues klingt wie ein Produktivitäts-Hack. Es ist tatsächlich ein anderer Modus des Ingenieurwesens. Die mentale Fähigkeit, die es erfordert, ist die Fähigkeit, den Abhängigkeitsgraphen stromaufwärts korrekt zu entwerfen — wenn du die Issues falsch zerlegst, kollidieren parallele Sitzungen. Wenn du sie gut zerlegst, ist Parallelismus fast kostenlos. Die Pipeline bestraft schlechte Zerlegung und belohnt gute Zerlegung, und das ist eine Feedback-Schleife, die ich vorher nie hatte.

Ich behandle Gedächtnis als ein Artefakt, nicht als eine Annahme. Jede wichtige Entscheidung lebt an einem Ort, den zukünftige-Claude lesen kann. Das PRD, die Issues, die Testnamen, die Commit-Nachrichten, die RFCs — alles ist so strukturiert, als könnte morgen ein gedächtnisloser Senior-Ingenieur ohne Kontext auf dem Repo landen, denn in der Praxis passiert genau das jedes Mal, wenn ich eine frische Agentensitzung öffne.

Wenn du einen tieferen Einblick möchtest, wie das zugrundeliegende Skills-System diese Art von Kompoundierung ermöglicht, ist die Agenten-Skills-Architekturanalyse der Artikel, auf den ich dich als nächstes verweisen würde. Die Pipeline, die ich hier beschreibe, ist, wie Skills aussehen, wenn man sie mit Absicht verknüpft.

Der Kurs, den ich tatsächlich verfolge

Ich wäre unehrlich, wenn ich nicht erwähne, wo die meisten dieser Muster für mich aufgetaucht sind. Matt Pocock — der Ingenieur hinter einem großen Teil der TypeScript-Ausbildung, auf die ich seit Jahren still und leise baue — führte eine zweiwöchige Kohorte namens Claude Code for Real Engineers durch, vom 30. März bis 13. April 2026, und der Lehrplan entspricht fast genau der Pipeline, die ich gerade beschrieben habe. Plan/Execute/Clear-Protokoll. Tracer-Bullet-Implementierung. PRD-Schreiben für KI-Leser. Das Autonome-Schleife-Muster am Ende der zweiten Woche.

Der Kurs kostet $795 auf AI Hero. Ich bin nicht affiliiert, ich bekomme keinen Kickback, und ich habe mich nicht für die Live-Kohorte eingeschrieben — die On-Demand-Version ist das, was jetzt verfügbar ist, und ich evaluiere, ob die Struktur die Kosten rechtfertigt, angesichts dessen, dass die meisten Muster öffentlich und reproduzierbar sind, wenn man bereit ist, sie selbst zusammenzustellen. Die ehrliche Einschätzung: Wenn du die Lernkurve von Monaten auf Wochen komprimieren willst und es vorziehst, die Fünf-Skill-Pipeline nicht aus Blogposts wie diesem zusammenzusetzen, ist die Kohorte eine vernünftige Wette. Wenn du geduldig bist und die obige Pipeline dir genug gibt, um loszulegen, kannst du es wahrscheinlich allein schaffen.

Was ich sagen werde: Die Kategorie, die dieser Kurs besetzt — strukturierte Ingenieurpraxis rund um KI-Agenten, im Gegensatz zu „Tipps und Tricks"-Inhalten — ist diejenige, die in den nächsten zwei Jahren am meisten zählen wird. Der Markt wird sich aufteilen in Ingenieure, die KI als Tippbeschleuniger behandeln, und Ingenieure, die sie als gedächtnislosen Mitarbeiter behandeln, der eine echte Pipeline braucht. Die zweite Gruppe wird der ersten Kreise um die Ohren fahren.

Jenseits der fünf Skills — Wohin ich als Nächstes gehe

Die Pipeline in ihrer jetzigen Form ist solide. Es ist nicht dort, wo ich sie am Ende haben will.

Womit ich jetzt experimentiere, ist autonome Agenten-Integration an den Rändern. Konkret: ein geplanter Agent, der alle zwei Wochen Codebase-Architektur verbessern gegen das Repo ausführt, RFCs als Issues einreicht und mich zur Überprüfung markiert. Ich muss nicht daran denken, den Skill auszuführen. Der Skill führt sich selbst aus. Die RFCs landen in meiner Warteschlange. Ich genehmige und gehe erneut in die Pipeline, oder ich schließe als Wontfix. Das Architektur-Drift-Problem wird ein passives Häkchen statt einer aktiven Gewohnheit.

Das andere Stück ist Kontextfenster-Disziplin quer durch die Pipeline. Jeder Schritt produziert ein Artefakt, das zum Eingabekontext für den nächsten Schritt wird. Wenn das Artefakt zu ausführlich ist, füllt sich der Kontext des nächsten Schritts und der Agent wird dümmer. Die Kunst besteht darin, jedes Artefakt so knapp wie möglich zu machen und dabei trotzdem einen vollständigen Vertrag zu bewahren. Ich habe mein PRD-Template im letzten Monat gestrafft, und die nachgelagerte Codequalität hat sich messbar verbessert, jedes Mal wenn ich einen Absatz gestrichen habe, der sein Gewicht nicht trug. Dieses Prinzip — die Idee, dass weniger, aber präzise gewählter Kontext besser ist als mehr, aber lose kuratierter Kontext — ist der wichtigste Hebel in der Software-Entwicklung mit KI-Agenten, über den in den Tutorials niemand spricht.

Das dritte Stück ist sprachunabhängige Anwendung. Ich habe diese Pipeline gegen Laravel, gegen Next.js, gegen eine Python-Datenpipeline und gegen ein Bash-lastiges Infrastruktur-Repository ausgeführt. Sie funktioniert bei allen vier. Die Skills wissen nicht, in welcher Sprache sie operieren; sie operieren auf dem Entwurfsbaum, dem PRD, den Issues, den Tests und den Architekturmustern. Diese Sprachunabhängigkeit ist die Eigenschaft, die mich glauben lässt, dass diese Pipeline die richtige ist, um in den nächsten zwei Jahren in sie zu investieren, unabhängig davon, mit welchem Stack ich letztendlich arbeite.

Was du vor Montagmorgen tun solltest

Wenn du bis hierhin gelesen hast und von der Idee überzeugt bist, ist hier die Reihenfolge, in der ich dir empfehlen würde, es auszuprobieren. Installiere nicht alle fünf Skills auf einmal. Die Pipeline ist aus gutem Grund sequentiell, und der Versuch, sie als Big Bang zu übernehmen, wird jeden Workflow, den du derzeit hast, überwältigen.

1. Diese Woche: Installiere Grill Me. Nutze es beim nächsten Feature, für das du sonst einfach Claude zum Schreiben prompten würdest. Achte auf die Fragen, die es stellt. Achte darauf, welche du ohne die Hilfe nicht hättest beantworten können. Das ist der Wert.
2. Nächste Woche: Füge Schreibe ein PRD hinzu. Leite die Grill-Me-Ausgabe hindurch. Reiche das PRD als GitHub Issue ein. Gewöhne dich daran, dass das Artefakt irgendwo dauerhaft lebt.
3. Die Woche danach: Füge PRD zu Issues hinzu. Beobachte, wie deine Features in Tracer Bullets zerlegt werden. Lerne, gute vertikale Schnitte von schlechten zu unterscheiden — schlechte kommen als ein einzelnes Issue zurück, das sich nicht schließen lässt.
4. Woche vier: Füge TDD hinzu. Sei auf die Refactoring-Schritt-Reibung vorbereitet. Löse sie, indem du das Refactoring in einer separaten Sitzung durchführst.
5. Woche sechs: Füge Codebase-Architektur verbessern hinzu. Führe es einmal aus. Sieh nach, ob du der Ausgabe genug vertraust, um danach zu handeln.

Bis Woche acht hast du eine funktionierende Pipeline. Bis Woche zwölf entwirfst du deine eigenen Variationen. Bis Monat sechs fühlt sich der Workflow so natürlich an wie der Workflow, den du hattest, bevor Agenten existierten, nur schneller, bewusster und schwieriger zu brechen.

Der Sonntag, den ich an Laravel verlor, war der, den ich verlieren musste. Es war der Preis des Lernens, tief in meinen Knochen, dass Software-Entwicklung mit KI-Agenten nicht darum geht, Prompts zu tippen und Code erscheinen zu sehen. Es geht darum, die richtigen Artefakte in der richtigen Reihenfolge zu produzieren, damit ein gedächtnisloser Experte die Arbeit an jedem Punkt aufnehmen und fortsetzen kann, ohne den Entwurf zu verlieren. Die Pipeline ist, wie du das möglich machst.

Ich habe seitdem keinen solchen Sonntag mehr verloren.

Häufig gestellte Fragen

Was bedeutet „Software-Entwicklung mit KI-Agenten" in der Praxis?

Software-Entwicklung mit KI-Agenten bedeutet, den Agenten als gedächtnislosen Senior-Ingenieur zu behandeln, der jede Entscheidung, Anforderung und Einschränkung als dauerhaftes Artefakt erfasst braucht, bevor Code geschrieben wird. In der Praxis ist das eine feste Pipeline — Grill Me, PRD, Issues, TDD, Architecture Refactor — bei der jeder Schritt den Kontext produziert, von dem der nächste Schritt abhängt. Die vollständige Durchführung findest du in den Pipeline-Abschnitten oben.

Funktionieren diese Skills nur in Claude Code?

Die fünf Skills sind sprach- und konzeptagnostisch — die zugrundeliegenden Muster (Entwurfsbaum, vertikale Schnitte, Red/Green/Refactor, parallele Sub-Agenten) funktionieren mit jeder Agenten-Laufzeitumgebung, die Skills oder gleichwertige abgegrenzte Instruktionen unterstützt. Claude Code ist, wo ich sie ausführe, weil das Skills-System dort am ausgereiftesten ist, aber dieselbe Pipeline kann auf anderen Plattformen mit benutzerdefinierten Slash-Befehlen oder System-Prompts reproduziert werden.

Warum weigern sich KI-Agenten, ihren eigenen Code zu refaktorisieren?

Agenten haben Schwierigkeiten mit dem Refactoring innerhalb desselben Kontexts, weil sie die gesamte Sitzung über den Code nachgedacht haben und die Perspektive verlieren, die nötig ist, um den Code-Geruch zu erkennen. Die Lösung ist, eine frische Agentensitzung ohne vorherigen Kontext zu öffnen, ihr nur den fehlschlagenden-dann-bestehenden Test und die grüne Implementierung zu geben und um Refactoring gegen den Testvertrag zu bitten. Das Prinzip wird im TDD-Abschnitt oben behandelt.

Was ist ein „vertikaler Schnitt" oder „Tracer Bullet" in diesem Kontext?

Ein vertikaler Schnitt ist eine durchgängige Implementierung, die jede Schicht des Systems berührt — UI, API, Domänenlogik, Datenbank — aber nur eine kleine Sache komplett durchführt. Er stammt ursprünglich aus dem „Tracer Bullet"-Muster in The Pragmatic Programmer und ist die Arbeitseinheit, in die PRD zu Issues ein Feature zerlegt. Das Ergebnis ist, dass jedes Issue, das du schließt, funktionierende Software liefert, keine halbfertige Schicht.

Ist der Claude Code for Real Engineers-Kurs $795 wert?

Die Kohorte behandelt dieselben Muster, die in diesem Artikel beschrieben werden — Plan/Execute/Clear, PRD-Schreiben für KI-Leser, Tracer-Bullet-Implementierung, autonome Schleifen — in einem strukturierten zweiwöchigen Format. Er ist die Kosten wert, wenn du die Lernkurve komprimieren willst und geführte Instruktion dem Selbstzusammensetzen der Pipeline aus öffentlichen Quellen vorziehst. Die On-Demand-Version ist derzeit verfügbar; Live-Kohorten werden periodisch wiederholt.

Lass uns zusammenarbeiten

Möchtest du KI-Systeme aufbauen, Workflows automatisieren oder deine technische Infrastruktur skalieren? Ich helfe dir gerne.

• Fiverr (Individuelle Builds & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Lösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienste): xcybersecurity.io