Hör auf, deine Agents zu micromanagen

Letzte Woche hat mein OpenAPI-Toolchain-Repo 110 Pull Requests gemerged.

Den Code habe ich fast nicht geschrieben. Die Issues habe ich fast nicht angelegt. Die Bugs habe ich nicht gefunden. Die meisten dieser PRs waren klein und eng umrissen, eher Fixes und Refactorings als Features. In denselben sieben Tagen wurden 52 Issues geöffnet und 33 geschlossen, und vielleicht zwei davon habe ich selbst von Hand angelegt. Den Rest der Arbeit haben Agents erledigt. Und das Einzige, was das Ganze zerstört hätte, war genau der Reflex, den jeder erfahrene Entwickler verspürt: sie eng zu kontrollieren.

Habe ich nicht. Und genau darum geht es.

---

Der Reflex, der Agents kaputtmacht

Das habe ich auf die teure Tour gelernt: Je stärker du einen Agent auf deinen exakten Weg zwingst, desto schlechter wird er. Jede Einschränkung, jedes „Nein, mach es so“ zieht ihn weg von dem Verhalten, für das er trainiert wurde, und hin zu einer schlechteren Imitation von dir. Einen Agent zu micromanagen ist keine Kontrolle. Es ist Sabotage mit Zwischenschritten.

Also habe ich aufgehört, mit einem fertigen Masterplan zu beginnen.

Als ich openapi-zod-ts gebaut habe, die Toolchain, die ich mir immer gewünscht hatte, kannte ich die Hälfte der Mechanik nicht. Ich hatte noch nie etwas auf npm veröffentlicht. Ich wusste nicht, welche Dependencies ich brauche oder wie man eine Release-Pipeline zum Laufen bringt. Also habe ich gar nicht erst so getan. Ich hatte eine Richtung, keinen Bauplan, und bin Schritt für Schritt vorgegangen: eine GitHub-Org anlegen, irgendetwas auf npm veröffentlichen, eine Workflow-Datei zum Laufen bringen. Jeder Schritt klein genug, um ihn wirklich abzuschließen. Sobald es sich auf Implementierung, Features und Tests zuspitzte, habe ich den Agent allein laufen lassen.

Es hat über eine Handvoll Abende funktioniert. Das Tempo war nicht die Überraschung. Die Überraschung war, wie wenig davon ich selbst war.

---

Du korrigierst ihn nicht. Du forderst ihn.

Wenn du nicht Zeile für Zeile steuerst, was machst du dann? Du legst die Latte höher.

Wenn der Agent gut lief, habe ich ihm nicht auf die Schulter geklopft und weitergemacht. Ich habe die nächste Sache schwerer gemacht. Ein eigenes Integrationstest-Paket, um zu beweisen, dass die drei Packages tatsächlich zusammenspielen und nicht nur isoliert. Smoke-Tests. Eine komplette Pet-Store-Demo, end-to-end verdrahtet. Und schließlich 128 echte OpenAPI-Specs auf einen Schlag, die chaotische, inkonsistente, Spec-verletzende Sorte, wie echte APIs sie ausliefern.

Dann habe ich ihm echten Schmerz gegeben. In meinem Hauptjob habe ich einen Pull Request geöffnet, um unsere Produktionssysteme auf die Library zu migrieren, nie gemerged, aber die Erfahrung war echt, die Breaking Changes waren echt, und das Ganze habe ich lokal mit einer separaten Claude-Session geprüft. Echte Specs und echte Migrationen bringen Probleme ans Licht, die kein Unit-Test erfindet.

Das ist die Verschiebung. Du sagst einem Agent nicht, wie er gut sein soll. Du gibst ihm schwerere Dinge, an denen er gut sein kann.

---

Der beste Fix, den ich gemacht habe, kam nicht von mir

Irgendwann griff der Agent bei einem Response-Schema zu .passthrough(), also: behalte jedes unbekannte Feld, das über die Leitung kommt. Falsche Wahl für einen Response-Contract. Da willst du .strip(), damit ein Backend, das plötzlich ein zusätzliches Feld schickt, es nicht in typisierten Code durchsickern lässt, der nie damit gerechnet hat.

Ich will ehrlich sein, weil die meisten Artikel genau diesen Teil schönreden: Ich habe das nicht gefunden. Ich saß nicht Zeile für Zeile über dem Diff und machte „Aha“. Was ich getan habe, war eine Frage von außen zu stellen, „Haben wir Tests, in denen wir das Zod-Schema mit eigenen Fehlermeldungen erweitern, und funktioniert das auch?“, und ich habe einen neutralen KI-Reviewer-Agent gestartet, der mit frischem Blick draufschaut. Meine Frage plus der Blick des Reviewers brachten die Fehlausrichtung ans Licht. Der Fix folgte als Konsequenz. Das System hat sich selbst ertappt. Ich habe es nur immer wieder von den Rändern her angestupst.

Das ist der eigentliche Motor. Ich reviewe den Code nicht. Ich lasse Kritiker laufen, die das tun, und lasse sie Issues anlegen, wie echte Nutzer es täten. 2026 schreibst du keinen Bug-Report mehr von Hand; ein Agent schreibt in Sekunden einen schärferen. Also erzeugt das Repo seine eigene Arbeit: 52 Issues letzte Woche geöffnet, 33 geschlossen, 19 noch offen, während ich das schreibe. Angelegt habe ich davon fast keins.

---

Erfindet sich diese Maschine ihre eigene Arbeit?

Ich muss die ehrliche Variante davon aushalten. 52 Issues geöffnet, 33 geschlossen. Der Backlog ist gewachsen. Eine Schleife, die sich nur immer mehr Arbeit selbst erzeugt, ist keine Feedback-Schleife, sie ist ein Hamsterrad, und von außen können beide identisch aussehen.

Also fordere ich das System immer wieder heraus, seine eigenen Issues so zu bewerten, wie es Code bewertet: Ist das echt? Ist es das wert? Hebt der Fix die Qualität oder nur die Zahl? Bisher hält die Antwort stand, und der Beweis ist das, was die Schleife wegwirft. Ein Agent hat einen sauberen, vernünftigen Wunsch eingereicht, für discriminated-oneOf-Schemas z.discriminatedUnion zu erzeugen. Er wurde als nicht den Mehraufwand wert geschlossen. Eine Schleife, die zu ihren eigenen Ideen nicht Nein sagen könnte, hätte das gebaut. Die Issues, die tatsächlich gefixt werden, sind echte Bugs und Refactorings, die gegen echte Komplexität ankämpfen, während die Test-Batterie darunter die Qualität davon abhält, abzudriften. Wenn gute Issues trotzdem schneller entstehen, als die Pipeline sie abarbeiten kann, ist das ein Priorisierungsproblem, und Priorisierung ist einer der wenigen Jobs, der meiner bleibt.

Ich beobachte das genau. An dem Tag, an dem die Schleife Beschäftigungstherapie produziert, die ihr eigenes Review besteht, ist die Philosophie falsch. Passiert ist das bisher nicht. Aber „bisher“ ist das entscheidende Wort, und das spreche ich lieber offen aus, als so zu tun, als wäre die Schleife selbstverständlich gut.

---

Wo es tatsächlich aufhört

Ein Prompt kauft mir etwa zehn Minuten agentische Arbeit. In dieser Lücke starre ich nicht auf einen Fortschrittsbalken. Ich bin in einem anderen Terminal, an einem anderen Projekt. Gerade habe ich sieben Sessions über fünf Codebases offen: Arbeit aus dem Hauptjob, diese Website, eine zweite Content-Seite, die OpenAPI-Toolchain und eine SEPA-XML-Library. Wenn eine davon einen Schubs braucht, ohne den Agent mitten im Lauf zu stören, öffne ich eine Read-only-Session oder zweige einen git worktree ab und merge ihn später zurück.

Die Decke, an die ich stoße, ist nicht meine Aufmerksamkeit und nicht meine Tippgeschwindigkeit. Es sind 36 GB RAM. Einmal liefen bei mir rund 60 Agents gleichzeitig, und meinem MacBook ging der Speicher aus, einmal hat es sich gefangen, einmal brauchte es einen harten Neustart. Das ist eine Geschichte für einen anderen Artikel, aber sie zeigt dir, wohin sich die eigentliche Grenze verschoben hat. Nicht zum Menschen.

---

Ich bin zum Software-Engineering-Manager von Agents geworden, und das passt besser zu meinem Traumjob als jede Rolle, die ich je hatte. Die Arbeit ist nicht mehr Code schreiben. Sie ist nicht einmal mehr Code reviewen. Sie ist: eine Richtung vorgeben, die Latte höher legen, Kritiker aufstellen, beurteilen, was sich lohnt, und das Ganze dann in fünf anderen Terminals nochmal.

Führe einen Agent wie einen Junior-Entwickler, den man beaufsichtigen muss, und du bekommst die Decke eines Junior-Entwicklers. Fordere ihn wie ein System, und er läuft, während du schläfst.