Agent Plans koennten das naechste AGENTS.md werden
Eine neue Studie zu Plan-Dateien fuer Coding Agents zeigt eine entstehende Schicht zwischen Repository-Kontext und Ausfuehrung: explizite Implementierungsplaene.
Leseaufrufe werden gezählt...
Agent Plans koennten das naechste AGENTS.md werden
Kurzfassung
AGENTS.md gab Coding Agents einen Ort fuer repository-spezifische Anweisungen. Eine neue Studie zeigt die naechste moegliche Schicht: persistente Plan-Dateien, die Agenten nicht nur sagen, was das Projekt ist, sondern wie eine konkrete Aenderung ausgefuehrt werden soll.
Die Forschenden untersuchten 36.710 GitHub-Repositories und suchten gezielt nach Plan-Artefakten fuer Coding Agents. Gefunden wurden 85 Markdown-Plan-Dateien in 10 Repositories. Das ist eine kleine Stichprobe, also noch kein etablierter Standard.
Aber es ist ein wichtiges Signal. Agentische Entwicklung bewegt sich moeglicherweise von Kontextdateien zu Ausfuehrungsspezifikationen.
Die grobe Entwicklung sieht so aus:
- README.md -> Kontext fuer Menschen
- AGENTS.md -> Kontext fuer Coding Agents
- Plan-Dateien -> aufgabenspezifische Ausfuehrungsanweisungen
Was passiert ist
Die explorative Studie suchte nach persistenten Plan-Dateien, die von agentischen KI-Coding-Tools genutzt werden. Diese Dateien beschrieben Implementierungsschritte, relevante Dateien, Testanforderungen, Validierungsanweisungen und Review-Kontext.
Das begleitende Material der Studie nennt 36.710 Repositories im Suchkorpus und 85 identifizierte Plan-Dateien in 10 Repositories. Das ist wichtig, weil die Praxis sichtbar ist, aber noch am Anfang steht.
Das ist nicht nur akademische Neugier. OpenAIs Codex-Guidance beschreibt PLANS.md als Moeglichkeit, einem Agenten einen lebenden Implementierungsplan zu geben: ein eigenstaendiges Dokument, das Ziel, Status, Entscheidungen und Validierungskriterien waehrend der Arbeit festhaelt.
Auch GitHubs Copilot-Dokumentation zeigt in dieselbe Richtung. Der Research-Plan-Iterate-Workflow fordert Entwickler auf, Kontext zu sammeln, Copilot um einen Implementierungsplan zu bitten, diesen Plan zu iterieren und erst dann in die Umsetzung zu gehen. Der Implementation-Planner-Custom-Agent ist noch direkter: Er soll Anforderungen in einen konkreten technischen Plan verwandeln.
Das Muster wird vertraut: Der Agent soll planen, bevor er editiert, und der Plan soll sichtbar genug bleiben, damit Menschen und andere Agenten ihn pruefen koennen.
Warum das wichtig ist
AGENTS.md loeste ein Problem: Agenten brauchen Repository-Kontext. Sie muessen Commands, Konventionen, Testerwartungen, Coding Style und projektspezifische Regeln kennen.
Aber Repository-Kontext ist nicht dasselbe wie Task-Ausfuehrung.
Eine gute Coding-Aufgabe braucht oft konkretere Anweisungen:
- welche Dateien wahrscheinlich relevant sind,
- welches Verhalten sich aendern soll,
- was sich nicht aendern darf,
- welche Edge Cases wichtig sind,
- welche Tests bestehen muessen,
- welche Validierung zeigt, dass die Aenderung fertig ist,
- welche Tradeoffs bereits betrachtet wurden.
Genau diese Luecke koennen Plan-Dateien fuellen.
Fuer Menschen wird der Plan zu einem Review-Artefakt. Fuer Agenten wird er zu einer Arbeitsspezifikation. Fuer Teams wird er zu einer Handoff-Flaeche, wenn ein Agent, ein Entwickler oder eine Session die ganze Aenderung nicht auf einmal abschliessen kann.
Die nuetzliche Version
Die nuetzliche Version ist nicht: “Der Agent schreibt einen riesigen Plan und folgt ihm blind.”
Die nuetzliche Version ist kleiner und praktischer:
- Vor groesseren Edits einen Plan verlangen.
- Im Plan relevante Dateien und Commands nennen lassen.
- Den Plan vor der Implementierung pruefen.
- Den Plan aktualisieren, wenn die Realitaet anders aussieht.
- Validierung als Teil des Plans behandeln, nicht als Nachtrag.
So wird ein Agent Plan fast zu einer leichten technischen Spezifikation.
Er macht Coding-Agent-Arbeit auch weniger undurchsichtig. Statt zu fragen “was hat der Agent getan?”, koennen Reviewer fragen: “Hat der Agent den Plan befolgt, und war der Plan gut?”
Das Risiko
Plaene koennen auch falsche Sicherheit erzeugen.
Ein sauber formulierter Plan kann trotzdem falsch sein. Er kann versteckte Kopplung uebersehen, Anforderungen falsch verstehen, Migrationsdetails auslassen oder Tests nennen, die das riskante Verhalten gar nicht abdecken.
Dazu kommt ein Wartungsproblem. Wenn Teams anfangen, Plan-Dateien zu committen, brauchen sie eine Regel dafuer, was dauerhaft bleibt. Manche Plaene sind nur waehrend der Implementierung hilfreich. Andere erklaeren Entscheidungen, die kuenftige Maintainer kennen sollten.
Wenn jede Agenten-Aufgabe veraltete Plan-Dokumente hinterlaesst, werden Repositories lauter, nicht klarer.
Worauf man achten sollte
Die naechste Frage ist, ob Plan-Dateien zu einer Konvention wie AGENTS.md werden oder ein tool-spezifischer Arbeitsstil bleiben.
Dafuer brauchen Teams praktische Antworten:
- Sollen Plaene in
docs/,.agents/,.codex/oder temporaeren Task-Ordnern liegen? - Sollen Plaene committed, an Pull Requests gehaengt oder nach dem Merge verworfen werden?
- Welche Mindestfelder sollte jeder Plan enthalten?
- Wer besitzt die Plan-Genauigkeit: Agent, Entwickler oder Reviewer?
- Sollte CI Plan-Checklisten gegen echte Commands validieren?
Die Studie ist frueh, aber die Richtung ist relevant.
Agenten lesen nicht mehr nur Repository-Anweisungen. Sie beginnen, mit expliziten Ausfuehrungsspezifikationen zu arbeiten. Das koennte eine der stillen Infrastrukturschichten hinter verlaesslicher KI-gestuetzter Softwareentwicklung werden.