KI zum Programmieren nutzen: Workflows, die Risiken senken

Regeln für sichere KI-Hilfe beim Programmieren

Der beste Weg, KI zum Programmieren zu nutzen, ist, sie genau an den Stellen langsamer zu machen, an denen Raten gefährlich wird. KI kann fremden Code erklären, Fehlermeldungen in Hypothesen verwandeln, Tests entwerfen, Diffs prüfen und Refactorings vorschlagen. Sie kann aber auch APIs erfinden, versteckte Abhängigkeiten übersehen, sich zu stark am eingefügten Ausschnitt orientieren oder einen Patch liefern, der sauber aussieht und dabei Verhalten ändert, das du eigentlich erhalten wolltest.

Nutze diese Regel: Die KI darf vorschlagen, entschieden wird im Repo. Die Wahrheit steht in der Codebasis, in der fehlschlagenden Reproduktion, in der Testsuite, in den Laufzeit-Logs, in den Produktanforderungen und in der menschlichen Prüfung. Ein guter KI-Pair-Programmer hilft dir, aus diesen Artefakten zu schlussfolgern, statt sie zu ersetzen.

Regel	Warum sie zählt	Was du das Modell fragst
Zuerst reproduzieren	Verhindert Patches ins Blaue	"Fasse das fehlerhafte Verhalten und die Belege zusammen, bevor du Code vorschlägst."
Umfang klein halten	Senkt das Regressionsrisiko	"Schlage die kleinste sichere Änderung vor und liste die berührten Dateien auf."
Verhalten erhalten	Schützt Nutzer und Schnittstellenverträge	"Benenne die Invarianten, die diese Änderung nicht brechen darf."
Tests verlangen	Macht die Antwort überprüfbar	"Schreib Tests, die vor dem Fix fehlschlagen und danach bestehen."
Vor dem Merge prüfen	Fängt selbstsichere Fehler ab	"Prüfe diesen Diff auf Korrektheit, Sicherheit und fehlende Randfälle."

Das gilt über alle Modelle hinweg. OpenAI, Anthropic und andere Anbieter veröffentlichen Modell-Dokumentationen, die unterschiedliche Fähigkeiten, Kontextfenster und Muster der Tool-Nutzung beschreiben. Diese Fähigkeiten sind nützlich, aber sie ersetzen keinen disziplinierten Workflow. Bei Engineering-Arbeit beurteile Modelle nach demselben Maßstab wie einen Kollegen: Fragen sie nach fehlendem Kontext, verringern sie Unsicherheit, respektieren sie Vorgaben und hinterlassen sie eine Spur, die du überprüfen kannst?

Debugging-Workflow

Ein verlässlicher KI-Debugging-Workflow hat fünf Phasen: reproduzieren, eingrenzen, Hypothesen bilden, patchen und prüfen. Fang nicht mit "repariere das" an. Fang mit den Belegen an. Gib dem Modell den fehlschlagenden Befehl, die exakte Fehlermeldung, das erwartete Verhalten, das beobachtete Verhalten, den relevanten Code, Details zur Umgebung und jede kürzliche Änderung, die das Problem ausgelöst haben könnte.

Phase 1: Erfasse die Reproduktion. Bei Backend-Code gehören Request, Response, Statuscode, Logs und der fehlschlagende Test dazu. Bei Frontend-Code gehören Route, Nutzeraktion, Fehler in der Browser-Konsole, Netzwerk-Response, Zustand der Komponente und, falls relevant, eine Beschreibung des Screenshots dazu. Bei Build-Problemen gehören der Befehl, der Paketmanager, die Node-Version und die vollständige Fehlerausgabe rund um den ersten Fehler dazu.

Phase 2: Frag nach Hypothesen, bevor Code kommt. Ein sorgfältiges Modell sollte die wahrscheinlichen Ursachen ordnen und sagen, welche Belege für jede einzelne sprechen. Wenn es Ursachen nicht auseinanderhalten kann, frag nach dem kleinsten diagnostischen Schritt. Das kann ein Log sein, ein gezielter Test, eine Typprüfung oder das Lesen einer weiteren Datei.

Phase 3: Verlange den kleinsten Patch. Sag dem Modell, es soll keine Variablen umbenennen, keinen umliegenden Code umschreiben, keine Abhängigkeiten einführen und kein öffentliches Verhalten ändern, solange es das nicht begründen kann. Bitte es, Grundursache, Patch-Skizze, berührte Dateien, Tests und Risiko zurückzugeben.

Phase 4: Lass die Tests lokal laufen. Eine KI-Ausgabe ist kein Prüfschritt. Der Prüfschritt ist der Befehl oder der Nutzerpfad, der das Verhalten belegt. Wenn kein automatisierter Test existiert, bitte das Modell, zuerst einen Regressionstest zu erstellen, und setze danach den Fix um.

Debugging-Prompt:

Agiere als sorgfältiger Debugging-Partner. Schreib noch keinen Code. Fasse zuerst die Reproduktion, das erwartete Verhalten, das beobachtete Verhalten und die drei wahrscheinlichsten Grundursachen zusammen. Ordne jede Ursache nach Belegstärke. Schlage dann den kleinsten diagnostischen Schritt vor. Bug: [beschreiben]. Befehl oder Nutzeraktion: [einfügen]. Fehler/Logs: [einfügen]. Relevanter Code: [einfügen]. Rahmenbedingungen: [Stack, Dateien, die nicht angefasst werden dürfen, Verhalten, das erhalten bleiben muss].

Fix-Prompt:

Nutze die bestätigte Grundursache und schlage den kleinsten sicheren Fix vor. Gib zurück: Grundursache, zu ändernde Dateien und Funktionen, Patch-Skizze, Tests, die vorher fehlschlagen und danach bestehen, Randfälle und Rollback-Risiko. Refaktoriere keinen unbeteiligten Code. Kontext: [einfügen].

Code-Review-Workflow

KI ist oft besser als Prüferin denn als Erstautorin. Wenn du sie bittest, einen Diff zu prüfen, findet sie übersehene Randfälle, Sicherheitsprobleme, veraltete Annahmen, Testlücken und Verhaltensänderungen. Entscheidend ist, die Prüfung konkret zu machen. Wenn du fragst "sieht das gut aus?", bekommst du höfliche Zustimmung. Wenn du nach dem Korrektheitsrisiko fragst, bekommst du eher nützliche Einwände.

Gib dem Modell den Diff, das beabsichtigte Verhalten, die zugehörigen Tests und alle Vorgaben. Bitte es, kleinere Stilfragen zu ignorieren, außer sie beeinträchtigen die Wartbarkeit. Die Prüfung soll Bugs priorisieren, nicht Erbsenzählerei.

Prüfbereich	Fragen, die die KI beantworten soll
Korrektheit	Erfüllt der Diff die Anforderung tatsächlich?
Regressionsrisiko	Welches bestehende Verhalten könnte sich versehentlich ändern?
Sicherheit	Sind Eingaben, Authentifizierung, Secrets, Berechtigungen und Injection-Risiken abgedeckt?
Fehlerbehandlung	Was passiert bei Null-Werten, Timeouts, Retries, fehlerhaften Responses oder unvollständigem Zustand?
Tests	Welche Verhaltensaussagen sind nicht abgedeckt?
Wartbarkeit	Folgt das den Mustern im Projekt und bleibt die Änderung verständlich?

Code-Review-Prompt:

Prüfe diesen Diff wie ein strenger, aber pragmatischer Maintainer. Konzentriere dich auf Korrektheit, Regressionsrisiko, Sicherheit, Randfälle und fehlende Tests. Ignoriere kleinere Stilfragen, außer sie erzeugen echtes Wartungsrisiko. Gib eine Tabelle zurück mit Problem, Priorität, Beleg aus dem Diff, Fix-Vorschlag und nötigem Test. Beabsichtigtes Verhalten: [einfügen]. Diff: [einfügen]. Vorhandene Tests: [einfügen].

Bei riskanten Änderungen nutze in Whizi einen Workflow, der die Fixes mehrerer Modelle vergleicht. Lass denselben Prüf-Prompt über zwei oder drei Modelle laufen. Wenn ein Modell ein mögliches Problem meldet, übernimm es nicht blind, sondern prüfe, ob es in der Codebasis wirklich existiert. Ziel ist nicht, mehr Meinungen zu sammeln. Ziel ist, die Prüffläche vor dem Merge zu vergrößern.

Refactoring- und Test-Workflow

Refactoring mit KI ist riskant, weil viele Refactorings daran gemessen werden, was sich nicht ändert. Das Modell kann den Code hübscher machen und dabei unbemerkt Verhalten, Fehlerbehandlung, Timing oder öffentliche Schnittstellen verändern. Ein sichererer Refactoring-Workflow beginnt damit, die Invarianten zu definieren, bevor die Implementierung angefasst wird.

Schritt 1: Beschreibe das Ziel des Refactorings. Beispiele: Duplikate verringern, eine große Komponente aufteilen, den Datenzugriff isolieren, Verzweigungen vereinfachen, einen API-Wrapper migrieren oder die Testbarkeit verbessern. Sag dann, was gleich bleiben muss: öffentliche Funktionssignaturen, Routen-Verhalten, Event-Namen, Response-Formate, Analytics, Berechtigungen, Barrierefreiheit und Performance-Erwartungen.

Schritt 2: Frag nach einem stufenweisen Plan. Ein brauchbarer KI-Refactoring-Plan ist umkehrbar. Jede Stufe sollte einen kleinen Bereich berühren, Tests enthalten und einen lauffähigen Zwischenstand liefern. Vermeide Rewrites in einem Rutsch, außer der Code ist winzig und gut abgedeckt.

Schritt 3: Schreib Charakterisierungstests. Bevor du Code änderst, bitte die KI, das aktuelle Verhalten zu ermitteln und Tests zu entwerfen, die die wichtigen Fälle festnageln. Diese Tests sind besonders bei Altcode nützlich, bei dem die ursprüngliche Absicht unklar ist. Sie sollten normale Eingaben, Grenzwerte, Fehlerpfade und einen Regressionsfall enthalten, der am Grund für das Refactoring hängt.

Schritt 4: Setze eine Stufe nach der anderen um. Lass nach jeder Stufe die Tests laufen und bitte um eine gezielte Prüfung. Wenn das Modell eine breite Abstraktion vorschlägt, lass es belegen, dass die Abstraktion echte Duplikate oder echtes Risiko beseitigt. Sonst halte den Code langweilig und lokal.

Prompt für die Refactoring-Planung:

Erstelle einen stufenweisen Refactoring-Plan. Ziel: [Ziel]. Aktueller Code: [einfügen]. Rahmenbedingungen: öffentliches Verhalten erhalten, Änderungsumfang minimieren, bestehenden Mustern folgen, keine neuen Abhängigkeiten, jede Stufe testbar halten. Gib zurück: Invarianten, Abhängigkeitskarte, Stufen, berührte Dateien, Tests pro Stufe, Rollback-Risiko und Prüf-Checkliste.

Unit-Test-Prompt:

Schreib Tests, bevor die Implementierung geändert wird. Nutze den vorhandenen Teststil aus diesem Beispiel: [einfügen]. Zu erhaltendes Verhalten: [einfügen]. Zu testender Code: [einfügen]. Gib Testnamen, Setup, Eingabe, erwartetes Ergebnis und den Grund zurück, warum jeder Test wichtig ist. Enthalte Happy Path, Grenzfall, Fehlerfall und Regressionsfall.

Prompt-Vorlagen

Gute Programmier-Prompts sind nicht lang, weil sie ausgefeilt sind. Sie sind lang genug, um Mehrdeutigkeit zu beseitigen. Das Modell braucht Rolle, Aufgabe, Kontext, Rahmenbedingungen, Ausgabeformat und Prüfkriterien. Speichere die Prompts, die funktionieren, damit KI zu einem wiederholbaren Engineering-Workflow wird statt zu einem einmaligen Chat.

Prompt zur Code-Erklärung:

Erkläre diesen Code für eine Entwicklerin, die neu ins Projekt kommt. Behandle Zweck, Eingaben, Ausgaben, Datenfluss, Abhängigkeiten, Fehlerfälle und Tests, die das Vertrauen erhöhen würden. Trenne Fakten, die im Code sichtbar sind, von Annahmen. Code: [einfügen].

Prompt für sicheres Programmieren:

Prüfe diesen Code auf Sicherheitsrisiken. Konzentriere dich auf Authentifizierung, Berechtigungen, Injection, Secrets, Validierung, unsichere Weiterleitungen, Dateiverarbeitung, Abhängigkeitsrisiko und die Preisgabe sensibler Daten. Gib nur Probleme zurück, jeweils mit Beleg, Auswirkung, Fix-Vorschlag und Test oder manueller Prüfung. Code/Diff: [einfügen].

Prompt zum Vergleich von Modell-Fixes:

Ich vergleiche KI-Modelle für eine Programmieraufgabe. Nutze nur den bereitgestellten Kontext. Gib Grundursache, kleinsten sicheren Fix, Tests, Risiken, Annahmen und offene Fragen zurück. Bewerte deine Sicherheit von 1 bis 5 und liste auf, welche Belege deine Antwort ändern würden. Aufgabe: [einfügen]. Kontext: [einfügen].

QA-Checkliste, bevor du KI-generierten Code akzeptierst:

• Das Modell hat die Aufgabe korrekt wiedergegeben.
• Der Patch ist kleiner als das Problem, nicht größer.
• Öffentliches Verhalten und Schnittstellenverträge sind benannt.
• Tests decken den Bug oder das Refactoring-Ziel direkt ab.
• Randfälle und Fehlerpfade sind aufgelistet.
• Sicherheitskritische Eingaben sind geprüft.
• Der Diff folgt den bestehenden Mustern im Projekt.
• Du hast den passenden Test, Lint, Build oder die manuelle Reproduktion ausgeführt.
• Ein Mensch hat den finalen Diff geprüft.

Whizi ist nützlich, wenn du Fixes vergleichen willst, ohne die Aufgabe zu verändern. Füge denselben Debugging- oder Prüf-Prompt in mehrere Modelle ein und bewerte die Ergebnisse nach Belegen, Umfang, Tests und Risiko. Starte mit ChatGPT-Alternativen zum Programmieren, wenn du einen Leitfaden zur Modellwahl willst, vergleiche Tarife unter Preise oder erstelle ein Konto, um den Workflow an deinem eigenen Code laufen zu lassen.