Seit dem ersten Commit meines Python-Projekts galt eine Regel vor allen anderen: Der Coding-Agent darf die Akzeptanzkriterien niemals sehen. Deshalb habe ich zwei Agenten gebaut, die sich nie untereinander austauschen. Der eine schreibt die Tests anhand der vollständigen Spezifikation, und ein separater Coding-Agent schreibt den Code anhand derselben Spezifikation, aus der die Kriterien aber herausgeschnitten wurden. In den meisten Coding-Umgebungen schreibt derselbe Agent beides, was die Aussagekraft der Testergebnisse beeinträchtigt.
Den Schnitt habe ich im Code erzwungen, und zwar beim Kontextaufbau, dem Schritt, der den Prompt des Coding-Agenten erstellt. Dort wird der Kriterienabschnitt der Aufgabendatei entfernt, bevor der Prompt gebaut wird. Eine Zeit lang hielt ich diesen Schnitt für absolut dicht. Dann stellte sich heraus, dass eine einzige Kommentarzeile ihn brach: Der Schnitt endete dort, und jedes Kriterium nach dem Kommentar gelangte zum Coding-Agenten. Eine Woche später tat ein Kriterium, das auf eine zweite Zeile umgebrochen war, dasselbe. Beide Fehler waren meine. Diesmal habe ich sie behoben und Tests ergänzt, sodass künftige Builds fehlschlagen, wenn der Schnitt nicht wie vorgesehen greift.
Skills und MCP-Server werden oft gegeneinander abgewogen, doch für die Regel, auf der mein Projekt beruht, war die Antwort keines von beidem. Ich wollte, dass Nutzer qikly, mein Kommandozeilenwerkzeug, aus einem KI-Assistenten wie Claude Code oder Cursor heraus nutzen können. Damit sind zwei LLMs im Spiel, und keines von beiden sollte die Akzeptanzkriterien sehen. Der Assistent konnte qikly bereits ausführen, wusste aber nicht, wann er es tun sollte. Also schrieb ich einen Skill: einen Ordner mit Markdown-Anweisungen, den der Assistent lädt, wenn eine Anfrage zu seiner Beschreibung passt.
Beim Schreiben des Skills trennten sich zwei Aufgaben. Die Aufgabe des Skills ist es, zu beraten, was in die Anforderungen gehört und was in die Akzeptanzkriterien. Das lässt sich nur vermitteln, nicht garantieren. Die Aufgabe des Kontextaufbaus ist es, die Kriterien jedes Mal herauszuschneiden, unabhängig davon, ob ein Skill installiert ist. Der Rat bleibt trotzdem wichtig, denn ein Kriterium, das auch in den Anforderungen steht, erreicht den Coding-Agenten ohnehin. Deshalb habe ich qikly --validate eine Prüfung hinzugefügt, die vor solchen Doppelungen warnt.
Häufig gestellte Frage
F: Warum nicht auf ein besseres Modell oder eine Temperatur von null setzen, um zu verhindern, dass das LLM die Kriterien sieht?
A: Ein besseres Modell folgt Anweisungen häufiger, aber nicht immer, und eine Temperatur von null macht Antworten reproduzierbarer, aber nicht gehorsamer. Regeln, die immer gelten müssen, sollten im Code erzwungen werden, etwa durch den Kontextaufbau, während urteilsbasierte Anleitung in einem Skill stehen kann.
Quelle: Towards Data Science · Zusammengefasst von HeadlinesBriefing