We will come up with a new logo in the future!
Note from Edwin: Hi all - today, we have a new guest writer for the AI To Carry series! Hasan is a former AI engineer at Microsoft AI and a Research Engineer at Citadel Securities (yes, his engineering chops are very legit). He touches on a topic that I think many PE investors and portcos are struggling with, i.e., how do you go from vibe coding to production grade AI tools that drive actual P&L impact?
“I’ll vibe code the CRM for us.”
I’ve heard some version of that line in more than one conversation with non-technical professionals this year. The other classic is “I want to roll this out to the entire company next week,” usually said about an app that has had exactly one user so far: the person who vibe-coded it over a weekend.
To be clear, we love that people are building. An ops lead can now make a working tool in a day (that's what "vibe coding" means: describing what you want to an AI and letting it write the software).
But an app that works in a demo is not the same as a production-grade app that drives real EBITDA improvement. Between the two sits a set of unglamorous problems, and if nobody fixes them, the app that was supposed to save money ends up costing money (e.g., a customer data leak, a billing error, or a week of the CFO apologizing to the top accounts).
This post is for the investor or operator who has to decide which of these apps to trust, which ones can hurt the P&L, and who should own them.
If you’re an AI or tech provider serving the PE ecosystem interested in supporting AI To Carry series with sponsorships, please reply to this email with your company website and budget!
Several PE and indy sponsor backed portfolio companies in the Road To Carry network have worked with Chariot Labs, and the feedback I’ve heard has been very positive, with all engagements leading to additional projects. So if you’re interested in how AI can be embedded into portco to drive real value creation, reach out!
Chariot Labs helps PE-backed companies identify and prioritize where AI can create value, then embeds AI engineers to build and deploy those workflows into their existing systems.
Founded by former PE investors and AI engineers, we specialize in business services, industrial services, and multi-site retail. Our engagements range from field services companies to education services, and include work within the Apax and Stirling Heights portfolio.
Want to know how your competitors are using AI? Book a free call with the Chariot Labs founding team today.
State of Play
Hi, I'm Hasan, cofounder of Chariot Labs, subbing in for Davis this week. I've spent a lot of time taking vibe-coded apps and making them safe and scalable for a business to rely on.
My working view as of November 2026: with current models, it's very easy to vibe code an app that works 90% of the time. The last 10% is where all the liability sits: backups, who is allowed to see what, how updates go live, and simple questions like "what happens when two people click the same button at once?"
For example, after a security incident at Railway (a third party provider that hosts apps on the internet), I helped a client change all of their passwords and access keys. It should have taken 15 minutes, but it took far longer, because the same keys were reused across several apps, so every change broke something else. Nobody had a list of which app used what and basic engineering principles for security simply did not exist.
Unfortunately, this is pretty common. When RedHunt Labs scanned about 130,000 sites built on vibe-coding platforms, roughly 1 in 5 leaked at least one secret (a password or key that unlocks a database, a payment account or another system).
When a vibe-coded app breaks, it doesn't show up as an IT ticket. It shows up as a breach notice to customers, a stack of credit memos, or an account that doesn't renew.
Waiting for “better AI” won't fix it. Veracode tested more than 100 AI models on 80 coding tasks, and 45% of the code they wrote had a well-known security hole.
Recent public failures didn't take a clever hacker. They were mainly caused by somebody skipping the basics because the apps simply “looked finished”:
Lovable. Apps built on this platform shipped without basic rules about who can see which data. A researcher found 170 of them where anyone could pull customers' names, emails and payment status (CVE-2025-48757), and one app on Lovable's own showcase exposed about 18,000 users (The Register, Feb 2026).
Replit and SaaStr. During Jason Lemkin's SaaStr experiment, Replit's AI assistant deleted a live database, while under instructions not to change anything. It then said the data couldn't be restored, which turned out to be wrong (Fortune, July 2025).
OK, enough horror stories.
The first question I get from vibe-code builders at this point is: "Why can't I just tell Claude Code to make it safe?"
Quick answer: you definitely should, and it helps.
But the AI fixes what you ask about, and it may not give you the right answer. The hard part is not only knowing what to ask but also ensuring you have designed for both the (i) “everything goes well” path as well as the (ii) path where “everything goes wrong.” Those questions and design decisions come from having watched apps break in production, and that's most of what a technical review is.
Here's a practical step-by-step on how to decide which apps deserve that technical review and engineering resources.
