Werkzeuge eingerichtet, die passende Wahl verstanden. Als Nächstes wird „wie man die KI bittet“ entscheidend. Selbst bei ein und demselben Claude Code ändert sich die Qualität des Ergebnisses mit der Art der Anweisung um ein Vielfaches. In diesem Kapitel eignen Sie sich die Kunst des „guten Bittens“ an – entlang der beiden großen Stile im Umgang mit der KI: dem Vibe Coding, bei dem man locker im Gespräch baut, und der spezifikationsgetriebenen Entwicklung, bei der man erst die Spezifikation festlegt und dann genau bauen lässt. Hier liegt der wichtigste Angelpunkt des KI-Codings.
Das Losungswort: „klein und explorierend → vibe, groß und genau → spec“
Die Qualität der Anweisung entscheidet über das Ergebnis
Woran man beim KI-Coding zuerst scheitert, ist meist nicht die „Bedienung des Werkzeugs“, sondern die „Art zu bitten“. Die KI kann nicht in Ihrem Kopf lesen. Geben Sie ihr eine vage Bemerkung, rät die KI die fehlenden Teile eigenmächtig zusammen und liefert Code, der zwar plausibel läuft, aber von Ihrer Absicht abweicht. Umgekehrt: Können Sie treffend vermitteln, was, warum und wie gebaut werden soll, fertigt sie es erstaunlich genau. „Die Qualität der Anweisung“ wird unmittelbar zur „Qualität des Ergebnisses“ – das ist die zentrale Botschaft dieses Kapitels. Und für diese Art zu bitten gibt es im Wesentlichen zwei Stile.
Vibe Coding – im Gespräch bauen
Vibe Coding ist ein Stil, bei dem man das feine Design nicht vorab festzurrt, sondern im Gespräch mit der KI durch Ausprobieren baut. Man teilt grob mit „so etwas in der Art hätte ich gern“, sieht das Ergebnis und verfeinert im Dialog mit „etwas mehr so“, „ändere hier das“, und lässt es dem Gespür (dem „vibe“) folgend Gestalt gewinnen. Der größte Reiz: Es ist unkompliziert, explorativ und lässt Ideen auf einen Schlag Form annehmen.
🎨 Bildlich: Wie das Formen von Ton, das man knetet, ohne einen Bauplan zu zeichnen. Weil man „beim Bauen denkt“, kann man selbst bei noch nicht ausgereiften Ideen erst einmal Hand anlegen und sie überprüfen.
Stellen wir passende Situationen und die zu beachtenden Fallstricke nebeneinander.
- Kleines: Einzelskripte, einfache Werkzeuge, Ein-Bildschirm-Apps.
- Prototyp/Versuch: wenn Sie an der Gestalt urteilen wollen. Experimente, die man verwerfen darf.
- Lernen/Trockenübung: wenn Sie eine neue Technik anfassen und ein Gefühl dafür bekommen wollen.
- Das Gesamtdesign wackelt: Mit jedem Gespräch schwankt die Marschrichtung, die Konsistenz geht leicht verloren.
- Bricht bei wachsendem Umfang zusammen: Je mehr Dateien, desto weniger überblicken KI und Mensch das Ganze.
- Der Inhalt wird zur Blackbox: Es häuft sich Code an, der läuft, dessen Funktionsweise man aber nicht erklären kann.
💡 In einem Satz: Vibe Coding ist zum „schnellen Ausprobieren“ unschlagbar, aber zum „groß aufziehen und lange pflegen“ ungeeignet. Klein, wegwerfbar, explorativ – diese drei Worte als Richtschnur, dann geht seltener etwas schief.
Spezifikationsgetriebene Entwicklung – erst festlegen, dann genau bauen
Die spezifikationsgetriebene Entwicklung (spec-driven development) ist ein zum Vibe Coding gegensätzlicher Stil. Bevor man beginnt, Code zu schreiben, fasst man „was und wie gebaut wird“ als Spezifikation in einem Dokument zusammen und übergibt diese Spezifikation der KI, damit sie genau umsetzt. Statt aufs Geratewohl zu plaudern, lässt man die KI entlang eines abgestimmten Bauplans laufen.
Das Vorgehen ist einfach. Zuerst erstellt man im Austausch mit der KI die Spezifikation, legt sie (meist als Datei) ins Projekt und treibt die Umsetzung voran, während man auf diese Spezifikation verweist.
Zweck, Funktionen, Ein-/Ausgabe und Einschränkungen in Worte fassen. Schneller, wenn die KI einen Entwurf macht und Sie ihn korrigieren.
Vor der Umsetzung die Spezifikation selbst lesen und Lücken und Widersprüche ausräumen. Hier entscheidet sich die Qualität.
„Setze gemäß dieser Spezifikation um“ anweisen. Weicht es ab, zur Spezifikation zurückkehren und korrigieren.
- Etwas Größeres: Entwicklung über mehrere Funktionen und Dateien.
- Qualität im Vordergrund: Dinge, deren späterer Bruch teuer wird und die lange gepflegt werden.
- Team oder Dritte lesen mit: Die Spezifikation wird zum gemeinsamen Bezugspunkt.
- Nicht von Anfang an Perfektion anstreben, sondern auch die Spezifikation klein beginnen und wachsen lassen.
- Die Spezifikation lesen Sie unbedingt selbst. Eine ganz der KI überlassene Spezifikation wird löchrig.
- Weicht die Umsetzung ab, nicht im Gespräch improvisiert korrigieren, sondern erst die Spezifikation korrigieren und neu beginnen.
📐 Warum es wirkt: Die KI sieht nur „dieses aktuelle Gespräch“. Legt man mit der Spezifikation vorab einen Maßstab, zu dem man jederzeit zurückkehren kann, wackelt die Marschrichtung auch bei langen Gesprächen nicht, und Lücken und Rückarbeit nehmen ab. Im Grunde ist es nur „der KI einen Bauplan geben und dann bauen lassen“, doch die Wirkung ist enorm.
Die passende Wahl – klein explorieren oder groß und genau
Es geht nicht darum, welcher überlegen ist. Richtig ist, nach „Umfang“ und „Zweck“ des Gebauten zu wählen. Stellen wir die beiden Stile achsenweise gegenüber.
| Umfang | klein |
| Zweck | Prototyp, Exploration, Lernen |
| Vorgehen | Ausprobieren im Gespräch |
| Tempo | sehr schnell |
| Schwäche | bricht bei Wachstum zusammen |
| Umfang | mittel bis groß |
| Zweck | Qualität, Pflege, Produktivbetrieb |
| Vorgehen | Spezifikation → Umsetzung |
| Tempo | langsamer Anlauf |
| Schwäche | für Kleinkram zu schwer |
✅ In der Praxis „wechselt“ man hin und her. Man muss sich nicht auf ein Entweder-oder festlegen. Zuerst mit Vibe Coding schnell einen Prototyp bauen, und sobald sich ein tragfähiges Gefühl einstellt, in eine Spezifikation überführen und zur richtigen Umsetzung übergehen – dieser Ablauf ist in der Praxis am stärksten. Kleine Exploration → vibe, die Ausbauphase → spec. Wechseln Sie den Stil innerhalb eines Projekts.
Fünf Kniffe für gute Anweisungen
Bei beiden Stilen steigt das Ergebnis, wenn die Anweisung (der Prompt) an die KI gut ist. Prägen Sie sich fünf grundlegende Kniffe ein, die ab heute nutzbar sind, als Karten. Zur Vertiefung geht es zum Praxisleitfaden Prompt-Engineering.
Nicht „mach's schön“, sondern konkret, was wie geschehen soll. Je klarer Werte, Bedingungen und Ziel benannt, desto genauer.
Verwendete Sprache, Framework, betroffene Dateien und Einschränkungen mitteilen. Je mehr Hintergrund, desto treffender die KI.
Nicht alles auf einmal bitten. Klein abgegrenzt, eins nach dem anderen – dann fallen Prüfen und Korrigieren leichter.
Die gewünschte Form (Funktionsname, Rückgabewert, Ausgabebeispiel, Format) vorab zeigen. Ein geteiltes Ziel verhindert Abweichung.
Nicht in einem Schuss Perfektion anstreben. Die Ausgabe ansehen und „hier so“ konkret nachkorrigieren ist schneller.
In Worten allein ist es schwer greifbar, darum stellen wir dieselbe Bitte als „schlechte Anweisung“ und „gute Anweisung“ nebeneinander.
„Bau eine Login-Funktion.“
Weder Sprache noch Speicherort noch Verhalten bei Erfolg/Misserfolg klar. Die KI füllt alles mit Vermutungen und liefert Code, der von Ihrer Vorstellung abweicht. Ursache für Rückarbeit.
„Füge dem Laravel-Projekt eine Login-Funktion mit E-Mail und Passwort hinzu. Nutze die bestehende Tabelle users. Bei erfolgreicher Authentifizierung zu /dashboard, bei Misserfolg eine Fehlermeldung anzeigen. Beim Passwort das bestehende Hash-Verfahren einhalten. Schlage zunächst nur routes und Controller vor, die Umsetzung erst nach meiner Prüfung.“
Zweck, Kontext, Erfolgsbedingung, Ausgabeumfang und Vorgehen sind benannt. Alle fünf Kniffe stecken drin.
🧩 Einen Schritt weiter: Der Denkansatz, nicht nur „was man der KI mitteilt“, sondern projektweit zu entwerfen, welche Informationen wie zugeführt werden, heißt Context Engineering; der Ansatz, die Umgebung, in der die KI arbeitet (Werkzeuge, Rechte, Anweisungsdateien), gesamthaft einzurichten, heißt Harness Engineering. Wenn Sie besser werden möchten, werfen Sie einen Blick hinein.
Wenn die KI Regeln ignoriert
Claude Code hat einen Mechanismus, um projektbezogene Anweisungen in einer Datei wie CLAUDE.md zu bündeln und die KI stets daran zu binden. In der Praxis stößt man jedoch auf Situationen, in denen die „eigentlich geschriebene Regel von der KI ignoriert wird“. Dafür gibt es mehrere Ursachen.
Sind die Regeln riesig, geht Wichtiges unter. Die Anzahl reduzieren, Prioritäten klarmachen.
Auslegungsspielraum wird nicht befolgt. Konkret und überprüfbar schreiben.
Zieht sich der Austausch, verblasst die anfängliche Anweisung. An Schlüsselstellen daran erinnern hilft.
💡 Kern der Gegenmaßnahme: Regeln „kurz, konkret und mit Priorität“ schreiben. Und wichtige Regeln bei Bedarf noch einmal im Gespräch nachdrücklich in Erinnerung rufen. Die genaue Ursachenabgrenzung und konkrete Behebung erklärt Warum die KI die CLAUDE.md-Regeln ignoriert und was hilft.
- Die Qualität der Anweisung ist die Qualität des Ergebnisses. Die KI füllt Fehlendes mit Vermutungen; je treffender die Bitte, desto genauer die Antwort.
- Vibe Coding = ausprobieren im Gespräch. Stark bei klein, wegwerfbar, explorativ. Bricht bei Wachstum zusammen.
- Spezifikationsgetriebene Entwicklung = erst Spezifikation festlegen, dann genau umsetzen. Stark bei mittel bis groß, qualitätsbetont.
- Die passende Wahl: „klein und explorierend → vibe, groß und genau → spec“. In der Praxis wechselt man hin und her.
- Die Kniffe guter Anweisungen sind die fünf: Konkretisieren, Kontext, eine Aufgabe je Bitte, Ausgabebeispiel, Iterieren.
- Die KI ignoriert Regeln, weil die Anweisung lang, vage oder das Gespräch lang ist. Kurz und konkret, mit Nachdruck.
Ist die Art zu bitten klar, wird KI-Coding auf einen Schlag stabil. Legen Sie dennoch tatsächlich Hand an, stoßen Sie unweigerlich auf Fehler und Sackgassen. Erfassen wir im nächsten Kapitel 5 „Aus Sackgassen herauskommen“ systematisch die Ursachen häufiger Fehler und die Wege heraus.