A handful of the major AI coding platforms now scan your project before you publish, and I've written positively about that shift more than once. It's a real improvement over a year ago, when none of them checked anything by default. I still run an independent scan on top of it every time, and I want to actually explain why, because it's not about distrusting the platform's intentions.
What a built-in scanner is genuinely good at
The platform that built your app knows its own architecture better than anyone. It knows exactly what a typical project on its system looks like, what its own default settings are, and which of those defaults have caused problems before. That's real, earned knowledge, and it's why these built-in scans catch what they catch: missing row-level security on a Supabase table, a leaked-password pattern in a signup flow, a known bad configuration the platform has seen a thousand times across other users' projects.
The structural limit that has nothing to do with effort
Here's the part that isn't about any platform trying hard enough. A scanner built by the same company that designed the defaults is checking your project against that company's own assumptions about what's normal and safe. If one of those underlying assumptions is itself wrong, or incomplete, the scanner has no outside reference point to catch it. It's checking your homework against its own answer key, and if the answer key has an error in it, the check will pass every time.
An independent scan, or a person who works across multiple platforms rather than just one, doesn't carry that same blind spot. It's not smarter about your specific app. It's just not grading against the same answer key, which means it can catch the exact category of mistake a platform's own tooling structurally can't.
A concrete way to think about it
Picture two different checks on the same app. The built-in scan asks: does this project match the patterns we already know are risky on our platform. An outside check asks a different question entirely: regardless of what platform built this, can I, right now, read or write data I shouldn't be able to. The first is pattern matching against known platform-specific mistakes. The second is actually trying the door. They overlap somewhat, but neither one replaces the other, and running only the first means you've only ever been checked against one company's list.
What this actually looks like in practice
- Run the built-in scan every time you publish. It's free, it's fast, and it catches real, common mistakes specific to your platform.
- Separately, run a free external scan or do a manual pass focused purely on access: can a logged-in user reach another user's data, does an admin route actually require authentication, is a key sitting somewhere the browser can read it.
- Treat a clean result from the built-in scan as one data point, not a final verdict. It answers "does this match a known bad pattern on this platform," not "is this actually safe."
None of this is a knock on any single platform's effort. It's just what happens whenever the checker and the thing being checked come from the same source. A second, independent look isn't redundant caution. It's the only way to catch the mistake the first check was never structurally able to see.