There's a phrase that has spread through software development over the last eighteen months, and depending on who you ask it's either the future of building software or a warning label. That phrase is vibe coding.
If you've read a LinkedIn post that claims the author "built the whole MVP in a weekend without writing a line of code," you've seen it in action. The results can be genuinely impressive. They can also be a liability waiting to surface in production. Both things are true at once, and understanding the difference is the whole point of this post.
What people actually mean by "vibe coding"
The term was coined by Andrej Karpathy, an OpenAI co-founder and former AI lead at Tesla, in early 2025. His original description was deliberately loose: you describe what you want to an AI, accept what it gives you, and in his words, "forget that the code even exists". You stop considering the build. You just let the model run. It was popular enough to become Collins Dictionary's Word of the Year for 2025.
What's often lost is the context Karpathy gave it. He was describing a way to build throwaway weekend projects, or low-stakes experiments where it genuinely doesn't matter if the code is a mess, because nobody is going to maintain it, secure it, or scale it. As an engineer, he could afford not consider architecture, precisely because the stakes were zero.
Since then the meaning has drifted and "vibe coding" gets used as shorthand for almost any prompt-driven development, including software that ends up in front of real customers handling real data. Which is where the trouble starts.
The trouble with shipping on vibes
The appeal of vibe coding is obvious: it closes the gap between an idea and a working model. You don't need years of experience to get something on screen. For prototyping, learning, and personal tools, that's a wonderful thing and we're all for it.
The problem is what happens when that same approach is used to build something that has to last. When generated code is accepted without understanding it, you inherit a set of risks that don't become obvious until it's expensive to fix them.
- You can't reason about what you don't understand. The job of building production software was never just producing code that works once on your machine. It's producing code that works reliably, can be understood by the next developer, and can be safely extended a year from now. If an AI wrote every line and nobody on the team understands it, the first awkward bug becomes an archaeology project rather than a fix.
- Security gets quietly skipped. Language models produce code that looks plausible, which is not the same as safe. Without someone who knows what to look for, it's easy to ship unsanitised user input, mishandled authentication, secret keys and passwords committed to a visible code, over-permissive access rules, or an endpoint that happily returns data it shouldn't. None of these throw an error in development. They simply sit there until someone finds them — and you'd much rather that someone be you than an attacker.
- The data model is the part you can't easily walk back. You can refactor a controller or restyle a component any time. Restructuring a database that's already full of live customer records is a different kind of weekend. Vibe-coded projects tend to grow their schema reactively, one prompt at a time, and you can end up with duplicated data, missing relationships, no clear source of truth, constraints that were never thought through and expensive or inefficient database interations. By the time the cracks show, the cost of fixing them has compounded.
- The debt is real and it's measurable. This isn't just anecdote. Analysis of hundreds of millions of lines of code over recent years has shown code duplication climbing sharply and churn (code that gets merged and then hastily rewritten) rising fast as AI-assisted development took off. The productivity you borrow on day one tends to come due later, with interest.
None of this is an argument against AI. It's an argument against switching your judgement off.
Our approach: agentic, not vibes
Here's the distinction that matters. Using an AI to write code that you then review, test, and understand isn't vibe coding at all - it's using a very fast, very capable assistant. Karpathy himself uses the term agentic engineering for the disciplined version, and that's much closer to how we at Fuze actually work.
The difference isn't the tools. We use the same agentic coding assistants everyone else does (though my personal preference is Anthropic/Claude). The difference is that we point them at a robust plan.
- We break the project down before we build it. A large, vague prompt produces large, vague code (just as a vague shopping list results in a terrible dinner. So we decompose the work into well-defined, individually verifiable tasks — this model, this migration, this endpoint, this component — each small enough to review properly and reason about in isolation. Agents are genuinely excellent at helping *scaffold* that plan in the first place: sketching the data model, proposing a structure, surfacing the edge cases you hadn't considered. We lean on them for that. We just don't let the plan be implicit.
- We build on well-documented frameworks. This is where a mature framework like Laravel earns its keep. Because it's so thoroughly documented and so widely used, the AI has seen the right patterns thousands of times and produces code that follows established conventions rather than inventing its own. Eloquent gives us a sane, relational data layer instead of ad-hoc queries. The framework's conventions mean any developer on the team, or any future maintainer, can open the project and immediately know where everything lives. The same logic applies across our stack, whether that's a structured CMS like Craft or WordPress or a well-trodden front-end toolchain.
- We reach for first-party packages and common patterns. When the framework's own ecosystem already solves a problem - authentication, payments, queues, validation - we use it rather than letting an agent hand-roll a bespoke version that nobody has battle-tested. First-party packages are maintained, secure by default, and familiar. Common patterns exist because they've survived contact with thousands of real projects. Steering an agent towards them is how you get speed and reliability instead of trading one for the other.
- We keep a human in the loop on every line that ships. The agent drafts. We review, test, and own the result. That's the whole game.
Why this is such a multiplier for experienced developers
The irony of vibe coding is that it's marketed at people with the least experience, when it's most valuable in the hands of people with the most. An experienced developer already has the mental model - the architecture, the security instincts, the sense of where a data structure will hurt later. Agentic coding doesn't replace that judgement; it removes some of the friction around it.
When you already know what good looks like, an agent that can scaffold a plan, write the boilerplate, draft the migrations and rough in the components is an enormous accelerant. You spend your time on the decisions that actually matter - the architecture, the business functions, the trade-offs, the review - and let the agent handle the typing. The work that used to take a week takes a couple of days, and the result is still something you understand, is secure, and can hand to the next person.
That's the bargain we think is worth making. Vibe coding asks you to trade understanding for speed. Agentic coding done properly, lets you keep both, provided you bring the plan.
At Fuze, AI is part of how we build, but it's never a substitute for knowing why we're building it that way. If you've got a project that needs to be fast to ship and built to last, get in touch with the team at FUZE Agency today on 01206 803999. We'd be happy to help your idea grow.
