Vibe coding: when do you need a real developer?

What is vibe coding?

The term vibe coding comes from AI researcher Andrej Karpathy. In February 2025 he described a way of programming where you let the AI do the work, accept the suggested changes without reading them and simply paste error messages back into the chat. You describe what you want and more or less forget that the code exists.

Tools like Lovable, Bolt.new, v0, Replit, Cursor and Claude put that within reach of anyone. You no longer need to know how to program to build a working app with a login screen, a database and payments. That is genuinely new, and I think it is a good thing: more people can try out their idea without spending a large budget first.

Karpathy himself added that it is mostly good enough for throwaway weekend projects. I see the same line in practice. The tricky part is that many apps don’t get thrown away. They suddenly get customers.

What vibe coding is good for

For a prototype, vibe coding is hard to beat. Within a few days you have something to show customers, and their reaction teaches you more than a plan on paper. You find out which features people actually use before you put serious money into it.

It also works well for internal tools with few users and little risk: a schedule for your own team, a form that puts data into a spreadsheet or a dashboard with figures that are public anyway. If something goes wrong there, the damage stays limited.

The trouble starts when an app that began as an experiment quietly becomes a business-critical system. Then the requirements for security, reliability and maintenance change, while the code is still exactly the same.

Signs that you need a developer

There is no fixed line, but founders usually come to me at the same moments. If you recognise one or more of these, it is time to have someone take a look.

• You have paying users. An outage now costs you revenue and trust.
• Your app stores personal or payment data. The GDPR applies, and a data breach is a real problem.
• The AI fixes one bug and causes two new ones. You go round in circles and every change feels like a gamble.
• You no longer understand your own code. You don’t know where things are or why they work.
• Your app gets slower as more users or more data come in.
• An investor or a large customer wants to know how your app is built and how secure it is.
• You get compliance questions, such as a data processing agreement, a security questionnaire or an audit.

What a developer actually does

A good developer doesn’t throw your app away to rebuild it. The first thing I do is read: how the app fits together, where the data lives, who can see what and which parts are vulnerable. I turn that into an overview of what is urgent and what can wait.

After that it is about the things an AI tool rarely does on its own. Writing tests, so a change doesn’t quietly break something else. Checking security, such as who can reach which data and whether there are keys in the code. Adding structure, so the app is still understandable a year from now. And setting up monitoring, so you know something is wrong before your customer notices.

That security part is not a detail. In 2025 Veracode tested more than 100 AI models on 80 coding tasks. In 45 percent of the cases the code contained a vulnerability from the OWASP Top 10, the well-known list of the most common security risks in web applications. Code that works is not the same as code that is safe.

Finally, a developer keeps the app up to date. The packages your app runs on get regular updates, including fixes for security holes. If nobody keeps up with them, you fall behind within a few months.

Working together without throwing your app away

You don’t have to choose between AI and a developer. The combination works best: you keep building and trying new things with your AI tool, and a developer reviews, cleans up what needs it and keeps the foundations healthy.

Agree on a few things to make that work. Work through GitHub, so every change is visible and can be rolled back. Let big changes land in a test environment first. And when in doubt, ask whether something is safe before it goes live, not afterwards.

That way you keep the speed of vibe coding without your app turning into a black box that nobody dares to touch.

How to hand your app over

Whether you work with me or with someone else, a good handover saves hours of detective work, and therefore money. This is what a developer needs to get started.

• Access to the code, preferably in a GitHub account of your own company.
• Team member access to your database, hosting and other services, such as Supabase, Firebase, Vercel or Stripe.
• An overview of the environment variables and keys your app uses, shared safely through a password manager, for example, and not by plain email.
• A short description of what the app does: the main screens, the types of users and the connections with other services.
• The problems you see right now, with an example or a screenshot.

How I help

I’m Patrick Willemsen, owner of BugFyx in ’s-Hertogenbosch, the Netherlands. I have more than 8 years of experience as a software engineer, for clients such as ING, ABN AMRO, de Volksbank, VodafoneZiggo and TCS. I take on apps built with Lovable, Bolt.new, v0, Replit, Cursor or Claude, in React, Next.js, TypeScript, Supabase, Firebase, Node.js, Python, Java, Spring Boot, PostgreSQL and Vue, among others.

I usually start with an App Check. For €600 excl. VAT I review an app of up to 15 screens, with one database and up to 3 connections. Within 5 working days you get a plain-language report with the risks ranked from red through orange to green, and a 30-minute call in which I explain everything.

If you then want me to keep maintaining the app, that’s possible in a maintenance plan from €600 per month. If you start it within 30 days, I credit the €600 of the App Check in full.