Ich habe mein Werkzeug in wenigen Wochen fünfmal umgebaut. Fünfmal am selben Ding klingt nach fehlender Planung. Ich halte jeden dieser fünf Umbauten für richtig.

Der Grund ist einfach. Jeder Umbau hatte einen konkreten Anlass. Keiner war auf Vorrat gebaut. In der klassischen Welt wäre das ein Warnsignal. Ein Werkzeug, das man ständig anfasst, ist selten fertig. Bei mir ist es das Gegenteil.

Was sich in allen fünf Schritten nicht verändert hat, sind die drei menschlichen Stopppunkte. GO, push, merge. Der Rest ist Bewegung. Die Kontrolle nicht.

Angefangen hat es mit einem Konzept

Ich habe aufgeschrieben, wie ich mit KI programmiere. Ein Whitepaper, in dem ich den Prozess festgehalten habe. Dort habe ich Dinge festgelegt, die für mich nicht verhandelbar sind.

Zum Beispiel, dass es menschliche Stopppunkte gibt. Die KI arbeitet. An drei Stellen entscheide ich. Ich gebe das GO, bevor sie loslegt. Ich gebe den push frei, bevor Code meinen Rechner verlässt. Ich merge, bevor er im Hauptzweig landet. Alles dazwischen kann die KI machen. Diese drei Punkte nicht. Das ist keine Bequemlichkeit. Das ist Verantwortung.

Vom Konzept zum Werkzeug

Ein Konzept setzt sich nicht von selbst um. In der zweiten Iteration wollte ich eine Leitplanke, die den Prozess auch durchsetzt.

Ich arbeite mit Claude und mit GitHub. Also habe ich das Claude Workflow Kit gebaut. Sieben Skills, ein Ablauf: Planung, Issues, Implementierung, Review. An den drei Stopppunkten übergebe ich, sonst läuft es durch. Es funktioniert.

Der Kunde arbeitet mit GitLab

Dann kam ein Kunde. Im August mache ich einen Workshop zum Kit. Ich habe jetzt erfahren, dass der Kunde mit GitLab arbeitet. Ich will das Kit im Workshop zeigen, also muss es auf GitLab laufen.

Der erste Schritt war pragmatisch. Die Unterscheidung wandert in die Skills. Je nachdem, ob für GitHub oder für GitLab entwickelt wird, schaltet der Skill um.

Das ist architektonisch unsauber. Das war mir sofort klar. Ich habe die unsaubere Lösung trotzdem genommen und die Schuld als Issue notiert: Die Skills müssen frei von Technik sein. Nicht aus Prinzipienreiterei. Ich hatte vor, die Skills auf Codex und andere Modelle zu übertragen. Dafür darf im Skill keine Annahme über das Werkzeug mehr stecken.

Bis August habe ich Zeit. Es bleibt also nicht bei der schnellen Lösung.

Was tun, wenn jemand Jira will

Die meisten Firmen, die ich kenne, arbeiten mit Jira. Also stellte sich die Frage: Was passiert, wenn ein Kunde Jira will?

Die Antwort war eine Abstraktionsschicht, in zwei Schritten. Der erste Schritt war die Trennung von Repository und Board. Dass GitHub und GitLab beides können, ist Zufall, kein Gesetz. Jira ist ein Board ohne Repository. Sobald ich beides trenne, kann ich jede Seite für sich behandeln.

Der zweite Schritt war die Abstraktion der Board-Tätigkeiten. Ein Issue lesen. Ein Issue auf dem Board verschieben. Solche Operationen habe ich beschrieben, ohne festzulegen, welches Board dahinter liegt.

Darunter liegen die Adapter. Ein Adapter übersetzt die abstrakte Schicht in die konkrete Struktur. GitHub, GitLab, Jira, Trello, was sonst noch kommt. Der Kern bleibt gleich. Nur der Adapter wechselt.

Manchmal will ich nur loslegen

Nicht jedes Projekt braucht ein Board bei einem Anbieter. Manchmal will ich einfach vor mich hin entwickeln.

Daraus wurde eine harte Anforderung an das Kit. Es muss reichen, dass ich zustimme, den Prozess mitgehe und loslege. Aber die Board-Funktionalität brauche ich trotzdem, weil der Prozess darauf aufsetzt.

Also habe ich eine leichtgewichtige Board-Funktion gebaut. Versionierbar heißt: das Board liegt im Repository, nicht bei einem Dienst. Ich sehe die Historie, ich kann zurückgehen, ich hänge von niemandem ab. Dazu eine einfache Oberfläche, auf der ich die Items ansehe, bei Bedarf bearbeite und weiterschiebe. Kein Anbieter, keine Anmeldung. Nur das, was der Prozess braucht.

Fünf Umbauten, kein Vorrat

YAGNI ist einer meiner Leitsätze. You Ain’t Gonna Need It. Bau nicht, was du nicht brauchst.

Fünf Umbauten klingen nach dem Gegenteil von Disziplin. Sie sind das Gegenteil von Verschwendung. Ich habe die Abstraktionsschicht nicht gebaut, als ich nur GitHub hatte. Ich habe sie gebaut, als GitLab dazukam und Jira absehbar wurde. Ich habe das leichtgewichtige Board nicht gebaut, weil es elegant ist, sondern weil ich es für ein konkretes Projekt gebraucht habe. Jeder Schritt kam, als der Bedarf da war. Keiner vorher.

Früher war das ein schwaches Argument. Nacharbeiten kostete. Wer zweimal an dieselbe Stelle ging, verbrauchte mehr Zeit als jemand, der gleich alles baute. Mit KI im Prozess stimmt diese Rechnung nicht mehr. Ein Umbau, der früher Tage gekostet hätte, ist heute ein Nachmittag. Manchmal weniger.

Das verändert, was sich lohnt. Wenn jeder Umbau billig ist, baue ich erst, wenn ich weiß, dass ich es brauche. Ich fange klein an, für mich. Ich mache es allgemeiner, wenn ein zweiter oder dritter Fall es rechtfertigt.

Billig heißt nicht kostenlos. Das erste Kit kam ohne Konfiguration. Für meinen Fall, GitHub und Claude, war es sofort einsatzfähig. Jede Schicht, die ich darüberlege, kostet etwas: mehr Konfiguration, mehr Dokumentation, mehr Stellen, an denen man etwas falsch einstellen kann. Das Bauen ist billig geworden. Die Komplexität nicht. Auch das spricht dafür, erst zu bauen, wenn der Bedarf da ist.

Das ist kein Umweg. Das ist die Methode. Inkrementell, iterativ, am Bedarf entlang. Fünf Umbauten, kein einziger auf Vorrat.