Table of Contents
The hidden cost of vibe coding doesn’t show up on day one. I recently spent a lot of time building a product with Lovable. This is what Andrej Karpathy called “vibe coding” when he coined the term in February 2025, and the first thing that hits you is the speed. You describe what you want and, very quickly, you have something that looks like a real product. The interface is polished, the buttons work, there are filters, empty states, dashboards and all the little things that traditionally end up on the “nice to have” list because nobody has time to build them.
That changes the economics of product development. When adding a feature costs almost nothing, you stop asking whether you have time for it and start asking whether you actually need it.
There are some obvious advantages to this way of working. If I am unsure how something should work, I can ask AI. If I have a UI problem, I don’t need to wait for a designer or developer to fix it. If I need some relatively simple logic, I can describe it and see what happens. For a product person, this is a huge change. I can go from an idea to something tangible without having to translate the idea into a specification and hand it to someone else.
But there is a catch.
AI is extremely good at producing something that looks finished long before it actually is.
You can have a beautiful interface, a database behind it, and seemingly connected workflows, while a surprising number of things are still wrong. Something works in one scenario, but not another. A value wasn’t saved correctly. One action breaks another part of the application. As we learn from working with our customers and developing our platform at the same time, an edge case can produce a completely different result from what you expected.
Our team ended up spending an enormous amount of time testing. I would say that around 80% of the work was used for testing.
That sounds strange when the whole point of vibe coding is speed, but it makes sense, and it isn’t only our experience. A 2025 randomised controlled trial by METR found that AI coding tools slowed experienced developers down by 19% once the time spent reviewing and fixing AI-generated code was counted, the opposite of what both the developers involved and independent experts had predicted. When you can generate functionality very quickly, you can also generate bugs quickly. The actual coding becomes cheap; finding out whether what was built is correct becomes the expensive part.
AI understands logic. It doesn’t necessarily understand the product. This was probably the most interesting thing I learned.
AI is actually pretty good at following technical logic. The problem is that technical logic, database logic, and product logic aren’t always the same thing.
While I was building cap table functionality, for example, I wanted actions such as issuing shares, editing stakeholders, and editing share classes to sit under the cap table. Lovable kept pushing back on this. Its reasoning was basically that a cap table is a table, while issuing shares or editing stakeholders are separate functionalities, so they shouldn’t be mixed together.
Technically, that reasoning isn’t completely ridiculous. From a product perspective, it was wrong. Nobody using a cap table thinks, “This is a table; therefore, everything related to managing the table should live somewhere else.”
There were plenty of other examples.
That last one is particularly interesting because the logic is not inherently bad. It is just solving the wrong problem. We are building a reporting tool, not an official cap table used to report ownership to authorities. We don’t need to introduce the complexity of a system designed for that purpose.
Then there were the things I never asked for: complex user rights, logins and passwords for a prototype nobody but me would ever touch. AI kept guarding fake test data I’d deliberately entered to try things out, and when I told it to delete that data, it pushed back, insisting the data needed protecting.
The pattern became clear: AI is very good at recognising common software patterns, but it doesn’t automatically understand the context in which those patterns make sense.
AI might build a beautiful flow for creating something and then invent a completely different, unnecessarily complicated flow for editing it. A human who understands the product usually thinks about the entire lifecycle of the object. AI often thinks about the individual feature it has been asked to implement.
That is one of the reasons product judgements still matter so much.
There is almost no friction between thinking of a feature and asking AI to build it.
That is both wonderful and dangerous.
In traditional development, you naturally prioritise. You have limited engineering capacity, so you build the important things first. The nice-to-haves usually don’t survive.
With AI, you can ask for the nice-to-have and have it five minutes later.
The problem is that every feature you add becomes another thing you need to test, maintain, and understand.
AI will happily give you ten additional features you didn’t ask for. Some of them will be useful. Some will be completely unnecessary. Some will create new problems that are harder to find because everything looks so polished.
There’s also a cost that’s easy to overlook: every feature that ships keeps running and keeps consuming compute, whether or not anyone actually uses it. Data centre electricity consumption has grown by around 12% a year since 2017, roughly four times faster than overall electricity demand, and the International Energy Agency names AI as the main driver.
I’ve started thinking about this differently: if AI builds something I didn’t ask for, I don’t necessarily need to test it. I can just delete it.
That is often much cheaper.
The biggest change isn’t that I can now “code.”
I can’t.
The change is that I can communicate a product much more directly.
Instead of writing a specification saying what the interface should look like, I can build the interface. Instead of trying to explain a flow with screenshots and diagrams, I can make the flow.
That makes the conversation with developers much better too. They can look at something concrete and say, “This won’t work well with the architecture,” or “We should do this differently.” Then we can discuss the actual product rather than spending a meeting trying to understand what the product person meant.
It has also changed how I structure the product itself.
I now think much more modularly. Instead of building one large system where every feature is tightly connected to everything else, I try to create smaller modules that can work independently. That makes it easier to build and test them separately, and it also means we can change or replace one part without having to rethink the entire product.
But there is another reason modularity is becoming important.
If these modules can communicate with each other, they can also communicate with things outside our product.
That means our customers can increasingly build things themselves.
This is where MCP, the open standard Anthropic introduced in November 2024 for connecting AI assistants to external systems, becomes particularly interesting. We now have an MCP server that allows customers to connect AI tools to Rundit and work with their Rundit data and functionality. Instead of every customer request becoming a feature we have to build ourselves, some customers can build their own workflows, tools and automations on top of what we provide.
That changes the product strategy quite significantly.
We don’t just want to build more features inside Rundit. We want to create more connection points that allow Rundit to connect to other systems, AI tools and customer workflows. Building those interfaces is becoming a much higher priority for us because we don’t know all the things our customers will eventually want to build.
The old approach was essentially “Tell us what you need and we’ll build it.”
The new approach can increasingly be “Here are the building blocks. Build what you need.”
That is a much more scalable model.
This is the strange conclusion I’ve reached after spending time with Lovable.
AI has made building software dramatically cheaper. That is a real advantage.
But it has also removed one of the natural constraints that kept products under control: development time.
When something took three days to build, you thought twice about whether you needed it. When AI can build it in ten minutes, that question disappears.
So you need to bring it back yourself.
The bottleneck is moving from “Can we build this?” to “Should we build this?” And then, once you’ve built it, “Does it actually work?”
That is a trade worth making.
I’d much rather spend my time deciding what should exist and testing whether it works than writing tickets about button behaviour.
And the more capable AI becomes, the more I think the job of a product team will be about deciding what belongs in the core product, what should be left for customers to build themselves, and how to give them the building blocks to do it.
That’s the hidden cost of vibe coding, in one sentence: the building got cheap, and nobody moved the bill for correctness anywhere else. For now, at least, the easy part is building it.
Rundit’s MCP server connects Claude or your AI tool to your portfolio and fund data, no export required. Early access starts with a conversation.
