TL;DR
Ein Projekt beginnt mit Anweisungen in CLAUDE.md und AGENTS.md, mit Skills und mit Commands. Alle drei entstehen, bevor irgendjemand etwas Konkretes über das Projekt weiss. Das Setup, das sie zusammen bilden, ist deshalb zwangsläufig ein erster Entwurf. Eine Session, die schiefging oder nur dank deiner Korrekturen ans Ziel kam, kann dir zeigen, was ins Setup gehört hätte. Verbessere es, solange der Agent den ganzen Verlauf noch im Kontextfenster hat: Dann kannst du gemeinsam mit ihm klären, was falsch lief und womit sich das hätte verhindern lassen. Stell nach jeder Session dieselbe Frage, solange das Projekt läuft: Was braucht es, damit die nächste mit weniger Korrekturen auskommt?
Am Ende der ersten Woche eines agentischen Projekts lautet die Meldung: «Das Setup ist fertig.» Gemeint ist damit: Die Richtlinien sind geschrieben, die Skills sind angelegt, die Connectors sind eingerichtet, und das Team arbeitet mit alldem. Einen genaueren Blick verdient das Wort «fertig».
Das Basissetup zum Projektstart ist bewusst generisch, und gerade das macht seine Teile wertvoll: eine Anweisungsdatei aus einer Vorlage, ein Review-Skill, ein Commit-Skill, eine Übergabenotiz für die nächste Session, die Connectors, die jeder als Erstes einrichtet. Diese Teile halten fest, was für jedes Projekt zutrifft. Genau deshalb fehlt ihnen alles, was nur für dieses eine Projekt gilt. Dieses Wissen gab es noch gar nicht, als das Setup entstand: das Vokabular der Domäne; die Stellen in der Codebasis, an denen der Agent es regelmässig falsch macht; die Konventionen, auf die sich das Team mit der Zeit einigt; die Fehlerklasse, auf die das Review immer wieder stösst.
Wer das Setup für fertig erklärt, sobald es läuft, tut so, als hätte er in der ersten Woche am meisten über das Projekt gelernt. Dabei weiss man in keiner anderen Woche so wenig darüber.
Bei jeder Korrektur lohnt sich die Frage, ob das Setup sie hätte verhindern können.
#Manchmal lautet die Antwort nein. Mit einem Agenten geht eben ab und zu etwas schief, wie mit einem Kollegen auch. In anderen Fällen lautet sie ja, weil du dem Agenten etwas gesagt hast, das ihm auch das Setup hätte sagen können. Das kann der eigene Testbefehl dieses Repositorys sein, das feste Namensschema für die Endpoints einer API oder der richtige Helper für einen bestimmten Kontext.
Am Schluss stimmt das Ergebnis, und die Session gilt als Erfolg. Doch alles, was du selbst beigesteuert hast, geht verloren, sobald sie endet. Eine Woche später taucht dieselbe Situation wieder auf, und du erklärst dem Agenten dasselbe noch einmal.
Ein Agent, den man ohne konkreten Anlass nach Verbesserungen am Setup fragt, findet immer etwas.
#Die Vorschläge klingen obendrein plausibel: eine präziser gefasste Anweisung, ein nicht abgedeckter Spezialfall, ein Abschnitt, der klarer sein könnte. Nichts davon lässt sich auf etwas zurückführen, das tatsächlich passiert ist. Dafür gibt es einen Namen: . Gemeint ist, dass KI-Modelle so antworten, wie man es gern hört, und einem recht geben. Das kennt jeder, der täglich damit arbeitet. Will man von Claude Code wissen, ob sich etwas besser machen liesse, hört man zuerst, was für eine gute Frage das sei. Danach folgen Änderungsvorschläge, die helfen können oder auch nicht. Man hat schliesslich um Verbesserungen gebeten.
Das hat seinen Preis, und zwar nicht, weil die Vorschläge schlecht wären, sondern weil nichts zeigt, dass auch nur einer von ihnen etwas taugt. Keinem dieser Vorschläge ging ja ein Fehler voraus, den er beheben würde. Damit bleibt es bei Verbesserungen auf Verdacht, und ob eine davon etwas gebracht hat, erfährt man nie.
Solange der Verlauf noch im Kontext liegt, kann dir der Agent sagen, was ihn fehlgeleitet hat.
#Der Auslöser für eine Verbesserung am Setup ist weder ein Zeitplan noch ein Review-Zyklus, sondern eine bestimmte Beobachtung: Diese Session hat viele Korrekturen gebraucht, bis das Ergebnis stand. Die Korrekturen kamen entweder von dir oder vom Agenten selbst, der einen eigenen Fehler bemerkte und es noch einmal versuchte. In beiden Fällen kann im Setup etwas gefehlt oder nicht gestimmt haben.
In diesem Moment enthält das Kontextfenster noch den ganzen Verlauf: den Auftrag, die Schritte des Agenten, die Teile, die er verworfen und neu gemacht hat, und alles, was du selbst ergänzen musstest. Genau daraus arbeitest du heraus, was sich am Setup verbessern lässt. Danach liegt all das nie wieder beisammen.
Besprich das alles mit dem Agenten. Frag ihn, was ihn zu diesem Vorgehen gebracht hat, und hinterfrag seine erste Antwort. Finde gemeinsam mit ihm heraus, was dem Setup gefehlt hat. Vielleicht fehlt in den Anweisungen ein Hinweis, vielleicht lässt ein Skill oder Command einen Schritt aus, vielleicht wird eine Regel noch nirgends geprüft. Im letzten Fall wird die Regel zu einem Check, den der Agent laufen lässt, bevor er die Arbeit als abgeschlossen meldet.
Ein neuer Skill oder Command ist gerechtfertigt, wenn sich im Projekt selbst ein Bedarf zeigt.
#Für Ergänzungen gilt derselbe Massstab wie für Änderungen am bestehenden Setup. Später im Projekt tauchen Aufgaben auf, die kein Basissetup hätte abdecken können, etwa ein Release-Check oder das Anlegen eines API-Endpoints nach den Gepflogenheiten genau dieser Codebasis.
Eine solche Aufgabe verdient einen eigenen Skill, sobald sie sich wiederholt: wenn du den Agenten dabei schon mehr als zweimal selbst Schritt für Schritt angeleitet hast und sie auch künftig ansteht. Diese Aufgaben nennt dir keine Best-Practice-Liste. Das Projekt nennt sie dir, und zwar erst, wenn es eine Weile gelaufen ist.
Viel Arbeit ist das alles nicht. Mal kommt eine Zeile dazu, mal ein Check, und jede dieser kleinen Ergänzungen erspart dir beim nächsten Anlauf ein paar Korrekturen. Es braucht allerdings Disziplin: Jeder, der im Projekt Code schreibt, macht solche Änderungen dann, wenn der Bedarf auftaucht. Bei einem Produkt im laufenden Betrieb, das seit Langem agentisch weiterentwickelt wird, haben sich die Teile des Setups als die wertvollsten erwiesen, die über Monate nach und nach verbessert wurden.
Weiter erkunden
Weitere Erkenntnisse