Prompt-Beispiele für Coding und Debugging

Warum Coding-Prompts so oft halluzinieren

Sprachmodelle kennen viele APIs – aber nicht unbedingt deine Version, dein Framework-Setup oder deine Team-Konventionen. Fehlt der Stack, erfindet das Modell eine plausible andere Welt: falsche Imports, veraltete APIs, Tests die nicht zu eurem Runner passen.

Gute Coding-Prompts sind weniger „genial“ als „vollständig“: Sprache/Runtime, relevante Dateiausschnitte, Fehlermeldung, gewünschte Änderung und Nicht-Ziele (kein großes Refactoring, keine neuen Dependencies). Je riskanter die Änderung, desto mehr solltest du das Modell als Reviewer statt als Autopilot einsetzen.

Kopiere niemals blind generierten Code in Produktion. Nutze KI für Entwürfe, Erklärungen und Alternativen – und lass Tests, Linter und Code-Review die Wahrheit entscheiden.

Mindestangaben für technische Aufgaben

Wenn du diese Felder konsequent füllst, sinkt die Rate unbrauchbarer Antworten deutlich. Speichere sie als Snippet in deinem Editor.

• Stack: Sprache, Framework, Versionen falls relevant
• Ziel: Bugfix, Feature, Review, Erklärung
• Symptom: Fehlermeldung, erwartetes vs. tatsächliches Verhalten
• Umgebung: Browser, Node, CI, OS – falls relevant
• Constraints: keine neuen Libs, Stilregeln, Performance-Budget
• Output: Diff, vollständige Datei, Schritt-für-Schritt, Testvorschläge

Vorher / Nachher: React-State-Bug

Kopiere immer den relevanten Ausschnitt – nicht das ganze Repo. Markiere die verdächtige Stelle, wenn du sie kennst. Weniger Rauschen führt zu präziseren Fixes.

Feature-Prompts ohne Scope-Creep

Bei neuen Features: Akzeptanzkriterien wie in einem Ticket formulieren. „Als Nutzer möchte ich … damit …“ plus Nicht-Ziele. Sonst baut das Modell oft Nice-to-haves ein, die du später wieder entfernst.

Bitte um einen Plan vor dem Code: Dateien, die sich ändern, Risiken, offene Fragen. Erst wenn der Plan passt, Implementierung anfordern. Das spart teure Fehlwege bei größeren Änderungen.

Refactoring und Code-Review per Prompt

Für Reviews: Kriterien vorgeben (Lesbarkeit, Fehlerfälle, Security, Tests). Bitte um priorisierte Findings (blocker / should-fix / nit) statt eines Umschreibens. So bleibt der Mensch Owner der Änderung.

Für Refactorings: Akzeptanzkriterien und „Do not change public API“ explizit setzen. Sonst optimiert das Modell an der falschen Stelle. Bei Legacy-Code hilft: „Erkläre zuerst, was der Code tut, dann schlage den kleinstmöglichen Fix vor.“

Tests und Edge Cases einfordern

Hänge an Feature-Prompts immer eine Bitte um Edge Cases an: leere Eingaben, Timeouts, Race Conditions, Locale-Themen. Modelle neigen zu Happy Paths, wenn du nicht nach Grenzfallen fragst.

Wenn du TDD magst: erst Testskizze verlangen, dann Implementierung – in zwei Schritten. Das reduziert spekulative Business-Logik. Nenne Test-Framework und Runner (Vitest, Jest, pytest), sonst bekommst du generische Pseudo-Tests.

Sicherheit und Geheimnisse

Keine API-Keys, Tokens oder personenbezogene Produktionsdaten in Cloud-KIs pasten. Anonymisiere Logs und ersetze Domains. Für sicherheitskritischen Code: Modellvorschläge immer reviewen, nie blind mergen.

Der Prompt-Veredler auf dieser Website läuft lokal im Browser – ideal, um aus einer groben Bug-Beschreibung einen strukturierten Prompt zu bauen, bevor du ihn in dein LLM kopierst. Die eigentliche Code-Analyse findet dann in dem Tool statt, dem du vertraust.

Debugging-Gespräch als Prompt-Serie

Statt „fix my bug“ in einem Rutsch: Zerlege in Diagnose, Hypothesen, Fix, Test. Prompt 1 verlangt nur Ursachenhypothesen mit Begründung. Prompt 2 wählt eine Hypothese und fordert den kleinsten Patch. Prompt 3 fordert Tests. So bleiben Antworten fokussiert und reviewbar.

Gib Repro-Schritte wie in einem Issue-Tracker an: Ausgangslage, Aktion, erwartetes Ergebnis, tatsächliches Ergebnis. Modelle ohne Repro raten – und raten oft falsch elegant.

Bei Performance-Themen: Messwerte und Umgebung nennen (Lighthouse, Profiler-Screenshot-Beschreibung, Node-Version). Ohne Zahlen bekommst du generische Tipps wie „memoize mehr“, die in eurem Fall irrelevant sein können.

Halte Team-Konventionen im Prompt: Naming, Error-Handling, Logging. Sonst liefert die KI Code, der technisch funktioniert, aber euren Styleguide bricht und im Review scheitert.

Wenn du unsicher bist, ob ein Vorschlag sicher ist: Fordere eine Threat-Skizze (Input-Validierung, AuthZ, Secrets, Injection). Auch eine kurze Liste „Was könnte hier schiefgehen?“ vor dem Merge ist Gold wert – und kostet einen Prompt.

Für Legacy-Code: Bitte zuerst um eine Verhaltensbeschreibung und erst dann um Änderungen. Viele Halluzinationen entstehen, weil das Modell refaktoriert, ohne den Ist-Zustand verstanden zu haben.