- In about 44 tasks out of 100, AI-written code introduces a vulnerability, against 45 a year ago: models write code that works better, not code that is safer.
- Thousands of apps built on AI platforms expose company data because nobody changed the defaults.
- The saving is in the quote. The risk is in customer data, employee hours and the company’s name.
- The difference is not whether AI was used. It is who reads the code before it reaches production, and how they prove it.
- Before you sign you need five answers and an independent review before acceptance.
It works at the demo
In February 2025 Andrej Karpathy, one of OpenAI’s founders, gave a name to a way of working that was already happening: tell the AI what you want, accept what it writes, fix it until it runs. He called it vibe coding. For a weekend prototype it is a great method, and that is how he presented it.
The trouble starts when the prototype is sold as a finished product. At the demo, people look at what the software does. Nobody looks at what it allows: who it shows data to, where it keeps the service keys, what happens when a customer changes a number in the page address. The AI answers those questions badly on its own. And someone who cannot read the code does not even know to ask them.
Veracode, one of the companies that measure software security, tests this every year on more than a hundred models. In its 2026 report about 44% of the tasks given to AI produce code with a vulnerability. A year earlier it was 45%. Models write code that works better and better. Secure code, about as often as before.
There’s a new kind of coding I call “vibe coding”…
The bill, line by line
In May, researchers at RedAccess looked at about 380,000 public apps built on AI development platforms such as Lovable, Base44 and Replit. About 5,000 held sensitive company information: a shipping company’s vessel schedules, a bank’s internal financials, a hospital’s patient summaries, according to VentureBeat. Many platforms make new projects public by default, and people who are not developers do not know they should change it.
Lovable, the best known of these platforms, later reconstructed an incident of its own: for almost eleven weeks, between 3 February and 20 April 2026, the code and AI conversations of public projects could be read by any user who had the project link. Private projects were not affected. The company’s first public answer, on the day it was found, had been a different one. People with a public project, and a key or some data inside it, found out afterwards.
To be clear: We did not suffer a data breach.
We’re sorry our initial statement didn’t properly address our mistake.
- AI-assisted build, 10 days5,200.00
- Customer login area900.00
- Go-live, first year500.00
- Someone who reads the code the AI wrotepaid by the company
- A safe place for the service keyspaid by the company
- A check that each customer sees only their own datapaid by customers
- Library updates, for yearspaid by the company
- The hours spent cleaning up when something leakspaid by employees
- The company’s name in the letter to customerspaid by everyone
The company signs the quote, but the bill is split. Customers pay with their data. Employees pay with the hours spent cleaning up, answering the phone, changing passwords. The company pays with its name, which ends up in the letter to customers.
And with time: when personal data leaks, the EU regulation requires notifying the data protection authority without undue delay and, where feasible, within 72 hours of becoming aware of it. The company files that notification, not the supplier who wrote the code.
AI is not the problem
We write code with AI too, every day. Most serious developers do now. The difference is not the tool. It is what happens next: who reads the code, who tests it against the cases the demo does not show, who signs off that it is ready.
A serious supplier can answer one simple question: how do you prove the code does only what it should? With tests, with a second pair of eyes, with an independent review. The vibe coder answers that it works. That is true. It is also the only thing they know.
That is why we made Yempik Security Audit public: AI agents that read the code looking for where it breaks, and a second agent that tries to disprove every problem before it reaches the report. It does not replace a serious supplier. It tells you, before acceptance, whether yours is one.
Five questions before you sign
You do not need technical skills to ask them. You need to listen to how they are answered: a person and a method, or a vague “don’t worry, it works”.
- 01
Who reads the code the AI writes, and how will you show me?
A good answer names a person and a method: review, automated tests, checks before every release.
- 02
Where do the database, payment and AI service keys live?
In a dedicated vault with limited access. Never in the code, never in what the browser downloads.
- 03
How do you stop one customer from seeing another’s data?
With a server-side check on every request, not just by hiding buttons in the interface.
- 04
Who updates the libraries, how often, and for how many years?
October showed that a compromised library gets in within hours. You need a name and a frequency written into the contract.
- 05
Will you accept an independent review before acceptance?
A supplier confident in their work says yes. If the answer is a hesitation, you already have your answer.
Questions
What is a vibe coder?
Someone who builds software by describing it to an AI and accepting the code it produces, without reading or being able to judge it. The term comes from vibe coding, the name Andrej Karpathy gave this way of working in February 2025.
Is AI-written code insecure by definition?
No. In Veracode’s 2026 tests generated code passes the security checks in about 56% of cases. The point is that the other 44% cannot be spotted by eye: someone, or something, has to read and test it before it reaches production.
How can I tell whether the software I bought was built this way?
Ask the supplier the five questions in this article and listen for answers that name people and methods. Then have the code reviewed by someone who did not write it: another developer, or an automated review such as Yempik Security Audit.
If data leaks because of a supplier’s defect, who is liable?
Towards customers and the data protection authority, the company that collects the data, the controller, is liable, even when the defect is the supplier’s. The contract with the supplier then decides who reimburses whom. That is worth settling before you sign.
Sources
- [1]Andrej Karpathy on X, February 2025: the post that named vibe coding. x.com
- [2]Veracode: 2026 GenAI Code Security Report (28 July 2026). www.veracode.com
- [3]Axios: thousands of AI-built apps exposed sensitive corporate and personal data (7 May 2026). www.axios.com
- [4]VentureBeat: vibe-coded apps and exposed data (8 May 2026). venturebeat.com
- [5]Lovable: our response to the April 2026 incident (22 April 2026). lovable.dev
- [6]IBM: Cost of a Data Breach Report 2026. www.ibm.com
- [7]Regulation (EU) 2016/679, Article 33. eur-lex.europa.eu
- [8]Italian Data Protection Authority: personal data breaches. www.garanteprivacy.it
Yempik builds custom software, writes code with AI too, and made the audit tool mentioned here public. The numbers come from the linked sources; the quote in the figure is invented and says so.
Do you know what is in your code?
Yempik Security Audit reads it, looks for where it breaks and hands you one page to decide what to fix.
See the audit