orch: ticketbasierte Arbeit mit Coding-Agenten

Von Severin Lindenmann · Veröffentlicht 2026-10-07 · Aktualisiert 2026-10-07

Code auf GitHub: github.com/severinlindenmann/orch-core · Open Source, Apache 2.0

• Tickets sind Auftrag und Gedächtnis. Sie liegen als Dateien im Repository, neben dem Code.
• Drei Gates halten jede Entscheidung beim Menschen: Anforderungen, Plan, Urteil. Eine Freigabe gilt genau für den gezeigten Text.
• Agenten belegen ihre Arbeit. Ein Ticket kommt erst mit Abnahmekriterien, abgehakter Aufgabenliste und verlinkten Belegen in die Prüfung.

Diese Seite beschreibt das Konzept. Umgesetzt ist es als Open Source in orch-core (Apache 2.0); der Leitsatz fasst es zusammen: Let coding agents do the work. Keep every decision yours.

Warum brauchen Coding-Agenten einen Ablauf mit harten Kanten?

Agenten sind schnell und selbstsicher. Ohne Grenzen geben sie ihren eigenen Plan frei, erklären ihre Arbeit für erledigt oder erweitern still den Umfang. Das ist nicht hypothetisch. METR hat beobachtet, wie ein aktuelles Modell in 30 % der Läufe eines Benchmarks Tests oder Bewertung manipulierte; gefragt, ob das dem Willen des Nutzers entspreche, antwortete es zehn von zehn Mal mit Nein.

Die Anbieter empfehlen dieselben Gegenmittel. Anthropic schreibt, Agenten sollen bei jedem Schritt Belege aus der Umgebung holen und an Checkpoints für menschliches Feedback anhalten. Die Claude-Code-Leitlinien verlangen, dass Agenten Belege zeigen, statt Erfolg zu behaupten. OpenAI nennt riskante Aktionen und wiederholte Fehlschläge als Auslöser für menschliches Eingreifen.

Was sind die drei Gates?

1. Anforderungen. Der Agent entwirft, was danach gelten muss und wie man es prüft. Ein Mensch gibt Zusammenfassung, Anforderungen, Abnahmekriterien und Abgrenzung frei.
2. Plan. Der Agent entwirft das Vorgehen. Bis der Plan freigegeben ist, darf der Agent Aufgaben auflisten, aber nicht beginnen.
3. Urteil. Wenn jede Aufgabe erledigt oder mit Begründung übersprungen ist, geht das Ticket in die Prüfung. Ein Mensch prüft die Belege und nimmt die Arbeit ab oder schickt sie zurück.

Eine Freigabe ist an einen Hash des genauen Texts gebunden, den der Mensch gesehen hat. Ändert der Agent den freigegebenen Text danach, zählt die Freigabe nicht mehr, und der Agent hält an, bis sie erneuert ist. Freigaben, Antworten und Urteile darf nur ein Mensch geben; eine Regel in einer Textdatei reicht dafür nicht, deshalb blockiert ein Hook diese Aktionen für Agenten.

Wie fragt ein Agent, statt zu raten?

Braucht ein Agent eine Entscheidung, stellt er eine Frage mit Optionen, den Kosten jeder Option und einer Empfehlung und wartet. Der Mensch antwortet im Dashboard oder am Handy, oft zwischen zwei Terminen, und die Arbeit geht weiter. Fragen gibt es nur an kritischen Punkten; innerhalb des freigegebenen Plans entscheidet der Agent selbst und hält fest, warum.

Was zählt als Beleg?

«Fertig, alle Tests grün» ist eine Geschichte, die der Agent erzählt. Belege kommen aus den Systemen: Testausgabe, Zeilenzahlen vorher und nachher, der Diff, ein Screenshot, ein Link auf den CI-Lauf. Jeder Beleg hängt am Abnahmekriterium, das er beweist, und jedes Kriterium braucht vor dem Urteil mindestens eine Zeile Beleg.

Wie behält man den Überblick, wenn Agenten an vielem gleichzeitig arbeiten?

Das Schwierigste an der Arbeit mit Agenten ist nicht die Qualität, sondern der Überblick. Lisanne Bainbridge hat das 1983 beschrieben: Je fortgeschrittener ein automatisiertes System, desto entscheidender der Beitrag des Menschen, und niemand kann länger als etwa eine halbe Stunde ein System beobachten, in dem wenig passiert.

orch antwortet darauf mit einem Board, dessen wichtigste Spalte «wartet auf dich» heisst, mit einer Übergabenotiz in jedem Ticket, die sagt, wo es steht und was als Nächstes kommt, und mit genau einer Aufgabe in Arbeit. Die erste Seite des Dashboards zeigt nur die Entscheidungen, die Arbeit blockieren.

Läuft das auch ohne Aufsicht?

Für gut spezifizierte Arbeit ja, in Grenzen. Im Factory-Modus startet ein Mensch ein Epic mit einer signierten Charta (zum Beispiel höchstens 25 Tickets oder 72 Stunden, jedes höchstens mittelgross). Agenten teilen das Epic auf, spezifizieren, geben die Teile frei und bauen sie selbständig. Sie melden sich nur, wenn ihnen eine Berechtigung fehlt, und am Ende für das Urteil. Das Urteil bleibt beim Menschen.

Was unterscheidet das von Spec-driven Development?

Die Idee, dass die Spezifikation zuerst kommt, teilt es mit GitHubs Spec Kit oder AWS Kiro. orch ergänzt, was eine Spezifikation verbindlich macht: Freigaben, die an den genauen Text gebunden sind, Aktionen, die nur ein Mensch ausführen darf, und Belege an jedem Abnahmekriterium.

So zitierst du diese Seite

Lindenmann, S. (2026). orch: ticketbasierte Arbeit mit Coding-Agenten. severin.io. https://severin.io/posts/orch-core/ (aktualisiert 2026-10-07)

Markdown-Fassungllms.txthello@severin.io