Viele Entwicklungsteams haben in den letzten Jahren eigene Prompt- und Skill-Sammlungen aufgebaut: Textbausteine, die einem KI-Assistenten erklären, wie im Projekt gearbeitet wird, welche Dateien er vorab lesen soll und welche Schritte er niemals ohne Rückfrage ausführen darf. Diese Bibliotheken sind mitgewachsen, meist ohne dass jemand sie wieder verkleinert hätte. Genau das wird nun zum Problem.

Was OpenAI beobachtet

Eric Provencher, Entwickler bei OpenAI, weist darauf hin, dass umfangreiche Skill-Beschreibungen, pauschale Lesepflichten und starre Freigaberegeln das Modell GPT-6 Astra in Codex ausbremsen können. Der Hintergrund: Leistungsfähigere Modelle benötigen weniger kleinteilige Anleitung als ihre Vorgänger. Was früher notwendige Führung war, wird heute zu Ballast.

Die Empfehlung fällt entsprechend nüchtern aus. Anweisungen sollen aufgabenbezogen gekürzt werden, statt generell für alle Fälle zu gelten. Und statt jeden Arbeitsschritt vorzuschreiben, sollen Teams klare Fertigstellungskriterien definieren – also festlegen, wann eine Aufgabe als erledigt gilt.

Warum das plausibel ist

Prompt-Bibliotheken entstehen reaktiv. Ein Assistent vergisst eine Konvention, also kommt eine Regel dazu. Er ändert eine Datei, die er nicht anfassen sollte, also kommt eine Verbotsliste dazu. Er liest den Kontext nicht, also wird das Lesen verpflichtend gemacht. Jede einzelne Ergänzung war zu ihrem Zeitpunkt sinnvoll.

Das Ergebnis ist ein Regelwerk, das auf die Schwächen eines bestimmten Modellstands zugeschnitten ist. Wechselt das Modell, bleibt die Anleitung stehen. Sie beschreibt dann Probleme, die es nicht mehr gibt, und verengt gleichzeitig den Spielraum für Lösungswege, die das neue Modell von sich aus finden würde.

Vorgaben, die besonders schnell veralten

  • Pauschale Lesepflichten: Anweisungen, vor jeder Aufgabe bestimmte Dateien oder Dokumentationen komplett zu lesen, unabhängig davon, ob sie zur Aufgabe passen.
  • Schritt-für-Schritt-Choreografien: Detaillierte Ablaufvorgaben, die dem Modell die Reihenfolge vorschreiben, statt das Ziel zu beschreiben.
  • Starre Freigaberegeln: Rückfragepflichten, die bei jedem Handgriff greifen und den Ablauf zerstückeln.
  • Redundante Erklärungen: Ausführliche Beschreibungen von Konzepten, die das Modell längst beherrscht.

Nicht jede dieser Vorgaben ist überflüssig. Freigabepflichten bei Datenbankmigrationen, Deployments oder Änderungen an Produktionskonfigurationen haben ihren Grund und sollten bleiben. Die Frage ist, ob eine Regel ein tatsächliches Risiko absichert oder nur eine alte Modellschwäche kompensiert.

Fertigstellungskriterien statt Arbeitsanweisungen

Der interessantere Teil des Hinweises ist die Umstellung auf Fertigstellungskriterien. Statt zu beschreiben, wie gearbeitet werden soll, wird beschrieben, wie das Ergebnis aussehen muss: Welche Tests müssen grün sein? Welche Prüfungen müssen durchlaufen? Welche Dokumentation muss aktualisiert sein? Welche Schnittstellen dürfen sich nicht verändert haben?

Dieser Ansatz ist robuster gegenüber Modellwechseln. Ein Kriterium wie "die bestehende Testsuite läuft ohne Fehler durch" bleibt gültig, egal welches Modell die Arbeit erledigt. Eine Anweisung wie "lies zuerst diese vier Dateien" ist an einen konkreten Modellstand gebunden.

Nebenbei zwingt die Umstellung Teams zu einer nützlichen Klärung: Wer Fertigstellungskriterien formulieren will, muss wissen, was Qualität im eigenen Projekt bedeutet. Diese Frage lohnt sich auch dann, wenn kein KI-Assistent beteiligt ist.

Ein Wartungsthema, kein Einmalprojekt

Prompt- und Skill-Bibliotheken sind Teil der Projektinfrastruktur, vergleichbar mit Build-Konfigurationen oder Linter-Regeln. Sie brauchen Pflege, und zwar nicht nur in Form von Ergänzungen. Ein pragmatischer Rhythmus wäre, die Sammlung immer dann durchzusehen, wenn ein neues Modell in den Arbeitsablauf kommt.

Dabei hilft ein einfaches Vorgehen: Jede Regel wird darauf befragt, welches konkrete Problem sie einmal gelöst hat. Existiert dieses Problem noch? Wenn niemand im Team die Antwort kennt, ist das ein Hinweis darauf, dass die Regel testweise entfernt werden kann. Versionierung macht solche Experimente risikoarm, weil sich jede Änderung zurücknehmen lässt.

Wichtig ist außerdem, dass die Wirkung messbar bleibt. Wer nicht verfolgt, wie viele Nacharbeiten ein Assistent verursacht oder wie oft Vorschläge im Review scheitern, kann auch nicht beurteilen, ob eine Kürzung geholfen oder geschadet hat.

Was das für Web- und Softwareprojekte bedeutet

Wer KI-Assistenten fest in seine Entwicklungsprozesse eingebaut hat, sollte die begleitenden Anweisungen als wartungspflichtigen Bestandteil des Projekts behandeln – mit regelmäßiger Durchsicht und der Bereitschaft, Regeln auch wieder zu löschen. Der Aufwand dafür ist gering, der Effekt auf Tempo und Ergebnisqualität kann deutlich sein. Und die Verschiebung von Arbeitsanweisungen zu klaren Fertigstellungskriterien zahlt sich doppelt aus: Sie macht die Zusammenarbeit mit Assistenten stabiler und schärft gleichzeitig das eigene Qualitätsverständnis im Team.

Quellen