Worum es geht: Die häufigste Ursache für unbrauchbaren Agentencode ist keine technische, sondern eine sprachliche: Die Aufgabe war nicht klar genug beschrieben. Diese Lektion zeigt, woraus eine Beschreibung besteht, die ein Agent zuverlässig umsetzen kann.
1. Kontext zuerst
Bevor eine einzelne Aufgabe beschrieben wird, braucht der Agent das Projekt: Wie ist es aufgebaut, welche Bibliotheken werden verwendet, wie heißen die Dinge hier, welche Regeln gelten. Bei den meisten Werkzeugen gehört das in eine Datei im Projektverzeichnis, die automatisch gelesen wird.
| Abschnitt | Inhalt |
|---|---|
| Was ist das | Zweck des Projekts in drei Sätzen |
| Aufbau | Welche Ordner wofür, wo liegen Komponenten, Daten, Tests |
| Regeln | Sprache der Bezeichner, Umgang mit Typen, was verboten ist |
| Befehle | Wie startet man, wie prüft man, wie baut man |
| Beispiele | Eine gute Datei je Muster – wirkt stärker als jede Beschreibung |
Der letzte Punkt wird unterschätzt. Ein Agent übernimmt Stil und Struktur aus vorhandenem Code deutlich zuverlässiger, als er Regeln in Prosa befolgt. Ein sauberes Beispiel ist die beste Anweisung.
2. Die sechs Teile einer Spezifikation
Was der Nutzer danach kann, in einem Satz. „Ein Interessent kann eine Anfrage mit Maßangabe senden und bekommt eine Bestätigung.“ Ohne diesen Satz baut der Agent, was er für üblich hält.
3. Zwei Beispiele
So nicht: „Bau mir ein Kontaktformular.“ Der Agent entscheidet dann selbst über Felder, Pflichtangaben, Prüfregeln, Fehlertexte, Speicherort und Versand – und trifft dabei ein Dutzend Entscheidungen, die eigentlich Ihnen gehören.
Besser: „Formular mit vier Feldern: Name (Pflicht), E-Mail (Pflicht, Format prüfen), Fläche in m² (Pflicht, Zahl über 0), Anliegen (Freitext, optional). Bei Fehlern: Meldung am betroffenen Feld, Eingaben bleiben erhalten. Bei Erfolg: Bestätigung mit dem Satz „Wir melden uns innerhalb eines Werktags“. Speichern über die bestehende Funktion in lib/anfragen.ts. Kein Versand von E-Mails in diesem Schritt. Bestehende Komponenten und Stile verwenden, keine neuen Abhängigkeiten.“
4. Kleine Schritte
Eine Aufgabe, die ein Agent in einem Durchgang lösen kann, sollte etwa dem entsprechen, was ein Mensch in ein bis zwei Stunden schafft. Größere Aufgaben werden geteilt – nicht, weil der Agent es nicht könnte, sondern weil die Durchsicht sonst unmöglich wird. Zwanzig geänderte Dateien liest niemand sorgfältig.
Zwischen den Schritten wird geprüft und committet. Das erzeugt eine Kette nachvollziehbarer Zustände statt eines einzigen großen Sprungs, dessen Fehler sich nicht mehr zuordnen lassen.
5. Was in den Kontext gehört – und was nicht
Hinein gehört, was der Agent für diese Aufgabe braucht: die betroffenen Dateien, das Datenmodell, die Regeln. Nicht hinein gehört der gesamte Quelltext des Projekts – das kostet Geld, verwässert die Aufmerksamkeit und macht die Antworten schlechter. Und keinesfalls hinein gehören Schlüssel, Zugangsdaten oder personenbezogene Daten.
6. Häufige Fragen
Wie lang darf eine Spezifikation sein? Eine halbe Seite je Aufgabe ist üblich. Wird sie länger, ist die Aufgabe zu groß geschnitten.
Soll man Lösungswege vorgeben? Nur wenn es darauf ankommt. Meist ist es besser, das Ergebnis genau zu beschreiben und den Weg offen zu lassen – aber die Einschränkungen zu nennen.
Was, wenn der Agent nachfragt? Antworten und die Antwort anschließend in den dauerhaften Kontext übernehmen. Jede Frage, die zweimal kommt, ist eine Lücke in der Projektbeschreibung.
Stand: September 2026. Die Übungen laufen vollständig in Ihrem Browser – es wird nichts gespeichert oder übertragen.