AI wrote your app.Do you know what it forgot to tell you?

“A developer? What for? I built it myself with AI, in one evening.”

I hear this more and more. And to be clear from the start: I use AI every day in my work. It writes quickly, it helps a lot, and one evening is now enough for something that looks impressive.

That’s exactly where the trap is. AI will give you an app that opens, works and makes you feel you’re finished. What it won’t tell you is that you’ve only just finished the easy part.

I put 105 AI-built apps to the test

So as not to talk off the top of my head, I took 105 public GitHub projects made with Lovable, one of the best-known tools that generate apps from a plain description. I ran them through ReadMyRepo, the tool I built to make sense of unfamiliar code. I read up to 44 files from each project and left out the ready-made template pieces, which are the same everywhere.

I expected a disaster. I didn’t find one.

91out of 100, the median overall score

Most projects looked tidy. That’s precisely what makes the problem so sneaky.

Of course, there were findings too:

Share of projects with at least one finding

1. Files larger than the limit I set87%
2. Load entire database tables27%
3. At least one security finding16%
4. One database request per item10%
5. Google keys written into the code5%

So AI is doing fine? In the code it writes, often yes. But the most dangerous problems don’t show up in a check like this, because they aren’t in the code. They’re in what it forgot to tell you.

1. “Your database is open to everyone”

In early 2026, researchers at Wiz looked at Moltbook, a social network for AI agents. Its creator had said publicly that he hadn’t written a single line of code. Without having to break anything, the researchers found its database open, with read and write access.

About 1.5 million access tokens and 35,000 email addresses were exposed. It was fixed within hours of being reported.

The cause was one setting. On services like Supabase, the key visible in the page is designed to be visible. The data is protected by a rule in the database (Row Level Security) that decides who sees what. Here the rule wasn’t switched on. The code can be flawless and the door still open.

2. “Your keys are showing”

RedHunt Labs scanned about 130,000 websites from 13 AI building platforms. About 26,000, or one in five, had at least one secret key in their public code. If a stranger finds your AI service key, they can use it and you pay.

Escape, across 5,600 apps, found more than 2,000 vulnerabilities, over 400 exposed secrets and 175 cases of personal data, including medical records and IBANs.

3. “I may have written a security hole”

Veracode gave 80 coding tasks to more than 100 AI models. In 45% of cases the code contained one of the most common types of security flaw. What’s more, models were getting better at writing code that works, but not at writing it securely.

An app with a security hole works normally. Nothing turns red and nothing warns you.

4. “I can delete your data”

In July 2025, the founder of SaaStr was trying out Replit’s AI agent. Despite an explicit freeze on changes, the agent wiped the live database, holding data on more than 1,200 executives and 1,190 companies. It then said a rollback wouldn’t work. It did, but had to be done by hand.

The company reacted quickly and added safeguards. The lesson stands, though: a separate environment for testing, and a backup you’ve actually tried restoring. A backup that has never been restored is just a hope.

5. “You’re the one responsible”

If your app stores customers’ names, phone numbers or bookings, the responsibility stays with your business. AI signs nothing. If a leak puts your customers at risk, the GDPR generally gives you 72 hours to notify the data protection authority. It’s worth knowing beforehand what you’d say.

6. “The work starts after launch”

A demo needs no maintenance. An app with customers does. When PHP2Shell came out, people with someone looking after their systems ran one update. The rest never even heard about it.

This is where the numbers from my check start to matter. A file that keeps growing makes every later change harder, for you and for the AI itself. A table that loads in full flies with a few records and crawls once years of data pile up.

What the demo shows

• It opens and works
• It looks great on your screen
• A little of your own data
• You’re the only user

What customers require

• Rules for who sees what
• Keys kept on the server
• A backup that’s been tested
• Updates and monitoring

Check yours before customers arrive

You don’t need to know how to code for the first steps:

1. Run a code checkReadMyRepo is free and runs in your browser.
2. Try it signed outIn a private window, open the pages that should be locked.
3. Change a numberWith two test accounts, change /orders/12 to /orders/13. See someone else’s data? Only ever on your own app.
4. Check the databaseOn Supabase, open the Security Advisor and confirm RLS is on for every table.
5. Restore a backupIn a test environment, not the live one.

So you don’t need a developer?

For a tool just for yourself, or an idea you want to try out, no. Build it and enjoy it. But the moment money, personal data or customers come in, the question changes.

AI is a very fast assistant. In the hands of someone who knows what to ask, it’s excellent. In the hands of someone who doesn’t know there’s a question, it very quickly builds something that looks finished.

As for us developers, don’t worry. It hasn’t replaced us. It has just brought us a new category of work: apps that were “finished in one evening”.

---

Built something with AI and want a second pair of eyes before customers arrive? Tell me what you’ve made.

Sources: Wiz, RedHunt Labs, Escape, Veracode, Fortune, GDPR, Article 33.