Prompts für Entwickler: vom Bug bis zum Code-Review

Du fügst einen Stack Trace ein, schreibst „korrigiere“, und der Assistent liefert dir eine umgeschriebene Funktion, die den Fehler zum Schweigen bringt. Der Test läuft durch, manchmal nur, weil das hinzugefügte try/except die Exception verschluckt. Das Symptom ist verschwunden, der Bug nicht.

Einem Entwickler muss niemand erklären, was ein Prompt ist. Er braucht vor allem Reflexe, um die KI davon abzuhalten, auf die erste plausible Lösung loszustürmen. Die folgenden Vorlagen erzwingen diese Bremse, und sie funktionieren im Chat ebenso wie in einem Code-Assistenten.

Debuggen: Diagnose und Korrektur trennen

Die lohnendste Anweisung besteht aus einer Zeile: kein Code vor der Diagnose. So vermeidest du, eine Korrektur abzusegnen, die auf einer bloß vermuteten Ursache beruht.

Bug in [SPRACHE/FRAMEWORK, VERSION, FALLS RELEVANT].

Erwartetes Verhalten: [WAS PASSIEREN SOLLTE]
Beobachtetes Verhalten: [WAS PASSIERT]
Reproduktion: [SCHRITTE ODER TEST]
Vollständiger Fehler:
[STACK TRACE]

Betroffener Code:
[AUSSCHNITTE]

Was ich schon versucht oder ausgeschlossen habe: [LISTE]

Schlage noch keine Korrektur vor.
1. Liste 3 Hypothesen, nach Wahrscheinlichkeit sortiert.
2. Nenne zu jeder die Beobachtung im Code oder im Trace, die sie stützt.
3. Gib die schnellste Prüfung an, um sie zu bestätigen oder auszuschließen (gezieltes Log, Abfrage, minimaler Test).

Ich führe diese Prüfungen aus und gebe dir die Ergebnisse. Wenn dir für die Überlegung eine Datei fehlt, frag danach, statt ihren Inhalt zu unterstellen.

Nimm einen Rails-Entwickler, vor dem eine doppelt erzeugte Rechnung liegt: Hier dürften die Hypothesen wahrscheinlich auf ein doppelt abgesendetes Formular, einen erneut abgespielten Webhook oder einen neu gestarteten Job zielen, und jede lässt sich in wenigen Minuten in den Logs prüfen. Diese Aufteilung in zwei Schritte greift das Prinzip des schrittweisen Denkens auf, mit einem Menschen obendrein, der zwischen den Schritten die Fakten liefert.

Einen Diff gegenlesen, nicht eine ganze Datei

Ein Review ohne Ausrichtung liefert vor allem Stilanmerkungen. Gib den Diff, sag, was die Änderung leisten soll, und präzisiere, was dich interessiert.

git diff main...HEAD > diff.txt

Du reviewst diesen Pull Request.

Ziel der Änderung: [TICKET ODER BESCHREIBUNG]
Kontext: [STACK, KONVENTIONEN, PERFORMANCE-ANFORDERUNGEN]
Diff:
[DIFF EINFÜGEN]

Suche in dieser Reihenfolge:
1. Bugs: Grenzfälle, unbehandelte Fehler, Nebenläufigkeit, Nullwerte.
2. Sicherheit: Injection, Zugriffskontrolle, sensible Daten in Logs.
3. Abweichungen vom Ziel: was fehlt und was über den Umfang hinausgeht.

Gib zu jedem Problem die Datei und die Zeile im Diff an, das konkrete Szenario, das es auslöst, und den Schweregrad (blockierend, zu korrigieren, geringfügig). Ignoriere Formatierung und Benennung, darum kümmert sich ein Linter. Wenn dir der Diff in einem Punkt korrekt erscheint, sag das einfach, statt ein Problem zu erfinden.

Der letzte Satz zählt. Ohne ihn neigt ein Modell, das man nach Problemen fragt, dazu, um jeden Preis welche zu finden, auch in gesundem Code.

Legacy-Code absichern, bevor du ihn anfasst

Du musst eine Funktion mit 300 Zeilen ändern, ohne Tests, geschrieben von jemandem, der nicht mehr da ist. „Refaktoriere“ zu verlangen, heißt, undokumentierte Verhaltensweisen zu verlieren. Die richtige Reihenfolge beginnt mit Charakterisierungstests, die festhalten, was der Code heute tut, Bugs eingeschlossen.

Hier ist eine Funktion ohne Tests, im Produktivbetrieb:
[CODE]

Test-Framework: [PYTEST, JEST, PHPUNIT ...]

Vor jedem Refactoring:
1. Beschreibe das tatsächliche Verhalten dieses Codes, Fall für Fall, auch Verhaltensweisen, die dir wie Bugs vorkommen.
2. Schreibe Charakterisierungstests, die dieses aktuelle Verhalten dokumentieren, ohne es zu korrigieren. Markiere Fälle, die wie Bugs aussehen, mit einem Kommentar.
3. Liste die zu simulierenden Abhängigkeiten (Datenbank, Uhr, API) und die Bereiche auf, die du nicht abdecken kannst, ohne den Code zu ändern.

Ändere die Funktion nicht. Das Refactoring folgt in einem zweiten Schritt, in kleinen Etappen, mit grünen Tests zwischen jeder.

Führe diese Tests gegen den aktuellen Code aus, bevor du weitermachst. Schlagen sie beim aktuellen Code fehl, hat sich das Modell beim Verhalten geirrt, und genau diese Abweichungen wolltest du aufdecken. Zerlege das Refactoring anschließend in eine Prompt-Kette: eine Extraktion pro Nachricht, ein Commit pro Etappe.

Tests schreiben, die den Code angreifen

Wenn man nach Tests fragt, nachdem man eine Implementierung gezeigt hat, schreibt die KI oft Tests, die diese Implementierung beschreiben. Sie laufen durch und beweisen nicht viel. Lenke sie auf die Spezifikation und auf die Bruchstellen.

Spezifikation der Funktion: [FACHLICHE REGELN]
Signatur: [SIGNATUR]
Reales Beispiel für Eingabe und Ausgabe: [BEISPIEL]

Schreibe die Tests auf Basis der Spezifikation, ohne eine Implementierung widerspiegeln zu wollen.
Decke Grenzwerte, ungültige Eingaben, Duplikate, Zeitzonen und Rundungen ab, soweit zutreffend.
Gib zu jedem Test in einer Zeile an, welchen realistischen Bug er fangen würde.
Streiche Tests, die nur fehlschlagen könnten, wenn die Sprache selbst kaputt wäre.

Bei einer Restaurant-Reservierungs-App hat dieser Prompt gute Chancen, den Zeitslot zutage zu fördern, der über die Zeitumstellung hinweg reicht, einen Fall, den man oft vergisst.

SQL-Migration: herausfinden lassen, was schiefgehen kann

Eine Migration läuft lokal und sperrt in der Produktion die Tabelle. Die KI ist ein guter pessimistischer Reviewer, sofern sie Datenvolumen und Datenbank-Engine kennt.

Engine und Version: [POSTGRESQL, MYSQL ...]
Größe der betroffenen Tabellen: [ZEILEN]
Traffic: [LESE-/SCHREIBZUGRIFFE, WARTUNGSFENSTER]
Migration:
[SQL]
Anwendungscode, der diese Spalten liest: [AUSSCHNITTE]

Analysiere:
1. Die Sperren, die jede Anweisung setzt, und ihre wahrscheinliche Wirkung bei diesem Volumen.
2. Die Kompatibilität während des Deployments, wenn alter und neuer Code gleichzeitig laufen.
3. Den Rollback-Plan und was sich nicht rückgängig machen lässt.
4. Bei Bedarf eine Version in mehreren Schritten.

Wenn ein Verhalten von der Version der Engine abhängt, sag das und nenne, was ich in der Dokumentation nachprüfen soll.

Drei Vorsichtsmaßnahmen, bevor du generiertem Code vertraust

Prüfe, dass das Zitierte existiert. Ein Modell kann eine Methode, eine Option oder ein Paket erfinden. Das Risiko ist bei der Sicherheit real: Ein erfundener Paketname kann von einem böswilligen Dritten registriert werden. Sieh dir vor der Installation Registry, Autor und Aktivität des Projekts an:

npm view [paket]
pip index versions [paket]

Füge nichts ein, was du nicht teilen darfst. API-Schlüssel, Verbindungsstrings, Kundendaten und Code unter Geheimhaltungsvereinbarung haben in einem von deinem Unternehmen nicht freigegebenen Tool nichts verloren. Sieh dir die Bedingungen deines Tarifs an, denn sie unterscheiden sich von Produkt zu Produkt, und lass einen Secret-Scanner über das laufen, was du abschickst.

Behalte die Verantwortung für das Review. Generierter Code wird gelesen wie der eines Kollegen, mit der zusätzlichen Frage nach den Lizenzen, wenn es um ein kommerzielles Produkt geht. Wenn du mit einem Agenten arbeitest, der selbst Befehle ausführt, verdienen seine Anweisungen so viel Sorgfalt wie dein Code: Alles dazu steht in unserem Leitfaden zu Anweisungen für Agenten.

Öffne dein zuletzt gelöstes Bug-Ticket, gib es deinem Assistenten mit dem ersten Prompt erneut und vergleiche seine Hypothesen mit der tatsächlichen Ursache. Du wirst schnell wissen, was dein Tool auf deiner Codebasis taugt.