Ein Prompt ist eine Arbeitsanweisung

Der wichtigste Mindset-Shift: Hör auf, Prompts wie Suchmaschinen-Anfragen zu behandeln. Behandel sie wie Arbeitsanweisungen. Eine Arbeitsanweisung erklärt, was zu tun ist, was nicht zu tun ist, und was am Ende rauskommen soll.

Wenn man jemandem im Team eine Aufgabe gibt, sagt man nicht nur "mach das mit dem Cache". Man erklärt kurz, worum es geht, was wichtig ist, in welchem Format das Ergebnis gebraucht wird, was Risiken sind. Genau dieselben Elemente gehören in einen guten Prompt.

Fünf Bausteine

Aus längerem Experimentieren haben sich fünf Elemente als Gerüst herausgestellt:

  • Ziel: Was soll am Ende erreicht sein? Woran erkenne ich, dass die Aufgabe erledigt ist?
  • Kontext: Sprache, Framework, Constraints, Datenstrukturen. Was das Modell wissen muss, um spezifisch zu antworten.
  • Format: Codeblock? Schritt-für-Schritt? Diff? Nur Code, keine Erklärung? Ohne Vorgabe entscheidet das Modell selbst.
  • Grenzen: Was nicht passieren soll. Welche Änderungen sind tabu, welche Annahmen darfst du nicht machen.
  • Verifikation: Woran erkennt man, dass die Antwort stimmt. Test-Beschreibung, Erfolgskriterium, Beispiel-Output.

Häufige Fehler

  • Zu offene Fragen: "Wie verbessere ich diesen Code?" — verbessern wofür? Performance, Lesbarkeit, Sicherheit?
  • Fehlender Kontext: Eine Frage zu Code ohne den Code. Das Modell muss raten, Raten führt zu Halluzinationen.
  • Mehrere Aufgaben in einem Prompt: "Schreibe, optimiere, dokumentiere und teste." Keine der vier Aufgaben wird tief genug bearbeitet.
  • Keine Grenzen: Ohne explizite Grenzen erlaubt sich das Modell Library-Wechsel, Architektur-Änderungen, Komplettumbauten.
  • Höflichkeitsfloskeln statt Substanz: "Bitte hilf mir freundlich..." kostet Tokens, gibt aber keine Information.

Iteration gehört dazu

Ein guter Prompt entsteht oft nicht im ersten Wurf. Der erste Versuch ist eine Annäherung, der zweite verfeinert, der dritte ist meistens präzise. Diese Iteration kostet keine Zeit — sie spart Zeit.

Was hilft beim Iterieren: ehrlich prüfen, an welcher der fünf Stellen der erste Prompt gehakt hat. War das Ziel zu vage? Fehlte Kontext? Daraus folgt der nächste Versuch.

Gute Prompts festhalten

Sobald ein Prompt für eine Aufgabe gut sitzt, wandert er bei mir in eine zentrale Sammlung: Code-Reviews, Bug-Diagnosen, Refactoring-Pläne, PR-Beschreibungen. Pro Aufgabentyp ein bewährter Prompt, der über Wochen verfeinert wurde.

Im Team ist das noch wertvoller: eine geteilte Sammlung guter Prompts ist eine der unterschätztesten Formen von Engineering-Wissen.

Was schlechte Antworten sagen

Schlechte Antworten sind eine Lernquelle. Kam die Antwort generisch? Fehlte Kontext. Hat das Modell eine andere Frage beantwortet? Das Ziel war unklar. Kam sie in einem unpassenden Format? Die Format-Vorgabe fehlte.

Wer schlechte Antworten als Feedback für den eigenen Prompt liest, lernt schneller als jemand, der sie dem Modell zuschreibt.