Die Idee

Ein KI-Coding-Assistent kann schnell einen nützlichen Patch schreiben. Das bedeutet nicht, dass der Patch für deine Anwendung korrekt ist. Ein Vorschlag kann überzeugend aussehen und trotzdem eine nicht existierende API verwenden, eine Einschränkung übersehen oder falsche Logik umsetzen. GitHub nennt solche Risiken ausdrücklich bei der Prüfung von KI-generiertem Code. GitHub Docs

Die Gewohnheit, die du entwickeln solltest, ist einfach: Behandle KI-Ausgaben als vorgeschlagene Codeänderungen, nicht als Beweis. Bevor du sie übernimmst, prüfst du sie mit Werkzeugen und mit deinem eigenen Verständnis.

Einfach gesagt: KI kann Code entwerfen. Du bleibst dafür verantwortlich zu entscheiden, ob dieser Code in dein Projekt gehört.

Beginne mit dem Diff, der exakt zeigt, welche Dateien und Zeilen sich geändert haben. Er beantwortet eine Grundfrage: Hat der Assistent nur das geändert, was du erwartet hast? Eine Anfrage zur Behandlung eines Eingabefehlers sollte nicht unbemerkt unabhängige Konfigurationen oder öffentliche Schnittstellen umschreiben.

Führe danach passende automatisierte Tests aus. Das sind wiederholbare Prüfungen, die Code ausführen und das tatsächliche Verhalten mit dem erwarteten vergleichen. Starte außerdem eine statische Analyse. Sie untersucht Code, ohne ihn auszuführen. Dazu können ein Linter, eine Typprüfung oder ein Code-Scanner gehören. GitHub empfiehlt automatisierte Tests und statische Analyse als frühe Prüfungen für KI-generierten Code. GitHub Docs

Diese Checks sind nützlich, beantworten aber nicht jede Frage. Lies die Änderung und vergleiche sie mit der gewünschten Absicht: dem Problem, das die Änderung lösen soll. Prüfe dann, ob sie zur Architektur des Projekts passt, also zu dessen gewählter Struktur und seinen Grenzen. GitHub empfiehlt, zu beurteilen, ob generierter Code dem Zweck, den Anforderungen und der Architektur des Projekts entspricht. GitHub Docs

Bewerte zuletzt Funktionalität, Sicherheit, Lesbarkeit und Wartbarkeit. Du solltest vorgeschlagenen Code verstehen, bevor du ihn akzeptierst. GitHub Docs

Ein kleines Beispiel

Beispiel, hypothetisch: Du bittest einen Coding-Assistenten, eine Funktion zum Einlesen von CSV-Dateien zu ändern. Das Ziel ist, leere Zeilen zu überspringen und gleichzeitig hilfreiche Fehlermeldungen für fehlerhafte Zeilen beizubehalten.

Öffne zuerst den Diff. Du erwartest eine kleine Änderung im CSV-Reader und vielleicht in dessen Tests. Fügt der Vorschlag auch eine neue Abhängigkeit hinzu oder verändert einen unabhängigen Parser, halte an und kläre warum.

Führe zweitens die vorhandenen Tests und die statischen Checks deines Projekts aus. Ein erfolgreiches Ergebnis zeigt, dass die geprüften Fälle weiterhin funktionieren. Es beweist nicht, dass die neue Anforderung vollständig umgesetzt ist.

Füge drittens einen Test für einen Randfall hinzu oder prüfe einen solchen Test: eine ungewöhnliche, aber bedeutsame Eingabe nahe einer Grenze des normalen Verhaltens. Hier ist eine Leerzeile zwischen zwei gültigen Zeilen ein Randfall. Du könntest auch eine Datei prüfen, die nur Leerzeilen enthält, sowie eine fehlerhafte, nicht leere Zeile.

Lies viertens den Zweig für die Fehlerbehandlung. Wird eine Leerzeile übersprungen, ohne dass zugleich eine fehlerhafte Zeile verborgen wird? Entspricht die Änderung dem umgebenden Stil und den Aufrufern der Funktion? Hier prüfst du Absicht und Projektkontext, nicht nur Syntax.

Vertraue einem generierten Test nicht allein deshalb, weil er besteht. GitHub weist darauf hin, dass KI-generierte Tests möglicherweise nicht alle Szenarien abdecken und daher ebenfalls geprüft werden müssen. GitHub Docs

Probier es aus

Nimm dir für diese hypothetische Übung etwa fünf Minuten:

  1. Wähle einen kleinen KI-generierten Vorschlag oder einen älteren kleinen Patch.
  2. Lies den Diff. Beschreibe in einem Satz, was sich geändert hat.
  3. Führe einen passenden Test oder statischen Check aus.
  4. Nenne einen Randfall, den die aktuellen Tests nicht eindeutig abdecken.
  5. Lies den geänderten Code und erkläre mit eigenen Worten, wie er diesen Fall behandelt.

Kannst du die Änderung nicht erklären, solltest du sie noch nicht mergen. Bitte bei Bedarf um eine Erklärung, prüfe sie aber gegen Code und Checks. Auch eine KI-Erklärung ist KI-Ausgabe und kein unabhängiger Beleg.

Darauf solltest du achten

Ein grüner Testlauf ist ein Hinweis, keine Garantie. Tests decken nur die Fälle ab, die sie enthalten. Statische Analyse findet viele wiederholbare Probleme, kann aber nicht zuverlässig entscheiden, ob Geschäftsregeln, Architektur oder nutzerseitiges Verhalten richtig sind.

Sei besonders vorsichtig, wenn ein Vorschlag eine Abhängigkeit einführt, Berechtigungen oder Eingabevalidierung ändert, eine öffentliche Schnittstelle verändert oder sicherheitskritisches Verhalten berührt. Welche Scanner und Abhängigkeitsprüfungen verfügbar sind, hängt vom Projekt ab. Nutze daher die Checks, die dein Projekt tatsächlich unterstützt.

Das Ziel ist nicht, jedem Vorschlag zu misstrauen oder für jede kleine Tippkorrektur einen riesigen Review zu machen. Passe den Aufwand an die Änderung an. Behalte aber die Reihenfolge bei: Diff prüfen, Checks ausführen, Code lesen und die Passung beurteilen. So kannst du KI-Unterstützung nutzen und behältst die Engineering-Entscheidung dort, wo sie hingehört: bei dir.