“Vibe coding” has become one of those terms that means five different things depending on who’s saying it. To some founders, it’s the entire reason they think they don’t need a dev team anymore. To some engineers, it’s a four-letter word for code they’ll be cleaning up for months.
We sat down as a team to talk through our thought on “vibe coding”, how we use AI-generated code, where it earns its place, and where it becomes a liability. Here’s what came out of it.
Vibe coding isn't the same as AI-assisted engineering
This distinction matters more than almost anything else in this conversation, and it’s worth being precise about it. We’d point to Addy Osmani’s writing on this if you want a deeper dive, but the short version is:
- Vibe coding is AI generating code with no human reviewer in the loop. You describe what you want, the AI builds it, and it ships largely as-is.
- AI-assisted (or agentic) engineering is an engineer directing what gets generated, reviewing it, shaping it, and taking responsibility for it, even if the AI wrote every line.
By that definition, most of our code is AI-generated, but we rarely vibe code. One of our engineers prefers the term “agentic engineering” for most of what we do day to day: using tools like Claude Code to generate large amounts of code quickly, but with an engineer steering requirements and reviewing every pull request before it goes anywhere near production.
Where it gets interesting is that our pipeline is also built to take purely vibe-coded work, something a founder or non-engineer built solo in a tool like Lovable or Vercel’s v0, and pull it into our systems, review it properly, and deploy it. Our internal tool ClientPulse is a good example: it was generated in v0, and one of our engineers finished it off, deployed it, and reviewed it before it went live. That’s vibe coding feeding into an engineering process, not replacing one.
Where vibe coding actually shines
Internally, we lean on it constantly, just not for the things people usually assume.
- Rapid prototyping
- Design ideation
- Standalone internal tools
- Exploration & viability
A good example: one of our non-engineers built ClientPulse, a small internal tool in v0 for morning stand-ups, tracking daily client touchpoints with a GitHub-style heatmap. So the team could instantly spot where engagement was dropping. Big buttons, dead simple, exactly tailored to what the team needed. It cost almost nothing and took almost no time to get in front of the team. It only became a real live tool once an engineer gave it a proper backend and deployed it on AWS.
The fact that a non-engineer could build and validate the concept first was the whole point.
Talking a founder through the trade-off
Founders tend to get very excited about shipping fast, and honestly, they should, speed is a genuine advantage. The trick isn’t to talk them out of vibe coding, it’s to build checkpoints into the plan from the start. Throwing away or substantially rebuilding early iterations is completely normal in most product lifecycles, especially in agile environments. A vibe-coded solution can validate the design, the user journey, and the outcomes you’re aiming for.
Our advice is usually to test with users who know they’re testing, then make the deliberate decision to move to a custom-built solution. Once real, production data and real stakes are on the table. Plan early how you will move from vibe coding to production and future scaling.
The signal that you've outgrown vibe coding
From a product and project management lens, it usually comes down to two things: budget and risk.
Budget: if you’re spending more time and money trying to force a vibe-coded or templated solution to do what you need, and still not getting the results. Than you would spend building it properly, that’s your answer. The “cheap and fast” option has quietly become the expensive one.
Risk: if you don’t understand where your data is going, whether it’s secure, and what happens if it’s exploited. You’ve already outgrown a vibe-coded or out-of-the-box solution, whether or not the budget math has caught up yet.
That second point isn’t hypothetical. The Tea app data breach is a devastating real-world example of what happens when security oversight gets skipped in the MVP phase in the rush to ship. The leak was caused by a fundamental lack of manually configured security rules and authentication on their Firebase cloud storage database. The second leak, any user could use developers exposed API keys to access other user’s private chats. Overall, 1.1 million user correspondences were exposed and over 72,000 images including drivers’ licenses and verification selfies were exposed.
There’s also a harder line: as soon as you’re building something that real end users will use in production, storing their actual data, vibe coding alone is no longer appropriate. It’s fine for prototypes. It’s often fine for internal dashboards. It stops being fine the moment real people’s data is on the line and nobody with engineering judgement has reviewed what’s actually happening under the hood.
Sequencing: what to vibe code now, what to build properly later
For a founder with a limited budget or that is reliant on scheduled funding, the sequencing question is really a scope question. Vibe coding is a genuinely low-cost way to validate ideas and test assumptions about design and user behaviour. Projects that stay front-end only, or that touch a very limited backend and no meaningful database, can often stay vibe-coded indefinitely if the results are doing the job.
The moment real backend logic, real data storage, or real regulatory exposure enters the picture, that’s the moment to invest in something built properly. Even if it means going back and rebuilding what the prototype already proved out.
If you’re not sure where that line sits for your product, that’s exactly what our upcoming roadmapping service is for. We work with a lot of founders whose priorities shift with their funding cycle, what’s “safe to leave vibe-coded” at pre-seed looks different once a Series A round means real users, real data, and real scrutiny. A roadmap built with that in mind means budget goes toward the right things at the right stage. Instead of a scramble to rebuild everything the moment funding lands.
What "debugging AI-generated code" actually looks like
According to our research, a large share of developers don’t fully trust AI output. Senior developers often spend more time debugging AI-generated code than human-written code. Which so far matches the experiences of our team.
The biggest recurring issue is technical debt that isn’t obvious at first glance. Coding agents tend to write code that’s technically correct but duplicates logic across different parts of a codebase. Violating the basic “don’t repeat yourself” principle. That’s a real problem down the line: if you need to change that logic, you now have to find and update it in multiple places, and it’s easy to miss one.
The other recurring issue is test coverage that looks solid but isn’t. AI-generated tests often have gaps, they don’t always correctly exercise the functionality they’re supposed to be testing. That creates a false sense of security: you think you’re protected against regressions, and you’re not. The net effect is that reviewing AI-generated code often takes noticeably longer. In contrast to reviewing code a human wrote from scratch, precisely because the errors are quieter and easier to miss.
What healthcare teaches non-regulated startups
Healthcare software has hard regulatory walls, DTAC, DCB0129, DSPT that force oversight whether a founder wants it or not. Most startups don’t have that external pressure keeping them honest, which means the discipline has to be voluntary.
The practical equivalent is simple, even if it’s unglamorous: don’t let AI-generated code reach production. Especially anything touching user data, without a human actually reviewing it, not skimming it, reviewing it. The regulatory frameworks in healthcare exist precisely because the cost of getting security and data handling wrong is so high. Startups outside that world don’t get a pass on the underlying risk just because nobody’s forcing them to check.
This is part of why having a team that’s already worked inside regulated, sensitive-data environments like healthcare matters as a product scales, that rigour transfers naturally to startups that aren’t legally required to have it. Which is exactly the moment a vibe-coded MVP needs to become something that can hold real user data safely.
A real example of where vibe coding went sideways
One of the more honest lessons came from building a client booking dashboard. Instead of running through a proper design phase first, sketching flows in a low-code tool, getting feedback, then building. The decision was made to go straight into vibe-coding a working prototype directly in the production stack using Claude Code.
It was partly a deliberate experiment. ‘Vibe coding’ was picking up momentum as a term, and the team wanted to see whether skipping the design phase would actually pay off.
The dashboard that came out of it works well. But skipping the design phase created its own cost: without a settled sense of what the platform should look like or exactly which features mattered. The team ended up going in circles across several open-ended requirement tickets. Each one carried a large set of loosely-defined requirements, which meant the resulting pull requests were huge and hard to review properly, and each new round of changes was driven by whatever came out of the most recent client meeting, rather than a stable spec.
The lesson: doing the design and requirements-gathering work up front, even in a rough, low-code tool, and then breaking work into specific, well-scoped tickets beats skipping straight to code generation, even when the code generation itself is fast and good.
How the team defines terms related to AI generated code use
We landed on roughly the same place, even coming at it from different angles. One useful framing: vibe coding is more like a black-box, scattergun approach, genuinely useful when you’re short on inspiration and want to see what’s possible. Custom development, by contrast, is what you do once you already know roughly what you want and can describe the moving parts precisely enough to write specific engineering tickets for them.
By that framing, most of wat looks like “vibe coding” inside a proper dev shop is more like agentic engineering. An engineer directing AI tools like Claude Code (or Codex OpenAI’s comparable coding agent, which currently has a strong reputation among our engineers for producing higher-quality output) to generate large volumes of code quickly. With human judgement steering the process and reviewing the result.
Does the gap widen or close?
Our honest guess is that the gap widens, not narrows. As AI coding tools get better, the people who lean on them purely as a black box, without understanding what the generated code is actually doing. Are likely to run into more security issues and harder-to-diagnose bugs over time, not fewer. The tools getting smarter doesn’t remove the need for someone who understands what’s happening under the hood; if anything, it raises the cost of not having that person in the room.
There’s also a real skill gap in how well someone can direct these tools, separate from which tool is objectively “better.” A senior engineer with strong programming fundamentals will consistently get better output from something like Claude Code than a less experienced user will. Simply because they’re faster to spot when something’s subtly wrong. The tool matters less than the judgement of the person steering it.
The bottom line
If we were starting a company tomorrow on a tight budget, the pattern would probably look like this: vibe code the first pass to explore what’s possible and pressure-test the idea, then take the strongest pieces of that prototype into a proper build, with real requirements, drawn from actual stakeholder conversations once it’s clear the idea is worth the investment. We’re not vibe coding, we’re agentic engineering.
‘Vibe coding’ as the most common term for AI generated code use isn’t the enemy, and it isn’t the future replacing engineers either. It’s a front door, cheap, fast, and good at answering “is this idea worth building properly?” The mistake is treating it as the whole house.
