← Zurück zum Blog

Die Qualität des Prompts bestimmt direkt die Qualität des Codes

Illustration, die einen vagen Prompt einem präzisen, gut strukturierten Prompt gegenüberstellt

Zwei Personen geben einem KI-Agenten scheinbar dieselbe Anfrage – und erhalten Ergebnisse von völlig unterschiedlicher Qualität. Was unterscheidet diese Anfragen tatsächlich, und woran lässt sich das erkennen, bevor die KI überhaupt zu arbeiten beginnt? Die Antwort ist eine einfache Regel: Je besser und konkreter eine Anfrage beschrieben ist, desto besser führt die KI sie aus. Das klingt selbstverständlich, ist in der Praxis aber die häufigste Ursache schlechter Ergebnisse – nicht unzureichende Fähigkeiten des Modells, sondern eine unzureichend beschriebene Anfrage.

Schlechter Prompt: „Behebe den Login-Fehler.“ Guter Prompt: „In AuthService.login() tritt ein Fehler auf, wenn ein Benutzer eine E-Mail-Adresse mit Großbuchstaben eingibt – der DB-Vergleich unterscheidet zwischen Groß- und Kleinschreibung. Korrigiere die Normalisierung der E-Mail so, dass sie VOR dem Vergleich erfolgt; fasse weder das Passwort-Hashing noch das Rate-Limiting in LoginThrottle.ts an.“

Der zweite Prompt enthält vier entscheidende Dinge, die dem ersten fehlen:

  1. Die exakte Stelle (Datei/Funktion) statt einer allgemeinen Beschreibung.
  2. Eine Beschreibung der Ursache, nicht nur des Symptoms.
  3. Genau, was zu tun ist, nicht nur „reparieren“.
  4. Was nicht kaputtgehen darf – eine ausdrückliche Grenze für die Änderung.

Ohne Punkt 4 neigt die KI dazu, Dinge zu „verbessern“, die man nie angefasst haben wollte – und genau in diesem Moment geht nachgelagerte Logik kaputt.

Es ist ähnlich, wie einem Fünfjährigen zu erklären, was zu tun ist. Man sagt ihm, was und wie, aber ebenso wichtig ist es, ihm zu sagen, was er nicht tun soll. Für ein Kind ist diese Grenze vor allem erzieherisch; für die KI ist sie eine präzise Definition dessen, was sie nicht untersuchen oder verändern darf – und diese Grenze schärft das Ergebnis weit mehr als jede Beschreibung dessen, wonach zu suchen wäre.

Dieselbe Logik gilt innerhalb eines einzelnen Prompts: Wenn man mehrere unzusammenhängende Anforderungen auf einmal hineinpackt, weiß die KI nicht, welche Vorrang hat, und interpretiert die Aufgabe oft anders als beabsichtigt. Daher die einfache Regel: ein Prompt = eine konkrete Sache.

Das gilt ebenso für handgeschriebene Prompts wie für automatisch erzeugte Tasks. Und genau diese Disziplin lässt sich automatisieren – sodass ein Prompt nicht aus dem stammt, woran sich ein Mensch gerade erinnert, sondern aus echtem, aktuellem Wissen über den Code (Contracts, DOM-Map, Geschäftslogik), das AITM für einen pflegt.

Bevor wir uns die Prompt-Struktur selbst ansehen, noch etwas Wissenswertes: AITM schreibt nicht jeden Task-Prompt auf dieselbe Weise. Wird ein Task angelegt, ordnet er sich zuerst selbst (oder man wählt) einer von drei Kategorien zu – Bug (Korrektur bestehenden Verhaltens), Enhancement (Verbesserung von etwas Vorhandenem) oder Feature (völlig neue Funktionalität) – und jede Kategorie erzeugt einen anderen Satz an Anforderungen und Verifikationskriterien. Konzentrieren wir uns zunächst auf das, was alle drei Typen gemeinsam haben: eine feste 5-Block-Struktur.

Wie AITM es tatsächlich macht – die echte Prompt-Struktur

AITM schreibt Task-Prompts nicht frei. Jeder Task-Prompt, der aus Chat oder Brainstorming erzeugt wird, besteht aus 5 festen Blöcken in dieser Reihenfolge – und jeder Block löst ein bestimmtes Problem, das sonst zu einer unklaren Aufgabe führen würde:

  1. Role (Rolle) – höchstens 3 Sätze, die beschreiben, welche Rolle und wie konservativ der Agent vorgehen soll. Ohne diesen Block weiß der Agent nicht, wie viel „Kreativität“ ihm erlaubt ist – und Kreativität ohne Leitplanken führt genau zu ungewollten Änderungen.
  2. Context (Kontext) – warum der Task existiert: die Meldung des Benutzers, die Vorgeschichte des Problems, wer den Bereich verantwortet. Er wird durch den Satz „Context (background only — implement nothing from this block)“ abgesetzt, denn ohne diesen Satz riskiert der Agent, versehentlich etwas aus der Hintergrundgeschichte umzusetzen, statt sich rein auf die Anforderungen zu konzentrieren.
  3. Requirements (Anforderungen) – pro Anforderung ein nummerierter Block, jeweils mit einem präzisen, überprüfbaren Akzeptanzkriterium. Die Aufteilung der Anforderungen in nummerierte Blöcke löst direkt das oben besprochene Problem – ein Block, eine konkrete Sache, keine Vermischung mehrerer Anforderungen in einem Satz.
  4. Scope – drei Zeilen: In scope (was geändert werden darf), Out of scope (was nicht geändert werden darf und wer dafür zuständig ist), Must not break (welche Contracts weiterhin gelten müssen). Das ist eine direkte Umsetzung der Regel „sag der KI auch, was sie nicht tun soll“ – ohne diesen Block weiß der Agent nicht, wo die Grenzen seiner Änderung liegen.
  5. Output und Verifikation – jede neue Datei, die der Task erzeugt, plus konkrete Verify-Befehle, die ausschließlich auf das begrenzt sind, was diese spezifische Änderung kaputt machen könnte. So wird der Task nicht bei „sieht fertig aus“ abgeschlossen, sondern bei einem messbaren „genau dieser Befehl ist durchgelaufen“.

Auffällig sind Contract-Verweise wie %AUTH-012 – das ist ein Verweis auf einen bestimmten Contract, eingefügt in einer exakten Syntax, die AITM erkennt und automatisch zur vollständigen Verhaltensbeschreibung expandiert. Genau das ist der Unterschied zwischen „schreib deinen eigenen Prompt“ und einem System, das präzise Struktur und Zitate für einen erzwingt.

Was ein Contract tatsächlich enthält. In AITM ist ein Contract ein Datensatz in der SQLite-Datenbank des Projekts, kein Code-Kommentar. Er hat eine kurze ID (ein Modulpräfix plus eine Nummer), ein Modul (zu welchem Teil des Systems das Verhalten gehört) und vor allem ein Feld behavior – eine präzise, mehrsätzige Beschreibung des Mechanismus, oft mit einem Verweis auf bestimmte Zeilen in einer Datei und auf die Task-Nummer, in der das Verhalten entstand. Außerdem trägt er eine Liste der Dateien, die der Contract berührt, optional eine Danger Zone und eine Liste zugehöriger Variablen. Sieht der Agent im Prompt einen Verweis unter „Must not break“, fügt AITM diese gesamte Beschreibung statt des bloßen Codes ein – so weiß der Agent genau, welches Verhalten er nicht verletzen darf.

Und Unit-Tests? Auch sie haben ihren eigenen Code – jeder Testblock in den Tests von AITM trägt am Anfang seiner Beschreibung ein eindeutiges Tag. So lässt sich ein bestimmter Test ebenso präzise ansprechen wie ein Contract. Ein Contract koppelt sich außerdem mit dem Pfad zur Testdatei, sodass ein Contract-Verweis nicht nur die Verhaltensbeschreibung trägt, sondern auch einen direkten Link zum Test, der es absichert.