Zum Inhalt springen

Blog

Der Feature Planner füllt sein Backlog selbst, mit einem Menschen am Gate

Läuft die Linie leer, schreibt die Triage-Automation der Factory auf software-factory.dev ihr Backlog selbst. Was riskant ist, geht vorher über eine Person.

Verfasst von

Software Factory

Veröffentlicht: 22. Mai 2026 Aktualisiert: 2 Min. Lesezeit

Öffentlich auf software-factory.dev (öffnet in einem neuen Tab) entsteht eine Factory mit einer Automation namens Feature Planner. Am interessantesten finde ich, was sie macht, wenn das Backlog fast leer ist.

Dann schreibt sie ihre nächsten Tickets selbst.

Triage, jede Stunde

Den größten Teil der Zeit macht der Planner Routinearbeit, die trotzdem jemand machen muss. Er triagiert Issues. Eine Cron-Zeile, 0 * * * *, weckt ihn zu jeder vollen Stunde. Zusätzlich könnt ihr ihn jederzeit manuell starten.

Zu Beginn jedes Laufs liest er drei Dokumente: die Produkt-Spec, das Architekturdokument und die Konventionen. Danach holt er sich alle offenen Issues ohne Status-Label. Bei jedem fragt er sich, ob die Beschreibung reicht, um es zu bauen. Reicht sie, bekommt das Issue einen vereinheitlichten Titel und das Label für die Queue. Reicht sie nicht, setzt er needs-human und stellt in einem Kommentar gezielte Fragen.

Der Beyond-Spec-Modus öffnet sich unter drei Bedingungen

Hier steckt das Detail, das ihr übernehmen solltet. Der Planner kennt einen Modus namens Beyond-Spec. Den öffnet er nur, wenn alle drei Bedingungen auf einmal zutreffen:

  • Alle Punkte der Spec sind umgesetzt.
  • Im Backlog sind weniger als drei Einträge offen.
  • Auf needs-human sind schon weniger als fünf Issues geparkt.

Erst in diesem Zustand fängt die Factory an, selbst Erweiterungen vorzuschlagen. Auch dann sortiert sie die Vorschläge nach Risiko. Kleiner Feinschliff mit geringem Risiko landet sofort im Backlog. Alles mit hohem Risiko, etwa ein neues Feature oder eine Schemaänderung, bekommt needs-human. Weiter geht es erst, wenn eine Person mit „approved“ kommentiert, also ihr Okay gibt.

Auf das Gate kommt es an

Eine Automation, die sich eigene Arbeit ausdenkt, hilft euch genau so lange, bis sie sich die falsche ausdenkt. Ehrgeiz zu verbieten wäre die falsche Antwort. Besser lasst ihr die Factory frei vorschlagen und schickt die riskanten Vorschläge zuerst über einen Menschen.

Das Muster funktioniert auch anderswo. Reagiert eine Automation nur auf das Backlog, das Menschen schreiben, bleibt sie stehen, sobald diese Menschen ausgelastet sind. Schreibt sie ihr Backlog ohne Gate selbst, findet ihr am nächsten Morgen zehn spekulative Tickets vor. Die Bedingung für den Beyond-Spec-Modus liegt genau zwischen diesen beiden Extremen.

Wer die Automation selbst lesen will: feature-planner.yaml im Repository der Factory (öffnet in einem neuen Tab).

Wenn die Queue eurer Factory leer ist: Wer legt fest, was sie als Nächstes baut, und was verhindert, dass diese Entscheidung zu weit geht?

Weiterlesen

Die Artikel der Wissensbasis sind auf Englisch.

  1. Das Issue-Label ist das Protokoll der Agenten Auf software-factory.dev beschreibt der Skill development-workflow die Factory aus ihrer eigenen Sicht. Er zeigt, dass keine Automation eine andere aufruft: Sie stimmen sich über Labels auf Issues ab. 2 Min. Lesezeit
  2. Erst Feedback und Nutzungsdaten abgleichen, dann Arbeit daraus machen Der Feedback Digest der Factory auf software-factory.dev legt neues Feedback neben sieben Tage Nutzungsdaten. Ein Issue entsteht nur, wenn die Daten den Wunsch belegen. 2 Min. Lesezeit

Alle 18 Teile

Kundenprojekte

Skalierung braucht benannte Eigentümer

Coding-Agenten skalieren über Teams hinweg, wenn benannte Menschen die Plattform, die Teampraxis, die Guardrails und die Messung verantworten. In Rollout & Skalierung wird diese Verantwortung aufgebaut und an interne Eigentümer übergeben, in eurem Stack.

Schulung zum Thema: Agentic Software Factory: Advanced Team Training
Rollout & Skalierung ansehen

Erst ein Team prüfen? Der Selbstcheck: zwölf Ja-Nein-Fragen, drei Minuten, Ergebnis sofort, ohne Konto. Zum Selbstcheck