Die Idee

Ein KI-Coding-Assistent kann einen Patch oder einen Pull Request erzeugen, also einen vorgeschlagenen Satz von Änderungen zur Prüfung. Das Ergebnis kann überzeugend wirken, weil es gut formatiert ist und wie erwarteter Code aussieht. Das ist kein Beleg dafür, dass es das richtige Problem löst, an den Rändern funktioniert oder zu deinem Projekt passt.

KI-Code zu prüfen bedeutet, ihn als vorgeschlagenen Beitrag zu behandeln. Lege zuerst fest, welches Verhalten die Aufgabe verlangt. Prüfe dann die Änderung, führe passende Checks aus und triff die Merge-Entscheidung selbst. GitHub empfiehlt, generierten Code vor der Nutzung zu verstehen und auf Funktionalität, Sicherheit, Lesbarkeit und Wartbarkeit zu prüfen. Außerdem sollst du eine Änderung mit Zweck, Anforderungen und Architektur des Projekts abgleichen: also mit seiner Gesamtstruktur und damit, wie seine Teile zusammenarbeiten. GitHub-Leitfaden GitHub-Empfehlungen

Einfach gesagt: KI kann einen ersten Entwurf für eine Änderung schreiben. Du bleibst dafür verantwortlich zu entscheiden, ob diese Änderung ins Produkt gehört.

Ein nützlicher Review-Ablauf hat vier Teile:

  1. Formuliere das erwartete Verhalten in deinen eigenen Worten.
  2. Lies den Diff, die zeilenweise Ansicht dessen, was sich geändert hat. Frage dich, warum jede geänderte Datei und jede Abhängigkeit nötig ist, also jede externe Bibliothek oder Komponente, auf die das Projekt angewiesen ist. Prüfe auch die Sicherheitsfolgen.
  3. Führe automatisierte Tests aus: Das sind Prüfungen, die Code ausführen und Ergebnisse mit erwartetem Verhalten vergleichen. Ergänze einen gezielten Test, wenn ein wichtiger Fall fehlt.
  4. Führe statische Analyse aus: Das sind Werkzeuge, die Code prüfen, ohne ihn auszuführen. Dazu gehören Linting, das den Stil und wahrscheinliche Programmierfehler prüft, sowie Code-Scanning, das nach möglichen Sicherheits- oder Codequalitätsproblemen sucht.

GitHub empfiehlt beim Validieren von KI-generiertem Code ausdrücklich automatisierte Tests und statische Werkzeuge wie Linting und Code-Scanning. Diese Checks ergänzen das Lesen der Änderung; sie ersetzen es nicht. GitHub-Leitfaden

Ein kleines Beispiel

Beispiel: Du bittest einen Assistenten, E-Mail-Adressen in einer Python-API zu normalisieren. Seine vorgeschlagene Änderung entfernt Leerzeichen am Anfang und Ende und schreibt die Adresse klein.

Beginne mit der Anforderung: „Akzeptiere eine Adresse mit Leerzeichen außen herum, gib den normalisierten Wert zurück und lehne ungültige Eingaben wie bisher ab.“ Lies den Diff. Ändert er nur den Validierungspfad? Verändert er die Fehlerbehandlung? Fügt er eine Bibliothek für etwas hinzu, das das Projekt bereits erledigt? Welche Sicherheitsfolgen könnte die Änderung haben?

Prüfe danach die Logik und führe vorhandene Tests aus. Ergänze kleine Tests für Eingaben in Großschreibung, Leerzeichen außen herum, ungültige Eingaben und eine bereits normalisierte Adresse. Führe anschließend das Linting des Projekts und weitere statische Checks aus. Ein erfolgreiches Ergebnis liefert nützliche Hinweise, beweist aber nicht, dass das Verhalten in jeder Situation korrekt ist.

Prüfe auch Tests, die der Assistent geschrieben hat. Ein Test kann erfolgreich sein und trotzdem nur die gewählte Implementierung bestätigen, statt das Verhalten zu prüfen, das Nutzer brauchen. GitHub weist darauf hin, dass generierte Tests relevante Szenarien oder Fehlerfälle übersehen können. GitHub-Leitfaden

Probier es aus

Nimm dir fünf Minuten für eine kleine KI-generierte Änderung. Wenn du keine hast, nutze eine hypothetische Änderung.

Schreibe einen Satz über das verlangte Verhalten. Öffne den Diff und benenne den Zweck jeder geänderten Datei. Wähle einen Grenz- oder Fehlerfall, der nicht eindeutig getestet wird. Führe zum Schluss die Checks aus, die im Repository bereits verfügbar sind, und notiere eine offene Frage. Wenn du die Änderung nicht verstehst, ist sie nicht bereit zum Mergen.

Darauf solltest du achten

Tests decken nur die Fälle ab, die sie ausdrücken. Auch statische Analyse hat Grenzen: Sie kann Probleme übersehen und Hinweise liefern, die Menschen einordnen müssen. Entscheidungen zu Sicherheit, Datenschutz, Lizenzen und Architektur können zusätzliches Fachwissen oder weitere Prüfung erfordern.

Behandle auch einen KI-Reviewer nicht als letzte Instanz. GitHub schreibt, dass von Copilot erzeugte Pull Requests vor dem Mergen eine gründliche menschliche Prüfung erhalten sollen, wie andere Beiträge auch. GitHub-Leitfaden

Das Ziel ist nicht, perfekten Code zu beweisen. Du sollst eine bewusste, auf Belegen beruhende Entscheidung treffen, bevor Code Nutzer erreicht.