Fünf Checks, bevor die KI-geschriebene App in Produktion geht
Viele aktuelle Apps entstehen überwiegend mit KI-Assistenten. Beim Blick in das Repository zeigen sich aber häufig versehentlich committete API-Keys, verwundbare Abhängigkeiten oder eine Authentifizierung, die nur den Idealfall abdeckt. Vor dem Release sollten Entwickler diese Punkte prüfen.
Die meisten Apps, die derzeit starten, wurden größtenteils von einem KI-Assistenten geschrieben. Das ist in Ordnung. Nicht in Ordnung ist, was zum Vorschein kommt, wenn jemand endlich das Repository liest: ein versehentlich committeter Schlüssel, eine Abhängigkeit mit einer bekannten Schwachstelle, eine Authentifizierung, die nur den Happy Path abdeckt.
Ich habe die letzten Monate damit verbracht, genau dafür einen Auditor zu entwickeln, und dabei habe ich ihn auf eine Menge öffentlichen Code angewendet. Hier ist, worauf ich prüfen würde, bevor man eine KI-geschriebene App echten Nutzern vorsetzt, in der Reihenfolge, die die schlimmsten Dinge am schnellsten findet.
Durchsuche den gesamten Verzeichnisbaum, nicht nur.env-Dateien. Assistenten fügen Schlüssel in Konfigurationsdateien, Test-Fixtures, Dokumentation und Beispielcode ein, und dann wird das Ganze in einem Rutsch committet. Suche nach API-Keys, Datenbank-URLs mit Passwörtern, privaten Schlüsseln und Access Tokens.
Wenn du einen findest, ist das Rotieren des Schlüssels die Lösung. Das Löschen der Zeile ist es nicht: Sie bleibt in der Git-History erhalten.
Führe npm audit, pip-audit, govulncheck oder cargo audit gegen deine Lockfile aus, nicht gegen dein Manifest. Die Lockfile ist das, was tatsächlich installiert wird. Am wichtigsten sind High- und Critical-Hinweise bei Paketen, die in Produktion gehen; eine verwundbare Dev-Dependency wiegt weniger schwer.
Assistenten pinnen die Version, an die sie sich erinnern, und das ist oft ein Jahr alt. Allein das macht einen überraschend großen Anteil dessen aus, was ich finde.
Die Anmeldung ist der einfache Teil. Die Frage ist, ob ein angemeldeter Nutzer die Zeilen eines anderen Nutzers erreichen kann, indem er eine ID in der URL oder im Request Body ändert. Wähle drei Endpoints, die eine ID entgegennehmen, und probiere es mit einem zweiten Konto. Das ist der mit Abstand häufigste ernste Befund bei KI-geschriebenen Apps, weil der Assistent den Happy Path schreibt, den man verlangt hat, und sonst nichts.
Wenn du Supabase oder ein ähnliches Backend nutzt, lies deine RLS-Policies und deine RPCs getrennt voneinander. Eine Policy umzäunt Tabellen; eine Funktion kann sie trotzdem umgehen.
Wenn du GitHub Actions verwendest, prüfe, ob ${{ github.event... }} direkt in einen run: step interpoliert wird. Ein Pull-Request-Titel oder eine Release-Note wird zur Shell. Das ist leicht zu übersehen, weil es in einer YAML-Datei steht, die niemand ein zweites Mal liest.
Öffne das gebaute Bundle und suche nach allem, was nach einem Schlüssel oder einem Prompt aussieht. Alles im Browser ist öffentlich. Serverseitige Logik, die etwas Wichtiges entscheidet, sollte serverseitig bleiben.
Ich pflege eine öffentliche Bibliothek dieser Prüfungen an bekannten Open-Source-Repos, damit du sehen kannst, wie ein echter Bericht aussieht, bevor du einen auf deinem eigenen Code ausführst. Von den 23 öffentlichen Repositories, die bisher eine vollständige Prüfung erhalten haben, waren 3 produktionsreif, 7 mit Bedingungen bereit, und 13 waren entweder hochriskant oder nicht sicher für den Produktiveinsatz. Das sind ausgereifte Projekte mit jahrelanger Historie. Ein Repo, das an einem Wochenende von einem Assistenten geschrieben wurde, schneidet tendenziell schlechter ab, nicht besser.
Die oben genannten Prüfungen sind diejenigen, die den Großteil der Befunde ausmachen, die ein Ausliefern blockieren. Keine davon braucht eine KI, um ausgeführt zu werden.
Das Tool heißt nittim. Der kostenlose Scan führt Schritt 1 und 2 sowie eine deterministische Code-Analyse für jedes öffentliche GitHub-Repo durch, ohne Anmeldung und ohne Kreditkarte. Mit Anmeldung erhältst du eine vollständige Prüfung gratis: eine KI-Analyse des Codes, bei der jeder Befund mit exakter Datei und Zeile sowie einem Fix dafür geliefert wird. Es läuft auch innerhalb von Cursor, Claude Code, Windsurf, Codex und Copilot über MCP, sodass dein Assistent dieselbe Prüfung auf das ausführen kann, was er gerade geschrieben hat.
Wenn es etwas meldet, das wirklich kein Problem ist, möchte ich davon hören. False Positives sind der Fehlermodus, der mir am wichtigsten ist.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Most apps I see launching now were written mostly by an AI assistant. That's fine. What isn't fine is what shows up when someone finally reads the repo: a key committed by accident, a dependency with a known vulnerability, auth that only covers the happy path.
I spent the last few months building an auditor for exactly this, and along the way I ran it on a lot of public code. Here's what I'd check before putting any AI-written app in front of real users, in the order that finds the worst things fastest.
Search the whole tree, not just.env. Assistants paste keys into config files, test fixtures, docs and example code, and then the whole thing gets committed in one go. Look for API keys, database URLs with passwords in them, private keys and access tokens.
If you find one, rotating it is the fix. Deleting the line is not: it's still in git history.
Run npm audit, pip-audit, govulncheck or cargo audit against your lockfile, not your manifest. The lockfile is what actually installs. Care most about High and Critical advisories in packages that ship to production; a vulnerable dev dependency matters less.
Assistants pin whatever version they remember, which is often a year old. That alone accounts for a surprising share of what I find.
Signing in is the easy part. The question is whether a signed-in user can reach another user's rows by changing an id in the URL or the request body. Pick three endpoints that take an id and try it with a second account. This is the single most common serious finding in AI-written apps, because the assistant writes the happy path you asked for and nothing else.
If you're on Supabase or a similar backend, read your RLS policies and your RPCs separately. A policy fences tables; a function can still bypass it.
If you have GitHub Actions, check for ${{ github.event... }} interpolated straight into a run: step. A pull request title or a release note becomes shell. This one is easy to miss because it's in a YAML file nobody reads twice.
Open the built bundle and search for anything that looks like a key or a prompt. Anything in the browser is public. Server-side logic that decides something important should stay server-side.
I keep a public library of these checks on well-known open-source repos, so you can see what a real report looks like before you run one on your own code. Of the 23 public repositories that have had a full audit so far, 3 came back production ready, 7 ready with conditions, and 13 were either high risk or not safe for production. These are mature projects with years of history. A repo written over a weekend by an assistant tends to do worse, not better.
The checks above are the ones that account for most of the ship-blocking findings. None of them need an AI to run.
The tool is nittim. The free scan does steps 1 and 2 plus a deterministic code read on any public GitHub repo, no sign-in and no card. Signing in gets you one full audit free: an AI read of the code, with each finding at the exact file and line and a fix for it. It also runs inside Cursor, Claude Code, Windsurf, Codex and Copilot over MCP, so your assistant can run the same check on what it just wrote.
If it flags something that isn't really a problem, I want to hear about it. False positives are the failure mode I care most about.