Eine Bugfix-Automation darf nie stillschweigend aufhören

Auf eine Zeile in der Bug-Fixer-Automation weise ich Leute immer wieder hin. Sie steht im „do not“-Abschnitt des Prompts: „never silently exit when something is broken“. Sinngemäß heißt das: Wenn etwas kaputt ist, nie kommentarlos beenden.

Der Bug Fixer gehört zu einer Software Factory, die öffentlich auf software-factory.dev entsteht. Seine Aufgabe klingt einfach: nächsten offenen Bug holen, beheben, Pull Request öffnen.

Ein Lauf, Schritt für Schritt

Alle zwei Stunden wird er aktiv. Will jemand nachhelfen, gibt es einen Button für den manuellen Start. Jeder Lauf geht so:

1. Er prüft, ob die Umgebung gesund ist.
2. Er zählt die offenen Pull Requests und bricht ab, wenn bereits drei oder mehr in Arbeit sind.
3. Er nimmt sich den nächsten Bug in der Reihenfolge der Priorität und schaut, ob dafür schon ein Pull Request offen ist.
4. Er sieht in den geschlossenen Issues nach, ob der Bug früher schon einmal aufgetreten ist. Kehrt ein Bug wieder, hat der letzte Fix meist nur ein Symptom behandelt und die Root Cause verfehlt.
5. Er reproduziert den Bug, schreibt den Fix auf einem Branch, lässt die komplette Test-Suite laufen und öffnet den Pull Request.

Zwei Ausgänge, kein dritter

Und jetzt das Detail, das ihr übernehmen solltet. Für den Bug Fixer gibt es genau zwei Arten, einen Lauf zu beenden. Er liefert einen Fix. Oder er findet die Root Cause nicht, dann eskaliert er das Issue mit dem Label needs-human und schreibt in einem Kommentar, was er versucht hat. Einen dritten Ausgang hat er nicht. Es gibt keinen Lauf, nach dem die Arbeit einfach verschwunden ist.

Klingt unscheinbar. Ich glaube, darum geht es im Ganzen.

Lautes Scheitern ist eingebaut

Wenn ihr eine Automation nicht den ganzen Tag im Blick haben könnt, verdient sie nur dann Vertrauen, wenn sie laut scheitert. Gefährlich wird es, wenn sie auf etwas Unverständliches trifft, nichts zurückgibt und trotzdem Erfolg meldet. Wochen später stellt ihr fest, dass sie eine ganze Klasse von Bugs übergangen hat, ohne ein Wort zu sagen.

Ehrliches Scheitern stellt sich nicht von selbst ein. Das müsst ihr ausdrücklich hineinschreiben, so deutlich wie in diesem Prompt. Danach prüft ihr, ob wirklich jeder Ausstiegspfad dort landet. Die komplette Definition findet ihr in der Konfiguration des Bug Fixer auf GitHub (öffnet in einem neuen Tab).

Wenn eure Automationen scheitern: Seht ihr das an einer Stelle, an der ein Mensch hinschaut, oder endet der Lauf einfach?

Weiterlesen

Die Artikel der Wissensbasis sind auf Englisch.

• The software-factory pattern →
• Agentic Software Factory: Advanced Team Training →