Sieben Open-Source-Tools, um KI-generierten Code vor der Produktion zu prüfen

Ihr Coding-Assistent meldet, dass die Arbeit erledigt ist, die Tests sind grün und die App läuft in der Vorschau. Es fühlt sich wie das Ende der Aufgabe an. Meistens ist es das nicht.

Ein grüner Testlauf beweist nur, dass die Tests bestanden wurden. Ob diese Tests bei einer kaputten Implementierung fehlschlagen würden, ist eine andere Frage. Genau wie einige weitere: Ist ein Zugangsschlüssel in einen Commit gerutscht, sind die eingebundenen Pakete frei von bekannten Lücken, und was passiert, wenn fünfzig Leute die App gleichzeitig öffnen? Von sich aus beantwortet ein Assistent solche Fragen selten.

Sieben Open-Source-Tools schließen diese Lücken, jedes aus einem anderen Blickwinkel: Stärke der Tests, geleakte Secrets, verwundbare Abhängigkeiten, Codemuster, toter Code, Barrierefreiheit und Last. Mehrere davon zielen auf JavaScript und TypeScript und passen daher besonders gut zu KI-gebauten Web-Apps. Lassen Sie sie laufen, bevor irgendetwas in Produktion geht.

StrykerJS: Beißen Ihre Tests wirklich zu?

StrykerJS ist ein Framework für Mutationstests in JavaScript und TypeScript. Es nimmt kleine, gezielte Änderungen am Quellcode vor, etwa einen Vergleich umzudrehen oder eine Anweisung zu löschen, und führt die Testsuite jedes Mal neu aus. Bestehen nach der Änderung trotzdem alle Tests, hat die Suite einen blinden Fleck. Abdeckungsquoten können das nicht zeigen, denn eine Zeile kann ausgeführt werden, ohne je geprüft zu werden.

Bei einem kleinen Projekt können Sie es sofort ausprobieren:

pnpm add --save-dev @stryker-mutator/core
# Only for small projects:
npx stryker run

Ohne Konfiguration greift es auf sinnvolle Standardwerte zurück. Es nutzt npm test als Testbefehl und sucht unter lib und src nach Code zum Mutieren.

Gitleaks: Secrets früh abfangen

Gitleaks durchsucht Dateien und die Git-Historie nach Zugangsdaten wie API-Schlüsseln und Tokens. Sie können es von Hand starten oder in eine automatisierte Pipeline einbinden, die einen geleakten Schlüssel stoppt, bevor er sich über Klone und Forks verbreitet. Generierter Code ist eine häufige Quelle dieses Problems, denn ein Modell fügt bereitwillig einen Platzhalter-Schlüssel ein, der sich als echter entpuppt.

So holen und kompilieren Sie es:

git clone https://github.com/gitleaks/gitleaks.git
cd gitleaks
make build

OSV-Scanner: Wissen, wovon Sie abhängen

OSV-Scanner gleicht die Pakete in Ihren Lockfiles mit der Schwachstellendatenbank OSV ab. Er meldet, für welche Ihrer genauen Versionen Sicherheitshinweise veröffentlicht wurden, und gibt Ihnen ein konkretes Bild vom Risiko, das Abhängigkeiten mitbringen. Assistenten fügen Bibliotheken oft ohne langes Nachdenken hinzu, daher zahlt sich diese Prüfung schnell aus.

Bauen lässt er sich mit Go:

go install github.com/google/osv-scanner/v2/cmd/osv-scanner@latest

Semgrep: statische Analyse mit Regeln

Semgrep ist ein schneller quelloffener statischer Analysator. Er gleicht Muster im Code ab, um Bugs zu finden, unsichere Konstrukte zu markieren und die Konventionen Ihres Teams durchzusetzen. Er versteht mehr als dreißig Sprachen und läuft im Editor, als Pre-Commit-Hook oder in einem CI/CD-Job.

Die Installation erfolgt über pip:

 python3 -m pip install semgrep

Knip: Löschen, was niemand nutzt

Knip findet in JavaScript- und TypeScript-Projekten Dateien, Abhängigkeiten und Exporte, auf die nichts verweist. In generiertem Code sammeln sich Überbleibsel schnell an: verwaiste Hilfsfunktionen, Pakete, die hinzugefügt und nie importiert wurden. Wer sie entfernt, senkt den Wartungsaufwand und hält das Repository lesbar, während es wächst.

axe-core: Prüfungen der Barrierefreiheit

axe-core ist eine Engine für Barrierefreiheitstests von Webseiten und anderen HTML-basierten Oberflächen. Sie ist schnell und schlank und lässt sich in jedes vorhandene Test-Setup einbinden, sodass Prüfungen der Barrierefreiheit neben gewöhnlichen Funktionstests stehen können. Assistenten erzeugen gern Markup, das richtig aussieht, dem aber Labels, Rollen und Kontrast fehlen, und so bemerken Sie es.

k6: Wie verhält es sich unter Last?

k6 ist ein Werkzeug für Lasttests. Sie beschreiben Szenarien im Code, messen Antwortzeiten und Fehlerquoten und legen Schwellenwerte fest, die einen Lauf automatisch scheitern lassen, wenn die Leistung nachlässt. Ein kleines Beispiel:

import http from "k6/http";
import { check, sleep } from "k6";

// Test configuration
export const options = {
  thresholds: {
    // Assert that 99% of requests finish within 3000ms.
    http_req_duration: ["p(99) < 3000"],
  },
  // Ramp the number of virtual users up and down
  stages: [
    { duration: "30s", target: 15 },
    { duration: "1m", target: 15 },
    { duration: "20s", target: 0 },
  ],
};

// Simulated user behavior
export default function () {
  let res = http.get("https://quickpizza.grafana.com");
  // Validate response status
  check(res, { "status was 200": (r) => r.status == 200 });
  sleep(1);
}

Das Skript simuliert dreißig Sekunden lang zehn virtuelle Nutzer, die zwischen den Anfragen jeweils eine Sekunde pausieren. Seine Schwellenwerte verlangen, dass das 95. Perzentil der Antwortzeit unter 500 ms bleibt und weniger als 1% der Anfragen fehlschlagen.

Speichern Sie die Datei als test.js, installieren Sie k6 und starten Sie sie mit k6 run test.js.

Alles zusammen

Keines dieser Tools beweist, dass Ihre App korrekt ist, und keines soll das. Zusammen decken sie die Fragen ab, die eine gelungene Demo überspringt. Beginnen Sie mit Gitleaks und OSV-Scanner, die nur Minuten dauern und die teuersten Fehler abfangen. Ergänzen Sie dann Stryker und Semgrep, um den Code selbst zu prüfen, Knip zum Ausmisten, axe-core für die Barrierefreiheit und k6 für den Traffic. Wenn ein anderes Open-Source-Tool in Ihre eigene Checkliste gehört, nehmen Sie es auf. Das Ziel ist jedes Mal dasselbe: Trauen Sie dem Ergebnis erst, wenn etwas versucht hat, es kaputtzumachen.