Von Prompts zur Software Factory

Ein KI-Assistent, dem man einzelne Aufgaben zuruft, spart in erster Linie Tipparbeit und nimmt gegebenenfalls noch Entscheidungen vorweg, die man zu definieren vergaß. Der eigentliche Hebel entsteht erst, wenn man den ganzen Weg vom Ticket bis zum Pull Request als Fertigungsstraße begreift und jede Station so baut, dass ein Agent sie zuverlässig bedienen kann.

In einem Kundenprojekt mit gewachsenem Code habe ich mir genau das aufgebaut. Dieser Artikel beschreibt die Bausteine.

Stationen statt Prompts

Meine Factory hat sechs Stationen:

1. Ticket lesen: Anforderung, Kommentare und Design einsammeln.
2. Spezifikation schreiben: Was wird gebaut, was ausdrücklich nicht, und woran erkenne ich, dass es fertig ist?
3. Umsetzen: Der Agent implementiert gegen die Spezifikation.
4. Prüfen: Kompilieren, Linting und Tests laufen automatisch.
5. Pull Request öffnen: mit einer Beschreibung, die im Review ohne Rückfrage verständlich ist.
6. Zurückmelden: Ergebnis und offene Punkte landen wieder im Ticket.

Jede Station hat eine definierte Eingabe und eine definierte Ausgabe. Das klingt bürokratisch, ist aber der Grund, warum ich mehrere Tickets parallel laufen lassen kann, ohne den Überblick zu verlieren.

Leitfäden im Repository

Ein Agent kennt weder die Architektur noch die Konventionen eines gewachsenen Codes. Beides steht deshalb in Leitfäden, die versioniert im Repository liegen: Architekturregeln, Namenskonventionen, die Befehle zum Bauen und Testen und alles, was neue Mitarbeitende in der ersten Woche lernen müssten. Dazu kommen ein Architektur-Digest und eine Karte des Codes, damit der Agent nicht bei jedem Ticket das halbe Repository lesen muss.

Die Leitfäden gelten für das gesamte Entwicklungsteam und für verschiedene Agenten. Ändert sich eine Konvention, ändere ich sie an einer Stelle.

Eigene Skills

Was ich dem Agenten zweimal erklärt habe, wird ein Skill: eine kurze, wiederverwendbare Anleitung für genau eine Aufgabe. Bei mir sind das zum Beispiel das Schreiben einer Spezifikation, das Pflegen von Übersetzungen oder ein Prüfschritt, der Kompilieren, Linting und Tests parallel startet und nur die Fehler zurückmeldet.

Skills sind bewusst klein. Ein Skill, der alles kann, wird so unzuverlässig wie ein Prompt, der alles will.

zsh-Funktionen als Fließband

Die Stationen verbinde ich mit einfachen zsh-Funktionen. Jedes Ticket bekommt einen eigenen Git-Worktree, damit sich parallele Arbeiten nicht in die Quere kommen. Vereinfacht sieht der Einstieg so aus:

# vereinfacht: ein Ticket, ein Worktree, ein Agent
ticket() {
  local id=$1
  git worktree add "../$id" -b "feature/$id" origin/main &&
    cd "../$id" &&
    claude "/spec $id"
}

Weitere Funktionen starten den Prüfschritt, öffnen den Pull Request oder räumen fertige Worktrees wieder ab. Die Shell ist dafür das richtige Werkzeug: Sie ist ohnehin da, und jede Funktion bleibt eine Handvoll Zeilen.

Eigene CLI-Werkzeuge und API-Anbindungen

Agenten sind gut im Aufrufen von Werkzeugen und schlecht im Erraten von Zuständen. Alles, was deterministisch sein muss, baue ich deshalb als eigenes Kommandozeilenwerkzeug mit klarer Ausgabe: wiederkehrende Release-Schritte, das Abgleichen von Daten zwischen Repository und angebundenen Systemen, Abfragen an interne Schnittstellen.

Der Agent ruft das Werkzeug auf und liest das Ergebnis. Er rechnet nicht selbst, und er rät nicht.

MCP und Browser-Automatisierung

Über das Model Context Protocol (MCP) bekommt der Agent Zugriff auf die Systeme rund um den Code. Wo es eine Schnittstelle gibt, nutze ich sie. Wo es keine gibt oder sie nicht freigeschaltet ist, steuert der Agent den Browser.

So liest er Ticketbeschreibung und Kommentare aus dem Issue-Tracking-System (etwa Jira), bevor die Spezifikation entsteht, und schreibt am Ende eine Zusammenfassung zurück. Auf der Code-Plattform (etwa GitHub) legt er den Pull Request an, füllt die Beschreibung aus der Spezifikation und reagiert auf Review-Kommentare. In der laufenden Anwendung klickt er den neuen Ablauf durch, bevor ich ihn mir ansehe.

Die Test Factory

Tests sind die Station, an der sich entscheidet, ob man einem Agenten trauen kann. In meiner Test Factory entstehen die Tests aus der Spezifikation, nicht aus dem fertigen Code. Sonst prüft der Agent nur, was er gerade selbst gebaut hat.

Die Factory deckt mehrere Stufen ab. Das sind für Frontend-Projekte: Unit-Tests, Tests der Barrierefreiheit und Durchläufe im Browser. Eine feste Schwelle für die Testabdeckung sorgt dafür, dass kein Ticket ohne Tests durchrutscht.

Was beim Menschen bleibt

Die Factory nimmt mir das Umsetzen ab, nicht das Entscheiden. Drei Dinge gebe ich deshalb nicht aus der Hand:

• Die Spezifikation. Ich lese sie, bevor eine Zeile Code entsteht. Ein Fehler hier ist der teuerste.
• Die Architektur. Leitfäden beschreiben Regeln, aber ob eine Regel für diesen Fall noch passt, entscheide ich.
• Die Freigabe. Jeder Pull Request geht durch mein Review und danach durch das des Teams.

Verantwortung lässt sich nicht automatisieren. Was sich automatisieren lässt, ist fast alles andere.

Für Ihr Team

Eine solche Factory lässt sich in bestehende Projekte einführen, schrittweise und ohne den laufenden Betrieb zu stören. Wie ein erster Ausschnitt aussieht, steht im Fallbeispiel zur agentischen Entwicklung. Wenn Sie das für Ihren Code aufbauen möchten, sprechen Sie mich an.