Ein Programmier-Prompt ist eine Spezifikation. Das Modell hat dein Projekt nicht gesehen, weiß nicht, welche Version der Sprache du verwendest, und kann nicht fragen, was bei leerem Input passieren soll. Was der Prompt weglässt, füllt es mit der häufigsten Wahl aus seinen Trainingsdaten, und die häufigste Wahl ist oft nicht deine. Die Prompts unten lassen dem Modell weniger zu raten.
Schreib die Spezifikation vor dem Code
Der Block unten bittet um eine kleine Python-Funktion. Jeder Baustein des Prompts beantwortet eine Frage, die das Modell sonst für dich beantworten würde. Schalte die Bausteine nacheinander aus und stell dir die Antwort ohne sie vor: Ohne die Vorgaben bekommst du vielleicht eine Fremdbibliothek, ohne den Kontext muss das Modell raten, was als gültiger Input zählt, ohne das Format bekommst du vielleicht keine Tests.
Die Funktion erkennt die drei optionalen Teile in ihrer Reihenfolge und lehnt einen Treffer ab, bei dem alle drei leer sind.
import re
_PATTERN = re.compile(r"(?:(\d+)h)?(?:(\d+)m)?(?:(\d+)s)?")
def parse_duration(text: str) -> int:
match = _PATTERN.fullmatch(text)
if not match or not any(match.groups()):
raise ValueError(f"invalid duration: {text!r}")
hours, minutes, seconds = (int(g) if g else 0 for g in match.groups())
return hours * 3600 + minutes * 60 + seconds
import pytest
from duration import parse_duration
@pytest.mark.parametrize("text, expected", [
("1h30m", 5400), ("45m", 2700), ("2h", 7200), ("90s", 90),
])
def test_valid(text, expected):
assert parse_duration(text) == expected
@pytest.mark.parametrize("text", ["", "1m1h", "1.5h"])
def test_invalid(text):
with pytest.raises(ValueError):
parse_duration(text)
Vier Details in diesem Prompt machen den Großteil der Arbeit:
- Beispiele mit ihren Ergebnissen. "1h30m ergibt 5400" ist ein Test, an dem das Modell seinen eigenen Code prüfen kann, und es räumt jeden Zweifel an der Einheit aus.
- Die Sprachversion und die erlaubten Bibliotheken. Ohne sie bekommst du vielleicht eine Bibliothek, die du nicht installiert hast, oder Syntax, die neuer ist als dein Interpreter.
- Was als ungültig zählt und was dann passieren soll. Fehlerbehandlung lässt ein Modell leicht weg, wenn niemand danach fragt.
- Tests in der Antwort. Sie machen aus "sieht richtig aus" etwas, das du ausführen kannst. Wenn ein Test fehlschlägt, fügst du den Fehler wieder ein, und das ist eine viel bessere Rückmeldung als "funktioniert nicht".
Auch die Prüfung any(match.groups()) verdient einen Blick: Das Muster allein passt auf einen leeren String, weil jeder Teil optional ist. Erst die Zeile im Prompt über den leeren String sorgt dafür, dass dieser Fall im Code und in den Tests auftaucht.
Nenn die Version, den Stack und was schon existiert
Modelle neigen zu dem Stil, der in ihren Trainingsdaten am häufigsten war. Bei JavaScript kann das CommonJS-require in einem Projekt mit ES-Modulen bedeuten, bei Python eine Bibliotheks-API, die sich inzwischen geändert hat (Pydantic 1 gegen 2 ist ein häufiger Fall), und bei jedem schnelllebigen Framework das Muster von vor zwei Hauptversionen. Eine Zeile behebt das meist: "Node 22, ES-Module, kein TypeScript" oder "React 19, Function Components, einfache CSS-Module".
Wenn du etwas zu einem bestehenden Projekt hinzufügst, muss das Modell die Teile sehen, die der neue Code berührt. Füg die Funktionssignatur ein, die er aufrufen muss, die Datenform, die er bekommt, und eine bestehende Datei, die deine Konventionen zeigt. "Nutze den Helper db.query(sql, params) aus der Datei unten" bringt Code, der passt; ohne diesen Satz bekommst du vielleicht eine neu geschriebene Datenbankverbindung. Lass Dateien weg, die mit der Änderung nichts zu tun haben, denn jede fremde Zeile ist etwas, das das Modell wiederverwenden könnte.
Bitte immer nur um einen kleinen Schritt
Der häufigste Fehler beim "Vibe Coding", also eine App zu bauen, indem man sie einer KI beschreibt, ist, die ganze App auf einmal zu verlangen. Das Modell muss in einer Antwort ein Framework, eine Datenbank, eine Ordnerstruktur und ein Dutzend Funktionen wählen, und eine einzelne Antwort fasst selten funktionierenden Code für all das, also kommt oft nur eine Gliederung zurück. Vergleiche die beiden Tabs.
Hier ist eine Full-Stack-To-do-App mit React, Node.js mit Express und MongoDB.
Projektstruktur
todo-app/
client/ (React front end)
server/ (Express API, auth, reminders)
server/index.js
const express = require("express");
const mongoose = require("mongoose");
const app = express();
app.use(express.json());
// ... auth routes, todo routes and the reminder scheduler go here
Für die Authentifizierung kannst du JWT mit jsonwebtoken ergänzen, und für Erinnerungen einen Scheduler wie node-cron. Sag mir Bescheid, wenn ich einen dieser Teile ausfüllen soll.
Die erste Antwort ist nicht falsch, aber sie ist ein Gerüst: Sie hat drei Technologien für dich gewählt und die eigentliche Arbeit als Kommentare stehen lassen. Die zweite Antwort ist kurz genug zum Lesen, läuft, sobald du die Datei öffnest, und gibt dir eine funktionierende Basis für Schritt 2 ("speichere die Liste jetzt in localStorage, damit sie ein Neuladen übersteht"). Jeder Schritt ist klein genug, dass du weißt, welche Änderung es war, wenn etwas kaputtgeht.
Das ist Prompt Chaining von Hand: Die Ausgabe einer Anfrage wird zum Ausgangspunkt der nächsten. Füg in jeden neuen Schritt die aktuelle Version der Datei ein, damit das Modell den Code bearbeitet, den du tatsächlich hast, und nicht den, an den es sich zu erinnern glaubt.
Bitte vor einer großen Änderung um einen Plan
Bei allem, was größer ist als eine Funktion, bitte zuerst um den Plan und dann um den Code: "Liste die Dateien auf, die du ändern würdest, und was jede Änderung bewirkt. Schreib noch keinen Code." Ein Plan ist schnell gelesen und schnell korrigiert. Wenn er eine neue Abhängigkeit vorschlägt, die du nicht willst, oder eine Datei übersieht, von der du weißt, dass sie betroffen ist, korrigierst du das in einem Satz, statt es in dreihundert Zeilen Code zu entdecken.
Prüf, was zurückkommt
Generierter Code scheitert auf ein paar vorhersehbare Arten, und für jede gibt es eine Prompt-Gewohnheit, die sie abfängt:
- Erfundene APIs. Ein Modell kann eine Funktion aufrufen oder ein Paket importieren, das es nicht gibt, weil der Name plausibel klingt. Schlag unbekannte Imports nach, bevor du sie installierst; KI-Halluzinationen erklärt, warum das passiert.
- Stille Randfälle. Code, der im Normalfall funktioniert und bei einer leeren Liste abstürzt. Die Randfälle im Prompt aufzulisten und nach Tests zu fragen, ist die billigste Lösung.
- Heimliche Änderungen. Wenn du in einer langen Datei um eine Korrektur bittest, benennt das Modell vielleicht auch Dinge um oder ordnet Code neu, nach dem du nicht gefragt hast. Ergänze "ändere nur, was nötig ist, und liste jede Änderung auf, die du gemacht hast".
Wenn der Code läuft, sich aber falsch verhält, wechsle zu einem Debugging-Prompt: Prompts zum Debuggen zeigt, was du einfügen solltest. Bevor du etwas Wichtiges mergst, kann ein zweiter Durchgang mit einem Code-Review-Prompt Probleme finden, an die der Schreib-Prompt nicht gedacht hat.
Häufig gestellte Fragen
Was ist der beste Prompt zum Programmieren mit ChatGPT oder Claude?
Den einen Zauber-Prompt gibt es nicht. Prompts, die funktionieren, lesen sich wie eine kurze Spezifikation: Sprache und Version, was der Code bekommt und zurückgibt, zwei oder drei Beispiel-Inputs mit ihren Outputs, die Randfälle und alles, was der Code nicht verwenden darf. Wenn du mit "schreib auch Tests für diese Fälle" endest, kannst du die Antwort prüfen, statt ihr zu vertrauen.
Was sind Vibe-Coding-Prompts?
"Vibe Coding" beschreibt, Software vor allem dadurch zu bauen, dass man einer KI beschreibt, was man will, und den Code übernimmt, den sie schreibt, oft ohne ihn genau zu lesen. Die Prompts, die ein Vibe-Coding-Projekt am Laufen halten, sind kleine: eine Funktion pro Anfrage, eine klare Beschreibung dessen, was schon existiert, und die Bitte, das Ergebnis auszuführen oder zu testen, bevor es weitergeht. An großen Alles-auf-einmal-Anfragen gehen solche Projekte meist kaputt.
Sollte ich der KI sagen, welche Version der Programmiersprache sie verwenden soll?
Ja. Sprachen und Bibliotheken ändern sich zwischen Versionen, und ein Modell schreibt sonst den Stil, der in seinen Trainingsdaten am häufigsten war, und der kann älter sein als dein Setup. Die Version zu nennen ("Python 3.12", "React 19 mit Function Components", "Node 22, ES-Module"), verhindert Antworten, die auf APIs aufbauen, die du nicht hast.
Kann ich Code vertrauen, den eine KI geschrieben hat?
Behandle ihn wie Code von einer neuen Kollegin: wahrscheinlich nah dran, manchmal falsch auf eine Weise, die richtig aussieht. Führ ihn aus, teste ihn mit den Randfällen, die dir wichtig sind, und lies jeden Teil, der mit Geld, Sicherheit oder Nutzerdaten zu tun hat. Modelle können auch Funktionen oder Pakete erfinden, die es nicht gibt, also prüf unbekannte Imports, bevor du etwas installierst.
Warum geht KI-generierter Code kaputt, wenn mein Projekt größer wird?
Das Modell sieht nur, was im Gespräch steht. Wenn ein Projekt wächst, sieht es die Dateien nicht mehr, die ihm nicht gezeigt werden, und füllt die Lücken mit Vermutungen über Namen, Struktur und frühere Entscheidungen. Füg die relevanten Dateien ein, nenn die Konventionen des Projekts und beschränk jede Anfrage auf eine Änderung.
