"We do these things not because they are easy, but because we thought they would be easy." Josh Vial, an AI educator, who works closely with our team, quoted this recently when we were discussing the value - and the risks of vibe coding. Vibe coding is quickly becoming part of modern software engineering, but knowing where it fits is what separates useful speed from risky shortcuts.
Where exactly vibe coding fits in professional software engineering has been coming up regularly in our work over the past few months. In team sessions, in client conversations, in the slightly haunted debrief of someone who spent three weeks untangling something that was supposed to take an afternoon.
It keeps coming up because people are genuinely trying to figure out where it fits in professional software practice. And because it’s almost addictively fun to build something real and solve a problem so rapidly. We're no different than anyone else when it comes to the joy of creation.
As a team of software engineers who have invested big in building out serious agentic development capabilities, vibe coding isn't something we dismiss. But where it exactly it fits in our mahi is an interesting question - and something we're trying to understand deeply. Because the conditions under which it's the right tool are genuinely different from the conditions under which it will quietly ruin your week. Knowing the difference is where things either go easy - or you get a rude awakening.
Vibe coding and agentic coding are not the same thing
Let’s make this distinction early and emphasise that, to us, it matters.
Vibe coding, leaning on Josh's definition, is using AI to produce software you don't understand. You describe what you want, the AI builds it, and you validate whether it works by testing it. You're not reading the code, you're not reasoning about how it works. You're pressing buttons and checking outcomes.
Agentic coding looks similar from the outside but is something quite different. It means running tested, engineered workflows for planning software, evaluating it, refactoring it, testing it, auditing it. As Josh put it: "it can look like you're vibe coding, but what you're doing is leaning on your software factory to produce code for you."
The output of both can arrive quickly. The rigour underneath is not the same.
For us, that distinction shapes everything. We've spent real time building planning workflows, QA processes, documentation systems, and review loops into how we develop software. That's not vibe coding. That's agentic development with human judgement at the gates. Vibe coding is a separate question, and the honest answer is that it belongs in some situations and not others.
When vibe coding is useful
The clearest case is early stage prototyping. When you need a functional sketch to put in front of real people, test an assumption, or communicate an idea before committing to build it properly, vibe coding is a good fit. The code doesn't need to be good. It needs to be good enough to learn from. If you're planning to throw it away regardless, the quality of what's underneath is largely beside the point.
The second case is small, isolated internal tooling. A script that automates something repetitive. A lightweight dashboard. A narrow tool that solves a specific problem for a small number of people. If you can manually test all the meaningful paths through it and you're comfortable with what happens if it fails, you can reasonably trust it enough to use it without understanding every line.
Both cases share the same underlying conditions. The software is bounded. It doesn't touch much else. That means, the consequences of failure are manageable and you’re happy to take those on for the level of investment made. You can see the edges of what it does and verify that it does those things right.
When vibe coding becomes risky
The failure mode is easy to describe and surprisingly easy to drift into.
A small tool that works gets extended. A prototype that was meant to be throwaway turns out to be useful, so it stays. One integration gets added, then another. The surface area grows. At some point you have a system that nobody fully understands, built in a way that makes it expensive and unpredictable to change.
AI is fundamentally additive by nature - and that’s important to keep in mind. It keeps adding to whatever you're building. It doesn't ask whether you need that feature. It doesn't push back on complexity. It doesn't tell you when a project has grown too large for the approach you started with. That's the human's job, and in a vibe coding workflow it's easy to outsource that judgement without quite realising you've done it.
The other risk is subtler. Vibe coded software can look like it works. It passes the tests you thought to run. It handles the cases you anticipated. The gaps live in what you didn't think to check. Traditional software development has decades of practice around finding those gaps. Vibe coding skips most of that process. Sometimes that's fine. When it isn't, the consequences can be hard to trace.
Before starting anything with AI-generated code, three questions are worth asking honestly.
* Can I genuinely isolate this from everything else?
* Can I manually test every meaningful path through it, not in theory but in practice?
* And what actually happens if it fails?
If the answers are yes, yes, and "not much," vibe coding is probably fine. If any of those answers gets complicated, we encourage you to read that as a signal.
The hidden technical debt of vibe coding
There's a longer-term version of this problem that's worth naming.
As building becomes faster and cheaper, the temptation is to build more. Small tools multiply. Scripts accumulate. Each one made sense when it was created. Collectively they add up to a maintenance surface that didn't exist before, often undocumented, poorly understood, and built in ways that make it hard to change safely.
This is a new version of technical debt and it arrives faster than the old kind because the creation is so frictionless. The right question isn't just "can I build this?" It's "do I want to own this in eighteen months?" Often the answer is still yes. But it's worth asking before you start rather than after because that should shape how you proceed.
How to use vibe coding wisely
None of this is an argument against vibe coding. It's an argument for being clear-eyed about where it fits.
In our context, we reckon the teams getting the most value from it aren't using it everywhere. They know when a quick prototype is the right move. They also know when something has grown past the point where that approach still serves them, and they have the agentic workflows to shift gears when it does.
AI makes it easy to drive fast, but the direction must still be yours. There's still nothing more expensive than going quickly … to somewhere you didn't want to end up.
A simple vibe coding checklist
Before starting anything with AI-generated code, ask yourself three questions:
1. Can I genuinely isolate this from everything else?
The less connected a tool is to your wider systems, data, and processes, the easier it is to understand, test, and replace if needed.
2. Can I manually test every meaningful path through it?
Not in theory, but in practice. If you can confidently verify how it behaves across all important scenarios, the risk is much lower.
3. What actually happens if it fails?
If the answer is "not much", vibe coding may be a perfectly reasonable approach. If failure affects customers, operations, revenue, security, or compliance, it's worth slowing down and applying more rigour.
If the answers are yes, yes, and "not much", vibe coding is probably fine. If any of those answers become complicated, that's often a signal that a different development approach is needed.
FAQs
What is vibe coding?
Vibe coding means using AI to produce software you don't fully understand. You describe what you want, the AI builds it, and you check whether it works by testing the output rather than reading the underlying code. It's genuinely useful for early stage prototypes and small isolated tools where the stakes are low and you can verify the behaviour manually. It's a poor fit for anything complex, integrated, or consequential.
How is vibe coding different from agentic coding?
Agentic coding uses tested, engineered workflows for planning, evaluating, refactoring, testing, and auditing software. It can look like vibe coding from the outside because the output arrives quickly, but the process underneath is structured and intentional. The distinction matters in professional software practice because the two approaches carry very different levels of rigour and very different risk profiles.
When should you not vibe code?
When the software needs to integrate with existing production systems, when errors have significant consequences, or when the surface area is too large to verify by hand. The larger and more interconnected a project becomes, the less suitable vibe coding is. Not because the AI can't produce the code, but because the gaps in understanding accumulate faster than the ability to catch and fix them.
What is the sprawl risk in vibe coding?
As software becomes faster and cheaper to build, there's a natural pull toward building more of it. Small tools accumulate and each one made sense individually. The collective result is a maintenance surface that grows faster than the understanding of what it contains. It's a new form of technical debt that arrives more quickly than traditional debt because the creation is so frictionless.
