Zum Inhalt springen
authorship.dev

Zurück zum ProgrammRead in English

Brief II22. Okt. 2026 · 3 Min. Lesezeit

Vom Flow des Codens zum Flow des Orchestrierens

Der Flow verschwindet nicht, er wandert. Vier PRs approved und gemergt, nur einer war in main: Was der Flow des Orchestrierens braucht, damit ich beim Sign-off noch hinsehe.

Am Ende des ersten Logs stand: Der Flow verschwindet nicht, er wandert. Heute geht es darum, wohin. Gemerkt habe ich es an einem Fall, in dem ich gar nicht gezögert habe: Ich habe approved, gemergt und alles fühlte sich so gut wie immer an. Es war aber nicht richtig.

Ein Beispiel aus der Arbeit an dieser Webseite: Das Feature für den zweisprachigen Log mit Startseite und Bannern lag in vier PRs, die aufeinander aufbauen, #21 bis #24 im authorship.dev-Repo. Die Stapel hat die KI angelegt, aber ich habe es überlesen. Jeder PR hing am Branch des vorherigen, nicht an main. Ich habe sie nacheinander approved und gemergt.

Erst später sah ich: Nur #21 war in main. #22 bis #24 steckten in den Feature-Branches. Aufgefallen ist es mir, weil die Log-Startseite und die Banner auf der Webseite fehlten. Passiert ist nichts Schlimmes, nur etwas git-Aufwand und ein erneutes Deployen. Aber ich hatte vier Mal mit meinem Namen bestätigt, ohne einmal hinzusehen, wohin es geht.

Mich beschäftigt weniger der Fehler als das Gefühl dabei. In Log 1 stand die grüne CI zwischen mir und dem Sign-off, aber ich habe gezögert. Hier gab es nichts, was mich zögern ließ. Ich war im Rhythmus: approven, mergen, nächster PR - es gab keinen Flow-Killer. Approve und Merge bestätigen aber die Aktion, nicht das Ziel. Ich habe „erledigt“ gelesen wie „signiert“. Der Button wurde zu meiner Ersatz-Signatur, so wie in Log 1 die grüne Pipeline.

Im Workflow-Plan heißt dieser Fall „Der Agent eröffnet den PR“, und das Risiko steht dort so beschrieben: „Das Risiko: Du fühlst dich als Reviewer. Du bist der Autor.“ Das Sign-off ist der Punkt, an dem ich mit meinem Namen einstehe. Genau dort habe ich nicht hingesehen.

Warum habe ich nicht hingesehen? Ich bin ein Freund des Flows, des Codens und Erschaffens im Tunnel. Bei KI-generiertem Code ist es verlockend, dort zu bleiben: Das „Approve“ steht immer bereit, ohne jede Hürde - das ist es, was mich im Fluss hält. Das ist der alte Flow des Codens, nur ohne die Widerstände, die mich früher von selbst haben genauer hinsehen lassen. Die Aufgabe ist jetzt, im Flow zu bleiben und trotzdem zu zögern. Das ist der Flow des Orchestrierens.

Er hat mehr Elemente als der Flow des Codens: In diesem Beispiel sind es Aufteilung, Basis und die Übergabe von einem PR zum nächsten. Dadurch bekommt er einen anderen Rhythmus. Das Innehalten fühlt sich zuerst wie ein Bruch an. Mit etwas Übung wird der Widerstand geringer und das Innehalten wird Teil des Flows. In meiner Arbeit mit Präzisionssportlern ist das Alltag: Die Pre-/Post-Shot-Routine ist ein Innehalten, das Teil des Schusses wird. Und das Zögern ist mehr als ein Innehalten: Es ist der Zeitpunkt, an dem ich bewusst mit meinem Namen für die Änderung einstehe. Es ist der Punkt, an dem ich bewusst meine Identität als Autor festige.

Was signiere ich in diesem Moment des Innehaltens? Bei einem einzelnen PR ist die Antwort einfach: den Diff. Bei einem Stapel sind es drei Dinge: den Inhalt, also den Diff, das Ziel, also die Basis, auf der er landet, und die Wirkung, also was danach tatsächlich in main ist. Ein richtiger Inhalt am falschen Ziel ist nicht das, was ich signieren wollte.

Meine Übung für diese Woche ist eine simple Frage vor jedem Merge: Wohin geht das? Die Antwort steht direkt unter dem Titel des PR, dort steht, in welchen Branch gemergt wird. Diese Zeile lese ich, bevor ich klicke. Bei einem Stapel sehe ich nach dem Merge zusätzlich einmal in main nach, ob angekommen ist, was ich signiert habe. Das ist die kleinste Form von Accountability.

Und du? Wohin ging dein letzter Merge und hast du nachgesehen?

Schreib mir deine Antwort. Zum Kontaktformular

Alle Briefe