DE
Lektion 1.5

Mit Agents reden: Prompt Engineering, das wirklich funktioniert

Einen Coding Agent so briefen, dass er beim ersten Mal grossartige Arbeit liefert - mit Axiomen, Framing, Pushback und Spec Sheets

24 minGrundlagen - Von null zur ersten veröffentlichten AppVerfügbar

Was du lernst

  • Axiome und Verträge: nicht verhandelbare Regeln festlegen, damit der Agent aufhört, sie neu zu entscheiden
  • Das Unlimited-Budget-Framing und um Widerspruch bitten, um die Output-Qualität zu heben
  • Ein Spec Sheet schreiben, das eine vage Idee in ein ausführbares Briefing verwandelt

Überblick

Der mit Abstand grösste Sprung bei den Ergebnissen kommt nicht von einem besseren Modell, sondern von einem besseren Briefing. Gut mit einem Agent zu reden ist eine Führungskompetenz: du setzt klare Regeln, framest die Arbeit auf Qualität statt Abkürzungen, lädst Widerspruch ein und übergibst eine Spezifikation statt eines Bauchgefühls. Diese Lektion gibt dir die konkreten Muster, die frustrierende Sessions von Agents trennen, die es beim ersten Mal treffen.

Was du lernst

Du lernst, Axiome zu schreiben (nicht verhandelbare Regeln), das Unlimited-Budget-Framing zu nutzen, das den Agent vom Ecken-Abschneiden abhält, explizit um Widerspruch zu bitten, damit der Agent deine Fehler fängt, und eine vage Anfrage in ein Spec Sheet mit Ziel, Kontext, Constraints und Akzeptanzkriterien zu verwandeln.

Voraussetzungen

Ein funktionierendes Claude-Code- oder Codex-Setup aus der vorigen Lektion. Du solltest dich auch an die Kontext-Lektionen erinnern: ein grossartiger Prompt besteht teils darin, den richtigen Kontext zu geben, nicht nur die richtigen Worte.

Das Problem

Das klassische Scheitern ist der einzeilige Wunsch: "bau mir eine Website". Der Agent muss die Zielgruppe, den Stack, das Design, den Umfang und die Definition von "fertig" raten, und er rät falsch. Dann gibst du der KI die Schuld. Das eigentliche Problem ist, dass du einen Dienstleister mit fünf Worten gebrieft und ein fertiges Haus erwartet hast. Gutes Prompten nimmt das Raten weg.

Axiome: die Regeln einmal festlegen

Axiome sind nicht verhandelbare Regeln, die du vorab festlegst, damit der Agent aufhört, sie bei jeder Aufgabe neu zu entscheiden. Statt dasselbe zehnmal zu korrigieren, schreibst du es als Regel. "Nutze immer TypeScript. Verwende nie Em-Dashes. Jedes neue Feature braucht einen Test. Committe nie Secrets." Die lesen sich wie ein Vertrag, und der Agent behandelt sie als Constraints statt als Vorschläge. In Kurs 2 verschiebst du diese in eine dauerhafte CLAUDE.md, aber selbst oben in eine Session eingefügt heben sie die Konstanz deutlich.

  • Formuliere Regeln als Absolute: "Immer...", "Nie...", "Jedes... muss...".
  • Deck Stil, Stack, Tests, Sicherheit und Ton ab - die Dinge, die du immer wieder korrigierst.
  • Halt sie kurz und eindeutig; ein Agent folgt einer knackigen Regel besser als einem Absatz voller Nuancen.

Das Unlimited-Budget-Framing

Agents tendieren wie Junior-Mitarbeitende zur schnellsten akzeptablen Antwort. Wenn du Weltklasse-Arbeit willst, musst du das sagen. Die Aufgabe so zu framen, als wären Budget und Zeit unbegrenzt - "tu das Richtige für die langfristige Gesundheit dieses Projekts, nicht das Einfache; schneide keine Ecken ab" -, hebt die Qualität messbar, weil es dem Agent erlaubt, Tests zu ergänzen, Randfälle zu behandeln und zu refaktorieren, statt den schnellsten Fix draufzuschrauben. Es klingt weich, aber es verschiebt den Output verlässlich von "funktioniert technisch" zu "ist tatsächlich gut".

Um Widerspruch bitten

Standardmässig ist ein Agent zustimmend und setzt eine schlechte Idee bereitwillig um. Die Lösung ist ein Satz: "Bevor du anfängst, sag mir alles, was an diesem Plan falsch ist, alles, was ich übersehen habe, und einen besseren Ansatz, falls es einen gibt." Das macht aus dem Agent statt eines Befehlsempfängers einen Berater. Er fängt fehlende Anforderungen, weist auf Sicherheitslücken hin und schlägt einfachere Designs vor. Einige der wertvollsten Momente in agentischer Arbeit kommen daher, dass der Agent dir widerspricht - aber nur, wenn du ihm dafür explizit die Erlaubnis gibst.

Schritt für Schritt: ein Spec Sheet schreiben

Ein Spec Sheet ist der Unterschied zwischen einem vagen Wunsch und einem ausführbaren Briefing. Es muss nicht lang sein. Vier Teile reichen, und sie zu schreiben zwingt dich, die Entscheidungen zu treffen, die der Agent sonst raten würde.

  • Ziel: was existieren soll, wenn das fertig ist, in ein bis zwei Sätzen.
  • Kontext: der Stack, die relevanten Dateien, Beispiele zum Folgen und alles, was der Agent nicht ableiten kann.
  • Constraints: deine Axiome plus aufgabenspezifische Grenzen (keine neuen Dependencies, muss auf Mobile funktionieren, und so weiter).
  • Akzeptanzkriterien: eine konkrete Checkliste, die "fertig" definiert, damit du und der Agent wissen, wann Schluss ist.
## Ziel
Ein Kontaktformular auf der Landingpage, das mir Eingaben per E-Mail schickt.

## Kontext
- Stack: dieses Astro-Projekt, vorhandene Styles in src/styles.
- Folge dem Button-Stil, der bereits in der Hero-Section genutzt wird.

## Constraints
- Nur TypeScript. Keine neue UI-Library.
- Den E-Mail-API-Key nie im Client-Code offenlegen.
- Einen Test für die Formularvalidierung ergänzen.

## Akzeptanzkriterien
- [ ] Formular validiert Name und E-Mail vor dem Absenden.
- [ ] Absenden zeigt eine Erfolgsmeldung.
- [ ] Der Validierungstest besteht.
Ein minimales, aber vollständiges Spec Sheet, das du in den Agent einfügen kannst

Typische Fehler

Die wiederkehrenden Fehler: der einzeilige Wunsch ohne Spec; nie Axiome festlegen, sodass du dieselben Dinge ewig korrigierst; die erste Antwort akzeptieren, statt um Widerspruch zu bitten; und den Prompt mit irrelevantem Kontext vollstopfen, was den Performance-Cliff aus Lektion eins auslöst. Knappe, strukturierte Briefings schlagen lange, weitschweifige.

Business-ROI

Briefing-Kompetenz ist der Multiplikator auf alles andere. Derselbe Agent und dasselbe Modell liefern mittelmässige oder hervorragende Arbeit, je ganz nach Briefing, und ein gutes Spec Sheet verwandelt oft drei frustrierende Runden in eine saubere Lieferung. Für eine Gründerin ist es der günstigste mögliche Weg, den Wert jedes KI-Abos, das du ohnehin zahlst, zu verdreifachen.

Checkliste

Bevor du weitergehst, stell sicher, dass du jedes davon auf Abruf produzieren kannst, denn jede spätere Lektion setzt voraus, dass du einen Agent gut briefen kannst.

  • Eine kurze Liste von Axiomen für deine eigenen Projekte.
  • Eine auf Qualität geframte Aufgabe mit den Zeilen Unlimited-Budget und Pushback.
  • Ein vierteiliges Spec Sheet für ein echtes Feature.
  • Ein ehrliches Gespür dafür, wann dein Prompt zu lang ist, nicht zu kurz.

Ressourcen

Speichere deine Axiome irgendwo wiederverwendbar - du fügst sie in Kurs 2 in eine CLAUDE.md ein. Das Agent-Task-Brief-Template in der Ressourcen-Bibliothek ist ein fertiges Spec-Sheet-Gerüst zum Kopieren. Als Nächstes setzt du all das ein, um ein echtes Projekt zu bauen.

Deine Aufgabe

Nimm die Projektidee, die du vor zwei Lektionen gewählt hast, und schreib ein vollständiges Spec Sheet für ihr erstes Feature, inklusive deiner Axiome, dem Unlimited-Budget-Framing und der Pushback-Bitte. Übergib es deinem Agent und beachte, wie viel schärfer das Ergebnis ist, als es ein einzeiliger Prompt wäre.

Nächste Lektion

Du kannst einen Agent briefen. Jetzt baust du etwas Echtes. Die nächste Lektion scaffoldet ein echtes Projekt, startet einen Dev Server, damit du es im Browser siehst, und stellt es unter Versionskontrolle mit Git und einem privaten GitHub-Repo.

Kommentare

Kommentare werden geladen.

Kommentar schreiben
KommentareWeiter
Nächster Schritt

Bereit, KI als Workflow zu nutzen?

Starte mit dem Starter-Pfad, speichere deinen Fortschritt lokal und synchronisiere alles später kostenlos mit deinem Konto.