Tools like Lovable, Bolt or Cursor made possible something that seemed impossible a few years ago: anyone can describe an app in words and see it running within hours. Along with the good things it brought, this also created a new wave of “programmers”: people who have never written a line of code, but who offer websites, online stores and apps at very low prices, delivered in a few days.
The demo looks flawless. It has a login, tables and charts. The difference from an app built by an experienced team doesn’t show in the presentation. It shows later, when the app meets real users.
The low price has an explanation
An app isn’t just the screens you see. It’s also the things you don’t see:
- how the data is organized and whether it will cope a year from now;
- who is allowed to see and change each piece of information;
- what happens when a user makes a mistake, malicious or not;
- what happens when payments, email or another external service doesn’t respond;
- backups, updates and maintenance.
Someone who can’t program can’t evaluate the generated code. They don’t know which questions to ask, so the AI never gets those questions either. The result is an app that works on the happy path and nothing more. We wrote about this at length in our article on vibe coding: AI writes good code, but it doesn’t design the architecture.
The low price isn’t a discount. It’s the price of an app missing everything listed above.
What happens when they reach production
Thousands of vulnerabilities in plain sight. In October 2025, Escape analyzed over 5,600 public apps built with vibe coding platforms. It found more than 2,000 vulnerabilities, over 400 exposed secret keys and 175 cases of personal data open to anyone, including medical records and bank account numbers (IBANs). All of them were in apps already in production, and the researchers say the figures are a lower bound1.
A social network with the door wide open. In early 2026, Moltbook, a social network for AI agents that went viral overnight, was analyzed by researchers at Wiz. Its founder had said publicly: “I didn’t write a single line of code for Moltbook.” The database was open to anyone: about 1.5 million access keys, 35,000 email addresses and private messages, some containing access keys for other services in plain text. Anyone could take over any account. The cause: a single database security setting left unconfigured2.
A new job: the vibe coding fixer. The phenomenon created a new market. Fiverr has hundreds of “vibe code fixer” offers, and the tech press has started writing about programmers paid to fix apps generated by others3. The fix often costs more than building the app properly would have cost in the first place.
The cheaper option
The first Tacoma Narrows Bridge (USA) was built from a design chosen, among other reasons, because it was cheaper: 2.4-meter girders instead of 7.6-meter trusses. It looked elegant and passed the calculations of the time. It collapsed four months after opening, on 7 November 1940, in a wind of only 64 km/h. Nobody had tested how the bridge would behave in the real conditions there4.
The responsibility is yours
If your app collects personal data, you are the data controller, not whoever built the app. A data leak means notifications, lost customers and, under the GDPR, fines of up to 20 million euros or 4% of annual turnover5.
How an experienced programmer works with AI
We use AI too. The difference isn’t the tool, it’s who holds it.
When an experienced programmer works, the decisions are theirs. They design the architecture: what the data looks like, how the app is split into modules, who has access to what, what happens on errors, how backups are made. They choose the libraries and patterns. Only then do they ask the AI to write the code, piece by piece, exactly as they would have written it.
Every piece is read and understood before it goes into the project. If the AI takes a shortcut, they see it. If it proposes a solution that doesn’t match the rest of the project, they reject it. The final result is identical to the code they would have written by hand, it’s just done faster.
Simon Willison, one of the most respected programmers writing about AI, puts it simply: “AI tools amplify existing expertise.”6 The more you know, the better the results. If you know nothing, AI amplifies exactly that.
| What we compare | Vibe coding | Experienced programmer + AI |
|---|---|---|
| Who decides the architecture | nobody, it emerges along the way | the programmer, before the code |
| Who reads the code | nobody | the programmer, every piece |
| What happens on an error | the AI is asked to “fix it” | the cause is understood, then fixed |
| Security | whatever comes out first | designed and verified |
| Tests | generated, if any | designed around what can fail |
| Who answers for the result | unclear | whoever signed the contract |
- We understand the problem. We talk to you, learn how you work, what data you have, what has to happen and what must never happen.
- We design the architecture. Data, access rights, integrations, security and hosting are decided before the first line of code.
- We write the code, with AI as a tool. The AI writes what we decided, faster. Every piece is read, understood and adjusted.
- We test what can fail. Not just the happy path, but the cases where apps usually break.
- We answer for the result. That’s why we offer a warranty of at least one year, and two years or more for complex projects.
Tests: AI doesn’t know what to test
A common argument: “I’ll let the AI write the tests too.” It sounds good, but a test is only useful if it checks what the app should do, not what it does now.
When AI writes tests by looking at the code, it mostly checks the existing behavior, mistakes included. Several studies reached exactly this conclusion: tests generated by models confirm what the program does, not what it should do, and sometimes they end up validating the bugs themselves7.
A simple example
The code applies a 10% discount instead of 15%. The AI writes a test by looking at the code and checks that the discount is 10%. The test passes. Now the bug doesn’t just exist, it’s “confirmed” by a test.
There’s another problem: asked to “make the tests pass”, an AI agent may take the shortest route. Kent Beck, one of the fathers of test-driven development, lists among his warning signs when working with AI “any indication that the genie was cheating, for example by disabling or deleting tests”8.
Good tests come from experience: from knowing how apps break. A programmer who has seen hundreds of production bugs automatically asks:
- what if two customers order the last item in the same second?
- what if the payment provider confirms the same payment twice?
- what if someone changes a number in the URL and lands on someone else’s order?
- what if a field is empty, has 10,000 characters or contains accents and emoji?
- what if the email server doesn’t respond just as the invoice is being sent?
- what if the clocks change for daylight saving in the middle of a booking?
AI can write the tests for all these cases very quickly, if someone knows to ask for them. Without that someone, the app has many tests, all green and all useless.
How to choose who you work with
Before picking the lowest offer, ask a few questions:
- Who designs the architecture, and can they explain the decisions to me?
- How is the data protected, and who has access to what?
- What do you test, and how?
- How are backups made, and how long does a restore take?
- What warranty do you offer, and who fixes a problem a year from now?
- Which of your apps have been running in production for years?
A vague answer to any of them tells you more than any demo.
Want an app built with AI, but by people who know what they are building?
Escape, How we discovered over 2k high-impact vulnerabilities in apps built with vibe coding platforms, October 2025. ↩
Wiz, Hacking Moltbook: The AI Social Network Any Human Can Control, February 2026. The issue was fixed within hours of the researchers’ report. ↩
404 Media, The Software Engineers Paid to Fix Vibe Coded Messes, September 2025. ↩
Tacoma Narrows Bridge (1940), Wikipedia. ↩
Regulation (EU) 2016/679 (GDPR), Article 83. ↩
Simon Willison, Vibe engineering, October 2025. ↩
Konstantinou, Degiovanni, Papadakis, Can we find bugs using LLM-generated oracles?; Mathews, Nagappan, Design choices made by LLM-based test generators prevent them from finding bugs. ↩
Kent Beck, Augmented Coding: Beyond the Vibes, June 2025. ↩
Cover image: Jimrickshaw, Wikimedia Commons (public domain)
