Das Erste, was ich morgens öffne, ist nicht mehr der Code-Editor. Es ist ein Bot in unserem internen Slack. Er heißt Anvil. Das klingt schnell nach einer Erfolgsgeschichte über Automatisierung, trifft den Punkt aber nicht. Ein zusätzlicher Bot hat meinen Arbeitstag nicht verändert. Entscheidend war das Harness dahinter: Egal, wer eine Änderung anstößt, sie muss denselben Qualitätsweg nehmen.

Früher stellte QA eine scheinbar kleine Frage: „Wenn wir diesen Text ändern, was ist noch betroffen?“ Ich unterbrach meine Aufgabe, verlor den aktuellen Gedankengang, öffnete das Repository, suchte den relevanten Code, antwortete und baute danach meinen ursprünglichen Kontext neu auf. Eine Frage konnte einen halben Tag zerlegen. QA wartete auf mich, ich wartete auf die eigene Konzentration. Beide Seiten standen still.

Heute schickt QA eine Ticketnummer und einen kurzen Auftrag an Anvil. Der Bot liest Ticket und Code, ordnet die Auswirkung ein und führt eine risikoarme Änderung bis zum Merge Request. Bei größerem Umfang fragt er vor der Umsetzung den Verantwortlichen. Gegen Mittag sehe ich die aufgelaufenen MRs zusammen durch. Der Gewinn liegt nicht zuerst in der Geschwindigkeit. Eine in Slack gestartete Änderung muss dieselben Regeln erfüllen wie eine Änderung aus meinem Terminal.

Für diese Geschichte habe ich genau eine interne Rückschau als Grundlage bereitgestellt. Ihre Zahlen sind kein Produktivitätsbenchmark und keine Prognose für andere Organisationen. Öffentlich prüfbare technische Aussagen sind mit den offiziellen Unterlagen von Claude Code, ESLint und TypeScript verlinkt. Anvil, der Ablauf und die Ergebniswerte gehören dagegen zu diesem internen Fall.

Warum ich dieses Thema aufgeschrieben habe

Eine Nachricht an einen Bot ist noch keine Delegation. Muss ich das Ergebnis danach vollständig neu prüfen, wurde nur das Eingabefeld ausgetauscht. Delegation beginnt dort, wo es einen belastbaren Grund gibt, nach der Übergabe dieselbe Qualität zu erwarten. Dieser Grund war nicht die Intelligenz des Modells, sondern die Betriebslogik des Projekts.

Zuerst versuchte ich es mit längeren Prompts. Doch Regeln wie „ein Abrechnungsmonat hat 28 Tage“, „der Mindestbestellwert beträgt 50.000 KRW“ oder „bei einer ungültigen Währungseinheit nicht speichern“ gehören nicht in jede einzelne Nachricht. Ein Teil davon lag bereits im Code, aber nicht so, dass jede neue Aufgabe ihn zuverlässig und in derselben Reihenfolge findet.

Wir sammelten Richtliniendateien, Risikostufen, Prüfkommandos und Übergabebedingungen in einer gemeinsamen Betriebsdefinition. Slack und Terminal wurden zu zwei Eingängen in denselben Prozess. Anvil ist keine eigene Intelligenz, sondern eine dünne Oberfläche für den bereits verwendeten Coding-Agenten. Die offizielle Dokumentation zum Headless-Betrieb von Claude Code beschreibt mit claude -p genau die nicht interaktive Ausführung einer einzelnen Anfrage.

Eine Oberfläche lässt sich schnell nachbauen. Die Betriebsdefinition ist die eigentliche Arbeit. Fehlen Repository-Kontext, Rechte und Abschlussprüfungen, bietet ein hübscher Slack-Bot Nichtentwicklern nur einen schnelleren Weg zu uneinheitlichen Ergebnissen.

Der konkrete Arbeitsfall

Als Referenz diente ein QA-Ticket. Zuerst müssen Repository und betroffene Dateien feststehen. Danach prüft der Agent, ob die Änderung Richtlinien oder Kernmodule berührt. Kleine Eingriffe laufen durch Umsetzung und Kontrollen bis zum MR. Größere warten vor der Codeänderung auf eine Freigabe. Die Entscheidung über Produktabsicht und Veröffentlichung bleibt in jedem Pfad bei einem Menschen.

Ein einheitlicher Ablauf von der Slack-Anfrage über Auswirkungsanalyse, Codeänderung und Qualitätsgates bis zum Merge Request und zur menschlichen Entscheidung

Der Weg aus Slack ist bewusst schlicht:

[QA-Anfrage in Slack]
→ Anvil
→ nicht interaktiver Coding-Agent
→ Projektregeln und Risikoeinstufung
→ Codeänderung
→ lint · typecheck · test
→ Merge Request oder Freigabeanfrage

Slack ist nur die Oberfläche. Projektdefinition, Prüfkommandos und Blockierregeln bilden das Harness. Anthropic unterscheidet im offiziellen Leitfaden zum Debugging der Claude-Code-Konfiguration ebenfalls zwischen Anweisungen, die Kontext liefern, und Rechten beziehungsweise Hooks, die Grenzen durchsetzen. „Führe keine gefährlichen Befehle aus“ aufzuschreiben ist etwas anderes, als die Ausführung technisch zu verhindern.

Diese Trennung hält den Ablauf auch außerhalb von Slack brauchbar. Starte ich im Terminal, gelten dieselben Dateien und Kontrollen. Ein Subagent braucht nicht den kompletten Verlauf eines früheren Chats, um die Regel zum Abrechnungsmonat oder die Pflichtprüfungen zu kennen.

Was ich praktisch verglichen habe

Der erste Vergleich war nicht Modell gegen Modell. Ich verglich einen Prompt, der um Tests bittet, mit einem Ablauf, der ohne bestandene Tests nicht enden kann. Das Gate läuft, wenn der Agent seine Arbeit beenden will. Korrigierbare Lint-Probleme werden mit ESLint --fix bereinigt. Übrige Lint-Fehler, tsc --noEmit und die relevanten Tests müssen grün sein. Der Claude-Code-Leitfaden zu Hooks beschreibt Lifecycle-Ereignisse und Stop-Hooks, an denen sich deterministische Kommandos ausführen lassen.

Gefährliche Aktionen teilen wir in zwei Gruppen. rm -rf, DROP TABLE oder das Anlegen einer .env-Datei werden in diesem Weg vollständig blockiert. git push --force oder das Umgehen von Prüfungen mit --no-verify können ausnahmsweise sinnvoll sein, brauchen aber eine menschliche Bestätigung und eine Spur im Protokoll. Das eine ist das Geländer um den Ofen, das andere das Warnschild für eine fachkundige Person.

Kleine Änderungen laufen automatisch, mittlere werden nach der Umsetzung geprüft und Richtlinien- oder Kernänderungen brauchen vorher eine Freigabe

Auswirkung Beispiele Ablauf
MINOR Text, einfache Zuordnung Umsetzen → Qualitätsgates → MR
MODERATE Komponentenstruktur, Style-Refactoring Umsetzen → Qualitätsgates → Review
MAJOR Richtlinienkonstanten, Validierung, Kernmodule Vorabfreigabe → Umsetzen → MR-Review

Der absichtliche Engpass bei MAJOR machte MINOR und MODERATE erst großzügig möglich. Jede Änderung gleich schnell durchzulassen wäre keine Automatisierung, sondern fehlende Kontrolle. Jede Tippfehlerkorrektur vorab genehmigen zu lassen automatisiert dagegen nur das Warten.

Die Stufe ergibt sich aus projektspezifischen Pfaden und Richtlinienbegriffen. Sie ist kein allgemeiner Sicherheitsklassifikator. Eine Textdatei kann in einem Repository harmlos sein und in einem anderen die Preislogik steuern. Entscheidend ist die Verbindung zwischen erwarteter Auswirkung und dem Zeitpunkt, an dem ein Mensch eingreift.

Wo es in der Praxis bricht

Ich tippte weniger Code, doch die Arbeit verschwand nicht. Nach meiner persönlichen Schätzung sank Umsetzung von ungefähr 60% auf fast null, das Schreiben von Tests von ungefähr 20% ebenfalls auf fast null. Dafür stiegen explizite Richtlinien und Anforderungen auf etwa 60%, Reviews auf rund 30% sowie Merge und Release auf ungefähr 10%. Das sind keine gemessenen Arbeitszeiten; deshalb sollen die Spalten auch nicht sauber 100 ergeben.

Persönliche Schätzung, wie sich Zeit von Umsetzung und Tests hin zu Richtlinien, Anforderungen, Review, Merge und Release verschob

Die Tastatur bleibt. Ich schreibe nun häufiger Nutzerwege, Eingaberegeln, Fehlermeldungen und Ausnahmen statt Implementierung. Aus „Login verbessern“ wird ein Arbeitsdokument: Wo beginnt der Weg, welche Werte kommen an, was sieht der Nutzer bei einem Fehler, was folgt danach? Dieses Dokument ist zugleich Vorgabe für den Agenten und Prüffläche für die Abnahme.

Der neue Ablauf scheiterte auch an banalen Stellen. Auf einer Seite mit mehreren Fehlermodalen konnte der Bot das richtige Repository nicht sicher bestimmen. Der Lauf endete am ersten Schritt. Erst eine Rückfalloption, in der der Nutzer aus möglichen Repositories wählt, brachte den Prozess weiter. Die Erfahrung der Person nach einem Automatisierungsfehler gehört ebenfalls zum Design.

Unklare Richtlinien verursachten mehr Störungen als ein schwaches Modell. Eine Geschäftsregel, die nur als „das machen wir natürlich so“ in einem Kopf steckt, kann kein Agent lesen. Wiederholte Fehler führten daher zuerst zu Änderungen an Richtliniendokumenten und Harness, nicht am Code. Dass ein Modell meine Gedanken nicht kennt, ist kein Fehler. Es markiert die Systemgrenze.

Grüne Tests waren nicht gleichbedeutend mit einer vollständigen Funktion

Für eine abgeschlossene Änderung betrachtete ich zwei getrennte Werte. Die technische Vollständigkeit lag bei 85%, die Abdeckung der Spezifikation bei 62,5%. Alle 151 Jest-Tests bestanden, alle sechs Modalzustände waren vorhanden. Beim Abgleich mit 40 Vorgaben fanden sich jedoch nur 25 im Produkt. Die fehlenden 15 betrafen Kategorien, Zuständigkeiten und Suchfilter – Geschäftsregeln, die Lint, Typen und bestehende Tests nicht erraten konnten.

Interne Rückschau mit 85 Prozent technischer Vollständigkeit, 62,5 Prozent Spezifikationsabdeckung, 151 bestandenen Tests, sechs Modalzuständen und 25 von 40 umgesetzten Vorgaben

Der Agent hatte die Lücken nicht völlig übersehen. Sein Bericht nannte Kategorie, Zuständigkeitsanzeige und Speicherbestätigung als offen. Er fand und dokumentierte die Punkte, verband sie aber nicht mit der Definition of Done. Technische Gates konnten diesen Fehler nicht sehen, weil gültiger Code und bekannte Tests keinen Widerspruch meldeten.

Darum entstand eine zweite Schicht für Verhalten und Spezifikation. Sie sucht nach betroffenen Richtlinien, führt zugehörige Akzeptanzkriterien aus und warnt, wenn Dokument und Ergebnis auseinanderlaufen. Noch funktioniert das nicht in jedem Projekt, und ungeschriebene Regeln erkennt es ebenfalls nicht zuverlässig. Der realistische Stand ist kleiner: Offene Punkte sollen nicht nur im Bericht stehen, sondern die Fertigstellung blockieren, sobald sie als Kriterium dokumentiert sind.

Was ich beim nächsten Mal anders machen würde

Ich würde nicht mit dem Bot anfangen. Zuerst müsste geklärt sein, ob zwei Menschen beim selben Auftrag auf dieselben Regeln und Prüfungen treffen. Andernfalls wird der Slack-Bot lediglich zum schnellen Eingang in die vorhandene Unordnung.

Drei Grenzen würde ich wieder setzen. Gefährliche Befehle werden an der Ausführung blockiert, nicht nur im Prompt. Je größer die Auswirkung, desto früher kommt die menschliche Freigabe. Teststatus und Anforderungsstatus bleiben getrennte Werte. Technische Gates beantworten, ob der Code beschädigt ist. Akzeptanzprüfungen beantworten, ob wir das beabsichtigte Produkt gebaut haben.

Menschen bleiben beteiligt. Änderungen an Geld, Kundendaten oder zentralen Richtlinien genehmigt eine Person mit passender Erfahrung. Auch Wiederherstellung nach einem Fehllauf und die endgültige Veröffentlichung haben einen benannten Verantwortlichen. Es geht nicht darum, Menschen herauszunehmen. Maschinen übernehmen wiederholbare Kontrollen; Menschen besetzen die Punkte, an denen Urteil das Ergebnis verändert.

Checkliste vor dem Nachbauen

  • Drei Richtlinien aufschreiben, die das Team regelmäßig nur mündlich erklärt.
  • Autonome Änderungen, prüfpflichtige Aktionen und blockierte Befehle auf Kommandoebene trennen.
  • Lint, Typprüfung und Tests als erzwungene Abschlussgates anbinden.
  • Text- und Mapping-Änderungen anders routen als Komponenten, Richtlinien, Validierung und Kernmodule.
  • Spezifikationsabdeckung getrennt von der Zahl bestandener Tests erfassen.
  • Bei fehlgeschlagener Zuordnung eine Auswahl für Repository und nächsten Schritt anbieten.
  • Eine Person für finalen Merge und externe Veröffentlichung benennen.

Ein interner Slack-Bot ist kein notwendiger Startpunkt. Dieselbe Projektdefinition und dieselben Hooks im Terminal liefern bereits einen großen Teil des Nutzens. Ich würde eine häufige, risikoarme Anfrage auswählen, sie höchstens bis zum MR automatisieren und zuerst wieder geöffnete MRs sowie fehlende Anforderungen zählen – nicht angeblich gesparte Stunden.

Die Betriebsgrenze festhalten

Die interne Rückschau beschreibt einen einzelnen Betriebsfall, kein Nachweis, dass dieselben Kontrollen in einem anderen Repository getestet wurden oder dort wirken. Nutzen Sie das Arbeitsblatt, um betroffene Pfade, Risikostufe, Genehmigungspunkt und erforderliche Prüfungen festzuhalten, bevor ein Agent eine Änderung beginnt. Arbeitsblatt für das Änderungsrisiko eines KI-Agenten herunterladen.

Quellen, die ich geprüft habe

Mein Arbeitstag änderte sich nicht, weil ich keinen Code mehr schrieb. Er änderte sich, weil ich genauer festlegte, was entstehen sollte. Innerhalb einer klaren Grenze kann das Modell handeln; außerhalb entscheidet ein Mensch. Harness Engineering bedeutete für mich weniger, ein Modell stärker zu machen, als die Reichweite sinnvoller Delegation sichtbar zu ziehen.

Quellen und Berichte

Öffentliche Quellen, die wir für Fakten, offizielle Dokumentation, politischen Hintergrund, Produktinformationen und veränderliche Angaben geprüft haben.