Die Spec ist für Menschen, der Plan für Roboter

Pasha macht kein Frontend. Er arbeitet an Java-Performance und der JVM. Trotzdem wurde die Seite mit dem Abhängigkeitsgraphen, die wir mit KI-Agents gebaut haben, in seinen Worten genau das, was wir besprochen hatten. Der Grund ist seine Reihenfolge: Design, Spec, Code.

Co-Speaker

Pasha Finkelshteyn

Developer Advocate bei BellSoft

Pasha hat einen Master in Psychologie und keine technische Ausbildung. Mit 20 fing er in C++ Builder an zu programmieren, wechselte vor rund 19 Jahren zu Java und hat seitdem auch Kotlin, Scala und Clojure geschrieben. Heute, sagt er, schreibt die KI den Code für ihn.

WebseiteGitHubLinkedInBluesky

Bauplan und Bauzeitenplan

Ein Bau hat zwei Dokumente. Der Bauherr gibt den Bauplan frei. Die Gewerke arbeiten nach dem Bauzeitenplan. Niemand erwartet, dass der Bauherr den Zeitplan liest.

Pashas Workflow teilt KI-Arbeit genauso auf. Er läuft auf Superpowers, einer Sammlung von Agent-Skills. Brainstorming stellt dir eine Handvoll Fragen und schreibt eine kurze Spec. Writing plans macht aus dieser Spec einen langen, detaillierten Plan. Bei 10:31 fasste er es so zusammen:

Es erzeugt ein sehr langes Dokument, das ich fast nie lese. Für mich gilt: Die Spec ist für Menschen, der Plan für Roboter.

Enlarge

100%−+

Subagent-driven development gibt dann jeden Task des Plans an einen eigenen Agent. Der Orchestrator wählt das Modell nach Schwierigkeit: Haiku, um eine Datei abzutippen, Sonnet für etwas Integration, Opus für komplexe Abwägungen. Jeder Task läuft nach Red-Green-TDD, und der Plan nennt sogar den Fehler, den der fehlschlagende Test liefern soll.

Nach jedem Task prüft ein Reviewer-Subagent die Arbeit. Er kennt den Task, nicht die Überlegungen des Implementers. Genau dieser frische Kontext ist der Punkt:

Ich traue keinem Review, das in derselben Session stattfindet.

Wo dein Urteil hineingehört

Die Spec ist das einzige Dokument, das du liest. Also müssen deine Entscheidungen dort landen. Unser Prompt war zwei Zeilen lang: ein Maven-Plugin, das eine interaktive HTML-Seite mit dem Abhängigkeitsgraphen schreibt. Das Brainstorming machte daraus in etwa einer halben Stunde echte Entscheidungen.

Manche kamen aus Pashas Erfahrung. Er wollte umschaltbare Scopes, denn eine Runtime-Abhängigkeit, die eine Compile-Abhängigkeit überschreibt, heißt: Du hast gegen eine andere Bibliothek kompiliert. Er wollte die Seite komplett offline: kein CDN, kein Internet, denn ein Abhängigkeitsbericht braucht keins. Und als wir uns bei einer Version uneinig waren, die gegen das Dependency Management gepinnt ist, haben wir sie weder in „Konflikt“ noch in „passt“ gezwängt. Wir haben eine dritte Kategorie eingeführt, Managed Override, mit eigener Farbe.

Beim Ausblenden von Teilen des Graphen lief es genauso. Pasha wollte einen Teilbaum ausblenden, ich wollte nur sehen, wovon ein Knoten abhängt. Die Spec nahm beides auf, dazu alle Pfade von der Wurzel zu einem Knoten, in einem Rechtsklick-Menü.

Das Rechtsklick-Menü aus der Demo des fertigen Plugins: beide Arten, Teile des Graphen auszublenden, dazu alle Pfade von der Wurzel.

Eine Entscheidung kam aus meinem Drauflosreden, das Pasha mir eigentlich abgewöhnen wollte. Ich wollte einen Link zu Maven Central, um nach neueren Versionen zu sehen. Pasha wies darauf hin, dass das Plugin Maven Central einfach per HTTP fragen kann. Jetzt zeigt die Seite, ob jede Abhängigkeit aktuell ist, innerhalb derselben Major-Version und insgesamt. Ich hatte eine Lösung verlangt, statt mein Problem zu nennen. Das Drauflosreden hat es trotzdem ans Licht gebracht.

Ein Konflikt auf der fertigen Seite: Nearest wins hat commons-io 2.19.0 gewählt, und die Seitenleiste zeigt, dass 2.22.0 verfügbar ist.

Die fertige Spec zu lesen dauerte rund zehn Minuten. Das hat sich gelohnt. Die Spec hatte stillschweigend optionale Abhängigkeiten ergänzt, die niemand verlangt hatte. So etwas fällt in einem Bauplan auf und geht in einem Plan mit 8 Tasks unter.

Einen Schritt haben wir aus Zeitgründen übersprungen: Grill with docs, Matt Pococks Skill, der jeden Entscheidungspunkt abfragt und ADRs schreibt. Laut Pasha hätte das noch eine halbe Stunde gekostet. Er hat einmal dreieinhalb Stunden Grilling-Fragen beantwortet, bevor eine Zeile Code entstand.

Die Gewerke arbeiten den Zeitplan ab

Sobald wir uns für subagent-driven development entschieden hatten, lief der Plan von allein. Wir haben die Zeit genutzt, um zu lesen, was die Agents schrieben, statt sie zu steuern.

Die Java-Seite brauchte nur die Maven-Plugin-API, Maven Core, die Annotations und JUnit. Die Integrationstests liefen mit dem Maven Invoker Plugin und synthetischen Projekten. Pasha hat sein letztes Maven-Plugin vor über 15 Jahren geschrieben und sagte, er hätte nicht gewusst, wie man diese Tests baut.

Der beste Moment kam bei 1:27:38. Ein Implementer-Subagent meldete, dass er den Code vor den Tests geschrieben hatte, ohne vorherigen fehlschlagenden Lauf. Er markierte den Task als „done with concerns“. Warum er von den Schritten des Plans abwich, wusste Pasha nicht. Ihm gefiel, dass er es dem Orchestrator ehrlich gesagt hat.

Einig waren wir uns nicht überall. Pasha verteidigte den handgeschriebenen JSON-Writer der Agents: Er serialisiert eine Klasse, ist getestet und umgeht die Risiken einer Bibliothek, die auch deserialisiert. Ich nähme trotzdem lieber eine gepflegte Bibliothek. Bei var gilt: Pasha nutzt es überall, ich sehe gern den Typ. Wenn ein Agent den Code schreibt, ist es uns beiden ziemlich egal.

Qualität kostet Zeit, nicht Tokens

Ich hatte Zweifel an TDD. Verbrennt ein zuerst fehlschlagender Test nicht Tokens? Die Zahlen bei 2:01:43 sagten: weniger als gedacht. Rund 23,4 Millionen Tokens, die meisten aus dem Cache, und 278.000 Output-Tokens. Die günstigen Modelle erledigten die Routine-Tasks. Pashas Punkt: Die Tests sind kurz und laufen deterministisch. Sie kosten Zeit.

Und Zeit ging uns aus. Pasha hatte vorhergesagt, dass der Build in den letzten 40 Minuten nicht fertig wird, und er hatte recht. Wir hörten bei Task 7 von 8 auf: Scope-Schalter und das helle und dunkle Theme funktionierten, Seitenleiste und Suche gab es noch nicht. Außerdem hing eine Shell zehn Minuten lang ohne Grund.

Das Plugin habe ich nach dem Stream fertiggestellt. Das dauerte noch etwa eine Stunde. Jetzt liegt es auf Maven Central, und du kannst es ausprobieren, ohne deine POM anzufassen:

mvn dev.rabauer:dep-graph-maven-plugin:0.2.0:graph

Danach target/dep-graph.html öffnen. Bei einem Multi-Modul-Build bekommst du eine Seite für den ganzen Reactor:

Der Demo-Build mit vier Modulen. Die rot gestrichelte Kante ist die Version, die verloren hat.

Dieser Workflow ist nicht der schnellste Weg zu einer funktionierenden Seite. Er führt zu einer Seite, die dem entspricht, was du entschieden hast. Wir haben Qualität vor Tempo gestellt, und ich würde mich wieder so entscheiden.

Der eine Skill, den Pasha dir mitgeben will

Um den Kern herum nutzt Pasha weitere Skills: UI UX Pro Max für Design-Richtlinien, die zur Art der App passen, und Systematic Debugging, zu dem wir nicht mehr kamen. Einer stach aber heraus, bei 20:17:

Wenn ihr euch aus diesem Stream nur eine Sache merkt, dann Good OSS Citizen.

Good OSS Citizen von Tessl läuft, bevor du in einem fremden Projekt einen PR oder ein Issue aufmachst. Er liest das Repository und dessen CONTRIBUTING.md und passt deinen Beitrag daran an. Pashas Beispiele: Er teilt einen PR, der über dem Zeilenlimit eines Projekts liegt, oder sagt dir, dass du die Beschreibung selbst schreiben sollst, wenn das Projekt keine KI-Texte annimmt.

Fazit

Pashas Workflow setzt dich dort ein, wo dein Urteil zählt: in einer Spec, die kurz genug ist, um sie wirklich zu lesen. Lies sie wie einen Bauplan, jede Zeile. Dann lass die Agents den Plan abarbeiten, mit Tests und einem Reviewer, der die Überlegungen des Implementers nie gesehen hat.

Das ist langsamer als Prompten und Nachbessern. Dafür entstand ein Frontend, mit dem zwei Backend-Entwickler zufrieden waren. Beim nächsten Mal will ich dieselbe Spec mit meinem BMAD-Prozess bauen und vergleichen.

Nützliche Links

• Superpowers, die Skills hinter Brainstorming, Writing plans und subagent-driven development
• Grill with docs, Matt Pococks Skill, der jede Entscheidung abfragt und ADRs schreibt
• UI UX Pro Max, der Design-Skill, den Pasha für Frontend-Arbeit nutzt
• Good OSS Citizen, der Skill für Beiträge zu fremden Projekten
• Live-Demo des dep-graph-maven-plugin, die fertige Seite zum Durchklicken
• dep-graph-maven-plugin auf Maven Central