KI-Prompts fürs Programmieren: Debuggen, Refactoring, Tests

Bitte ein Modell, „diese Funktion zu reparieren", wirf zwanzig Zeilen hinterher, und du bekommst eine plausible Neufassung, die den eigentlichen Bug trifft – oder eben nicht. Stell dieselbe Frage mit der vollständigen Fehlermeldung, dem Input, der sie auslöst, der Framework-Version und dem, was du erwartet hättest – und in den meisten Fällen sitzt der Fix beim ersten Versuch. Der Abstand zwischen diesen beiden Ergebnissen ist die ganze Kunst. Gute KI-Prompts fürs Programmieren sind keine cleveren Zauberformeln. Es ist derselbe Kontext, den du einer Kollegin geben würdest, bevor du sie bittest, auf deinen Bildschirm zu schauen.

So baust du diesen Kontext für die Arbeit auf, die Entwickler wirklich machen: Debugging, Refactoring, Tests, Erklärungen, Gerüstbau – und der ehrliche Teil, in dem du prüfst, was das Modell dir zurückgibt.

Der Kontext, den jeder Coding-Prompt braucht

Die stärksten KI-Prompts fürs Programmieren teilen ein Rückgrat: genug Kontext, damit das Modell nicht rät. Es kann dein Repo nicht öffnen, den fehlschlagenden Test nicht laufen lassen und nicht nachsehen, auf welche Bibliotheksversion du festgenagelt bist. Es sieht nur, was du einfügst. Also schreib es aus. Jeder solide Coding-Prompt trägt fünf Dinge:

• Sprache und Version – „Python 3.12", nicht „Python". Das Verhalten verschiebt sich zwischen Versionen, und die APIs, nach denen das Modell greift, auch.
• Framework und dessen Version – React 18 vs. 19, Django 4 vs. 5, die festgepinnte Zeile aus deinem Lockfile. Das allein killt die Hälfte aller Antworten mit veralteten APIs.
• Der echte Code – die tatsächliche Funktion, keine Umschreibung. Nimm die aufrufenden Stellen mit, wenn der Bug dort liegen könnte.
• Erwartetes vs. tatsächliches Verhalten – „sollte die aktiven Sitzungen des Nutzers zurückgeben; gibt stattdessen eine leere Liste zurück, wenn der Nutzer genau eine hat."
• Einschränkungen – keine neuen Abhängigkeiten, muss abwärtskompatibel bleiben, muss in einer Lambda unter dem 512-MB-Limit laufen.

Vergiss die Version, und du bekommst Code für eine API, die sich vor zwei Releases geändert hat. Vergiss Erwartet-vs.-Tatsächlich, und das Modell erfindet seine eigene Definition von „kaputt". Wenn ein Prompt unterspezifiziert wirkt und du nicht sagen kannst, was fehlt, macht ein Durchlauf des Entwurfs durch einen Prompt-Optimierer die Lücken schnell sichtbar.

Debugging: füg den ganzen Fehler ein, keine Zusammenfassung

Der häufigste Fehler ist, einen Fehler als „da steht irgendwas mit undefined" abzutippen. Füg den vollständigen Stacktrace ein. Zeilennummern, die Aufrufkette, der Exception-Typ – das ist die Landkarte. Und dann gib dem Modell einen Weg, das Ganze zu reproduzieren.

Zuerst nach der Grundursache zu fragen ist Absicht. Debugging mit KI geht schief, wenn das Modell zu einem Pflaster springt, das das Symptom stummschaltet – ein try/except um das eigentliche Problem gewickelt. Erzwing die Diagnose, und du kannst beurteilen, ob der Fix die Ursache angeht oder nur den Absturz. Bei verzwickten Bugs, wo es auf die Argumentation ankommt, fängt ein Chain-of-Thought-Prompt, der das Modell die Logik Schritt für Schritt durcharbeiten lässt, Dinge, die eine Einmal-Antwort überspringt.

Refactoring und Code-Review

Vage Refactoring-Anfragen bekommen vage Ergebnisse. „Räum das mal auf" lädt das Modell ein, ein paar Variablen umzubenennen und es dabei zu belassen. Sag, was „besser" für diesen Code bedeutet, und setz Grenzen, damit das Verhalten nicht abdriftet.

Diese letzte Zeile macht aus einem Refactoring ein Review. Das Modell zeigt oft auf einen verschluckten Fehler oder einen Off-by-One, den du nicht mehr wahrgenommen hast. Für reines Review sag ihm, es soll als Reviewer mit einer Checkliste agieren – Korrektheit, Edge Cases, Benennung, Sicherheit – und Funde nach Schweregrad ordnen, damit du nicht in Stil-Kleinkram ertrinkst. Die fortgeschrittenen Prompting-Techniken, die hier zu lernen sich lohnt, sind Rollenzuweisung und explizite Ausgabestruktur. Beide machen aus Review-Output etwas, mit dem du arbeiten kannst.

Tests, die das Modell nicht fälschen kann

Modelle schreiben Tests schnell, und genau deshalb musst du sie lenken. Sich selbst überlassen, testen sie den Happy Path und behaupten, was der Code ohnehin schon tut – Bugs inklusive. Lenk sie stattdessen auf Verhalten und Randfälle.

Lies die Tests, bevor du ihnen traust. Ein Test, der gegen kaputten Code besteht, ist schlimmer als gar kein Test. Wenn du dieselben Testkonventionen in jeden Prompt neu eintippst, ist das das Signal, eine wiederverwendbare Anweisung zu speichern – deine Prompts mit der Zeit zu verbessern heißt vor allem, das, was funktioniert hat, in eine Vorlage zu gießen, zu der du wieder greifst.

Code erklären, den du nicht geschrieben hast

Eine 400-Zeilen-Datei geerbt, ohne Kommentare, mit einer abgewanderten Autorin? Ein Modell ist ein wirklich guter Erklärer, solange du die richtige Flughöhe verlangst.

Punkt vier ist der stille Gewinner. Er legt die tragenden Annahmen offen, von denen der Code abhängt, die aber nie ausgesprochen werden. Gute Einstiegs-Coding-Prompts fürs Onboarding fragen außerdem „was bricht, wenn ich X ändere" – das kartiert den Explosionsradius, bevor du eine Zeile anfasst.

Boilerplate, Gerüstbau und Sprachkonvertierung

Hier sparen Modelle echte Stunden. Einen CRUD-Endpoint gerüsten, einen Config-Parser, eine GitHub Action, ein Dockerfile – repetitive, gut ausgetretene Arbeit mit bekannter Form. Die besten KI-Prompts fürs Programmieren in dieser Kategorie benennen den exakten Stack, sodass die Ausgabe ohne Neuschrieb hineinpasst.

Behandle das Modell bei Konvertierungen wie einen Übersetzer, der ein Glossar braucht. Python nach Go zu portieren ist nicht Zeile für Zeile; die Idiome unterscheiden sich.

Diese letzte Anforderung zählt am meisten: Eine stille semantische Lücke zwischen zwei Sprachen ist genau die Stelle, an der dich konvertierter Code Wochen später beißt. Wenn du solche Dinge oft von Grund auf baust, schlägt der Start von einer strukturierten Basis mit einem ChatGPT-Prompt-Generator oder einem Claude-Prompt-Generator das Starren auf ein leeres Feld. Viele Entwickler pflegen einen Ordner wiederverwendbarer ChatGPT-Prompts fürs Programmieren, einen pro Projektform.

Prüf, was das Modell dir zurückgibt

Jede Zeile, die eine KI schreibt, ist ein Vorschlag, keine Antwort. Die Fehlerarten sind spezifisch, und sie in- und auswendig zu kennen ist der Job:

• Subtile Logikfehler – Code, der läuft, einen oberflächlichen Test besteht und an einem Rand, den du nicht getestet hast, falsch ist. Off-by-Ones, umgedrehte Vergleichsoperatoren, invertierte Bedingungen.
• Sicherheitslücken – per String zusammengesetztes SQL, unvalidierter Input, ein hartcodiertes Secret in einer Konstante, ein verify=False, das leise die TLS-Prüfung abschaltet. Modelle reproduzieren die unsicheren Muster, auf denen sie trainiert wurden.
• Veraltete APIs – eine Methode, die vor drei Versionen abgekündigt wurde, weil Trainingsdaten alt tendieren. Genau deshalb verdient sich die Versionszeile in deinem Prompt ihren Platz.
• Halluzinierte Bibliotheken – ein plausibel klingendes Paket, das es nicht gibt, oder eine Funktion, die in der echten API fehlt. Wenn du es nicht in den Docs findest, geh davon aus, dass es nicht existiert.

Führ den Code aus. Lies ihn so, wie du den Pull Request einer Fremden lesen würdest, denn genau das ist er. Die Entwickler, die echten Hebel aus KI-Prompts fürs Programmieren ziehen, sind nicht die, die der Ausgabe trauen – es sind die, die genug Kontext liefern, um einen starken Erstentwurf zu bekommen, und ihn dann hart prüfen, bevor er in Produktion geht.

Quellen

• Anthropic — Überblick zum Prompt Engineering
• OpenAI — Leitfaden zum Prompt Engineering