Check out the Build Series. Part 1 | Part 2 | Part 3 | Part 4 | Part 5
AI-generated edge functions can silently discard every file your users upload by writing to ephemeral /tmp/ storage instead of Supabase Storage, returning success: true either way.
I found this out during the AI Advent Challenge, when I checked the submissions table three days in and found zero rows despite 37 contributors having uploaded their PDF submissions over 48 hours. The edge function Lovable built was writing files to local memory that evaporated the moment the function terminated, and nobody, including the AI, had any reason to flag it.
The AI Advent Challenge ran across 30 days, pulling in builders and PMs from the community to submit their work as PDFs through a custom upload form. The form worked beautifully. The success banner fired on every submission.
The database was empty.
Every upload had been silently discarded since day one. The edge function received the file, wrote it to
/tmp/inside the function’s execution environment, returned a 200 response, and terminated. When the function stopped, the/tmp/directory went with it. No error fired. No alert sent.
That is a difficult message to send to 37 contributors who trusted your platform with their work. If you are shipping AI-built upload features without verifying the persistence layer, you probably have the same empty database waiting for you. [That is exactly what I help teams catch before their users find it instead.]
This Pattern Has Already Wiped Production Databases
In July 2025, The Register reported that a Replit AI agent deleted SaaStr’s live production database, then fabricated 4,000 fake user records and produced misleading status messages throughout. The agent reported success at every step. The original data was gone and unrecoverable.
That incident and my AI Advent Challenge disaster share the same root cause:
AI-generated code that completes its function contract without verifying where data actually ends up. The HTTP response fires 200 because the function ran without crashing. The data loss happens in the gap the AI never thought to check.
Escape.tech’s 2026 analysis of 5,600 vibe-coded apps found 2,000+ vulnerabilities and more than 400 exposed secrets. The majority of data exposure issues came from the same class of error: code that handled data incorrectly while returning clean status messages throughout.
The silent failure is the hardest category to catch because nothing warns you. The pattern repeats across storage, file handling, payment webhooks, and any feature that moves data between two systems.
✅ AI generates code that runs without crashing.
✅ Tests pass because test data never exercises real persistence.
✅ The success banner fires because the HTTP response is 200.
✅ The database stays empty with no alert fired, ever.
Why Your PM Workflow Has No Checkpoint for This
Your definition of “done” was built in an era when humans wrote code and understood where data was going.
When a developer built a file upload handler, they made an intentional choice about where the file would live, and that choice was reviewed in code review and tested manually. That step does not exist in a Lovable build.
AI-generated code completes the function contract: accept input, return output. It does not necessarily close the loop on what happens to the data in between.
Your sprint review, your staging demo, and your QA checklist will almost never surface it because everyone is looking at the UI layer, not the database table.
The gap between “feature demo’d in staging” and “data safely persisted” is exactly where silent bugs live.
The Approach I Follow
Here is what I now run before any AI-built storage or upload feature ships:
✅ Test with a throwaway account and check the database directly, not the UI. Open Supabase, run a SELECT, and confirm the row exists. I have caught two silent failures this way that looked perfect in the browser.
✅ Read the edge function code and trace every file path. Any reference to /tmp/, local filesystem paths, or in-memory variables is a red flag. The question to ask: where does this data live after the function terminates?
✅ Verify that your success response includes a persistent identifier. A correctly implemented upload should return a Supabase Storage path or a database row ID. If your success response only contains {success: true} with no reference to where the data lives, the function is probably not persisting anything.
✅ Trigger a cold start and re-upload. Edge functions are stateless. Kill and restart the function, upload again, and check whether the previous upload’s data is still retrievable. If it vanishes, the data was never persisted.
✅ Check your row count against your user action count. If 10 users submitted forms, you should have 10 rows. Any mismatch is a persistence bug until proven otherwise.
If your AI-built features are shipping with assumption-driven bugs, this five-part spec is the exact process I walk teams through in an audit. Just one slot open this month at promptledproduct.com/audits.