The fix your AI swears it shipped

After the Moltbook and Tea breaches, most vibe coders drew the same sensible conclusion: before shipping, ask the AI to check its own work. Paste in the scary headlines, type “review this app for security issues and fix them,” and watch the agent produce a tidy list of changes and a reassuring summary. These issues have been addressed. It feels like closure.

It is progress, and you should absolutely do it. It is also not a security program, for two reasons that have nothing to do with how smart the model is.

You can only fix what got found

A “make it secure” pass reviews whatever is in the model’s context: the code it can see, through the patterns it happens to check. It does not enumerate your dependencies against vulnerability databases, walk your git history for leaked credentials, or probe the deployed app’s headers, CORS policy, and storage rules. Those live in different layers, and a prompt inherits every blind spot of whatever found the problem in the first place. The fix step can never be more complete than the finding step.

Leaked keys make the gap concrete. Ask an agent to fix a committed API key and it will delete the line, move the value to an environment variable, and report success. But the key is still in git history, and still in every clone and scrape made since it landed there. The real fix is rotation, which happens in a provider dashboard the agent does not control. Some fixes are not code, and an agent scoped to your repository cannot tell you that its code-shaped fix was the wrong kind.

The confident fix that never happened

The second problem is sharper: an agent reports success with exactly the same confidence whether or not the vulnerable behavior actually changed. That is not dishonesty, it is the absence of any feedback signal. Nothing failed, because there were no security tests to fail. A few patterns show up constantly:

• It patches the example, not the class. The finding named one route, so the agent sanitizes that route and leaves the identical pattern in the six other routes it scaffolded from the same template.
• It fixes the symptom in a new shape. The query gets rewritten, the variable names change, and the string concatenation that made it injectable survives the rewrite.
• The fix quietly regresses. Three feature prompts later, the agent regenerates the file from its favored pattern and the fix vanishes. Nobody rereads the diff, because not reading the code is the whole premise of vibe coding.

What a real fix loop looks like

None of this means the agent is the wrong tool for fixing. It means the agent cannot also be the referee. The loop that actually closes findings looks like this:

1. Find with instruments, not vibes. A scan across code, dependencies, secrets, configuration, and the running app produces findings with evidence: the file, the line, the request that worked when it should not have.
2. Fix with a named target. Each finding becomes a precise, scoped task you hand to the same agent that built the app. “Parameterize the query in orders.ts line 41” gets a reliable fix; “make it secure” gets a performance.
3. Rescan to verify. The finding flips to Verified Fixed only when the evidence is gone. If the rewrite dodged the scanner’s first probe but not the second, the finding reopens with the new evidence attached.
4. Keep rescanning. Verification that runs once is a snapshot. Rescans on later releases are what catch the regenerated file that silently undid the fix.

This is the right division of labor. Agents are genuinely good at step two when the instruction is specific, which is exactly what the common vulnerability classes tend to produce: findings with a file and a line. Scanners find and verify. Agents write the code in between.

Trust the loop, not the transcript

Vibe coding collapsed the time between idea and production, and prompting the agent to fix its own security issues collapses most of the time between finding and fix. The step that cannot be collapsed is the one where something other than the author confirms the fix is real. The agent that built your app can absolutely fix it. It just cannot be the one who tells you it worked.