Before you ship the app your AI wrote, check these five things

A developer built nittim, an auditor that scans AI-written applications for committed secrets, vulnerable dependencies, broken authorization, GitHub Actions script injection, and leaked client-side data. Running full audits on 23 mature public repositories, the tool found only 3 production ready, 7 ready with conditions, and 13 high risk or unsafe for production. The tool runs free scans on public GitHub repos and integrates with Cursor, Claude Code, Windsurf, Codex and Copilot over MCP.

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 https://nittim.com . 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.