Vibe Coding in Production: What Rundit Team Learned Building With AI 

Building software with AI looks deceptively simple. Describe what you want, and within minutes you have something that resembles a finished product: a polished interface, working buttons, filters, dashboards. This is what Andrej Karpathy called “vibe coding” when he coined the term in February 2025, building by describing intent rather than writing code.

For Goran, Product Lead at Rundit and Greenstep, the portfolio management platform that operates within Greenstep’s Fund Business team, that speed was the starting point of a months-long experiment building with the AI tool Lovable, and a lesson in what that speed actually costs, one with direct implications for any fund relying on software to manage its portfolio and reporting.

Rundit provides a portfolio management platform for venture capital and private equity fund managers, used by global fund managers across 35 countries. The platform centralises portfolio data, automates LP reporting and applies AI to fund reporting workflows. Rundit is independent subsidiary of Greenstep and operates within the Fund Business team. Learn more.

Why does AI-generated software look finished before it works?

AI is extremely good at producing something that looks finished long before it actually is. A beautiful interface, a database behind it, workflows that appear connected, and underneath, a surprising number of things still wrong. Something works in one scenario but not another. A value isn’t saved correctly. One action breaks another part of the application.

“Our team ended up spending an enormous amount of time testing,” Goran says. “I would say around 80% of the work was testing.”

That isn’t unique to Rundit’s 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. Generating functionality quickly also means generating bugs quickly. The coding becomes cheap. Verifying it becomes the expensive part.

AI understands logic. It does not always understand the product.

The clearest example came from building cap table functionality. Goran wanted actions such as issuing shares and editing stakeholders to sit under the cap table itself. Lovable pushed back, reasoning that a cap table is a table, and managing it should be handled separately.

“Technically, that reasoning isn’t completely ridiculous,” Goran says. “From a product perspective, it was wrong. Nobody using a cap table thinks the table and the actions on it should live in different places. AI is very good at recognising common software patterns, but it doesn’t automatically understand the context in which those patterns make sense.”

Similar gaps followed: an ESOP feature with no way to exercise shares, loans with no write-off option, convertible notes that could only convert in full. For a platform that funds and their portfolio companies depend on for accurate reporting, that distinction between technically correct and practically usable is not a minor one.

The overlooked cost of overbuilding

“AI will happily give you ten additional features you didn’t ask for,” Goran says. “Some will be useful. Some will be completely unnecessary. Some will create new problems that are harder to find because everything looks so polished.”

AI does not just build what is asked for. Every one of those features has to be tested, maintained, and understood, whether or not anyone uses it.

There is a less visible cost too. Every feature that ships keeps running and keeps consuming compute, whether or not anyone uses it. Data centre electricity consumption has grown by around 12% a year since 2017, more than four times faster than overall electricity demand, and the International Energy Agency names AI as the main driver. For a product team, that reframes an old instinct in a new way: unnecessary features are not just a maintenance burden, they carry an ongoing resource cost.

“If AI builds something I didn’t ask for, I don’t necessarily need to test it, I can just delete it. That’s often much cheaper.” Goran says.

Building for a more open platform

The experience has changed how Rundit approaches product development more broadly, not toward building faster, but toward building smaller, more independent modules that can be tested, changed, or replaced without reworking the entire platform. That shift also opens the door to something with a direct benefit for fund teams: rather than every request becoming a feature Rundit has to build itself, Rundit’s MCP server now lets customers connect their own AI tools to their Rundit data through MCP, the open standard for connecting AI assistants to external systems, and build the specific workflows their fund needs.

“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,” Goran says.

Knowing what not to build

AI has made building software dramatically cheaper, and that is a real advantage. But it has also removed a constraint that used to keep products disciplined: development time. When something took three days to build, teams thought twice about whether they needed it. When AI can build it in ten minutes, that question disappears, and someone has to bring it back deliberately.

“The bottleneck is moving from ‘can we build this’ to ‘should we build this,'” Goran says. “And then, once it’s built, does it actually work.”

For a platform handling fund reporting and portfolio data, that discipline is not optional, it’s what keeps the product reliable for the funds and back-office teams depending on it every quarter.

What does this mean for funds relying on AI-built software?

What made the experiment work was not the tool. It was a development team experienced enough to spot wrong output, discard what was not needed, and test the rest until it held. AI wrote the code quickly. The team decided what deserved to ship.

Fund managers using AI in their own work should carry the same distinction. For drafting and routine analysis, it earns its place. But the systems holding your portfolio data and producing your LP reporting get read by people outside your fund, and that is the layer where judgment has to be built into the tool rather than added afterwards.

Speed is easy to demonstrate. Reliability only shows up on the quarter you needed it.

Learn how we can support your fund →