Are Vibe Coders Coming for Your App this Weekend?

Are the vibe coders coming for your app?

Imagine this. You've just pitched your app. You're proud of all the little intricacies in the backend that make it function. You get introduced to an investor. You're excited. Then they say, “Looks nice. But, you know, I could just vibe code this in a weekend.”

This was the experience that the founder of Food Storri, an app designed to help users reduce food waste in their homes, related to me after a pitch event at the end of an incubator programme. At this point I'd been working on the app with the founder, developing the agentic AI backend and frontend features with Claude Code, many evenings and weekends over the past two months. Was the investor right? Could this just have been vibe coded in a weekend?

His comment got me thinking about the lessons I'd learned in this period and what level of truth there might be to it.

The Devil is in the Details

First of all, the investor was right. Sort of. Someone could sit down and, using Claude Code, write something that looks like the app we made and do it in a weekend. If they had all of the ideas fully formed when they started. And if they only needed to make something that looks like it worked, but that doesn't actually really work.

In literally everything I've made that incorporates LLM agents somewhere in the tool or app, as the Food Storii app did, the first 80% of the work is easy. But an app that works only 80% and has the goal of eliminating food waste in someone's kitchen fails. Because when the food accounting isn't perfect this means that food goes off or the user gets suggested recipes with ingredients they've already used up. If this happens, they stop trusting the app and leave.

So how do you ensure perfect food accounting? A lot of questions came up as I refined the digital twin of the kitchen over those two months:

• How do we make it seamless to capture food items into the kitchen…
• Whilst also ensuring that we capture the quantities of food (e.g. 1kg flour)…
• When this info is on some supermarket receipts and not others…
• And include the expiry date which is never on a receipt…
• And, most interestingly, how do we track the food that the user is eating, but is not being tracked as part of the recipes that we generate for them - e.g. snacks and things they cook from memory?

Nerd moment: the last was my favourite to think about because I dived in deep and started to think about some kind of complex Bayesian model and where to get data to learn the consumption relationships between food items.

The importance of perfecting the digital twin of the kitchen, or what it would even mean to try to perfect that, wasn't obvious at the beginning of the project. It's also not something that I think someone with zero machine learning experience could figure out over their “weekend of vibe coding the app”. It took trial and error and testing to figure out what would be needed and although I don't doubt that most people would figure this out if they embarked on a similar project, there's still some kind of path dependency to this, where figuring out what needs to be done is iterative. It's unlikely one could go through all these iterations over a vibe coding weekend.

Testing is a Bottleneck

Claude and I were pushing out relatively big features almost every other evening - more so after a weekend. And almost every feature led to the blooming of two more and a new set of specs. But these features needed to be tested - and I don't mean unit tested and I don't mean AI-evals, those we obviously had; I mean some kind of manual test to check that every agentic step is working just fine.

For example: there's an agent that generates meal plans - a number of recipes over a specified number of days with the ingredients the user has. We feed it preferences, a set of rules for generating recipes and the user's inventory. Sounds simple. Yet I spent a whole Sunday afternoon trying to force this agent to generate vegetarian recipes after it kept sneaking meat-based recipes into the meal plan, despite clear instructions not to.

A vegetarian user who gets meat recipes sometimes is going to stop trusting the app, so it's vital for a decent UX that this vegetarian user gets vegetarian meals every time. But without some focused testing, I wouldn't have noticed - and fixed - this very specific failure mode where the LLM just couldn't suggest something without meat if the meat in the kitchen was expiring soon - user preferences injected in the system prompt be damned.

Testing takes time and the more features you write, the more time you - and other people in the team - need to test them. And sure, you'll write automated testing, but I believe you still need humans to do uniquely human things that break systems and are hard to conceive of testing beforehand.

Users are a Bottleneck

Perhaps you've got a really wide circle of friends who are dying to test your MVP of an app. But I doubt it. Finding people to test what you've built and then spending time with them to find out what they liked and didn't like is tough. It's totally doable, people do it every day. But it's so vital to the process to get feedback from real users in the real world using your app - and then taking that feedback and iterating on what you've built and going back again for more feedback. But this takes time, patience and perseverance.

There's an enormous difference between something vibe coded over a weekend and something that's been iterated on a number of times using early user feedback.

Are the vibe coders coming to destroy your app this weekend?

Building something involves creating hypotheses and testing them out. You have an idea and you do some market research talking to people and testing the hypotheses out. Maybe you validate that you've found a problem that might be worth solving and you build something. Then you test another hypothesis out, in this case, do the features and UI you've built help solve the customer problem you tested out in the first hypothesis. Building the features is just a part of that process.

So could someone destroy your app by vibe coding it away this weekend? If your app is basically a pretty UI that makes some OpenAI calls and writes some rows to a table on Supabase, then maybe.

But most likely, when you actually get into the details, almost all functioning apps are much more complicated than that. To vibe code something that works 80% over a weekend, sure, I can buy that that's possible. To build something that customers will use and then come back to again, that takes much more.