I've been vibe coding for a while now - long enough for the novelty to wear off and for the reality to set in.
If you haven't tried it, it's mind-blowingly fast. You describe a vague concept, wave your hands over an LLM and get a working prototype almost immediately. It's development at lightspeed. Projects that would have felt too tedious to even start are suddenly running before you've even had a chance to understand what you've built. However, in my experience I often encounter a liminal boundary where the vibes stop and the god of structural debt comes calling.
For a long time software development has been treated a bit like building a house. You start with a plan: how many rooms? A garage? A pool? You assess the "lay of the land" (your tech stack) and lay the foundations. You don't add the finishing touches (flooring, wallpaper, etc.) until you're sure the house won't collapse. It's methodical, it's slow and it requires you to understand exactly how it all fits together. I'm paraphrasing a lot, but you get the idea.
Vibe coding turns this on its head. It's less like building a house and more like hiring a hyper-fast general contractor. You ask for "a four-bedroom villa with a pool", and — boom — there it is. You don't need to know how to lay a brick or tile a floor; the model handles the assembly, wires together the APIs and presents you with a finished result.
It is incredibly levelling. Suddenly, everyone has access to the same Lego set. I've seen people one-shot entire applications that would have taken a developer a week. I've done it myself. It feels like a superpower.
Until you decide it's so fantastic and you want to add a second story to something that was only ever meant to be a bungalow.
This is the crux of the problem. Vibe coding is an exercise in short-term optimisation. The model is trying to give you exactly what you asked for right now. It isn't necessarily thinking about how that new "killer feature" will fit into the half-formed ideas rattling around in your head. When you change your mind - which we all do - the model does what it does best: it makes it work. It glues a module here and hacks a workaround there. The house still looks great from the outside, but the foundation is starting to look like the Jenga endgame.
I've hit this a lot. I keep prompting, keep layering changes and suddenly the project becomes so brittle that a single, innocent bug-fix causes the backend to implode. A house built on sand won't stand for long.
But there's a deeper, more personal cost: you lose your mental map of the project. When the model does all the heavy lifting in one giant leap, you become a stranger in your "own" codebase. You have the results, but you didn't participate in the engineering decisions. If you want to make any changes yourself, you are working in the dark. This is ok in many cases, but that debt builds and as it does, the harder it is to untangle. (Aside: I think many organisations are going to have a hard time explaining minor errors as "AI did it" - we still need some human oversight).
I often find I hit the cognitive event horizon.
This is the point where the code becomes so complex that it's impossible to untangle. We've all been there, getting carried away and spaghettifying our vibe-coded project.
As a result, I've found myself drifting into a different mode, one that prepares me a bit more for the future. I don't scale back the AI's autonomy, but I do change how I use it. If I play into the "vibe" sentiment, I think of it more as bossy coding*.
(* Aside: I prefer agentic engineering, but at a non-technical level, this is what it is.)
If vibe coding is sketching a house and walking away, bossy coding is standing over the contractor's shoulder and micro-managing them. It's a structured, knowledge-guided cousin of vibe coding. Instead of one big prompt, I break the work into smaller, more procedural and instructive steps. I don't lay the bricks myself, but I tell the agent exactly where they go.
By forcing the model to work in smaller increments, I'm forced to have an understanding of the architecture myself. I'm making conscious design decisions. And since I guide the how, I can understand the why. This means that when the requirements inevitably shift, I actually have an idea of how to adapt. Sure, it's a bit slower, and a lot less playful, but the payoff is a system that doesn't collapse when you need to add something that far exceeds the original scope.
Working in smaller increments also helps solve the alignment problem. You can review the model's intentions before letting it loose. This is exactly what a lot of devs were screaming for and it's why tools like Cursor introduced their "plan" feature. I use it constantly to keep the model on track. This is the difference between quick-and-dirty prototypes and a scalable application. Claude Code has a version of this too.
For me, scale is the real fault line for vibe coding. Small projects - building a single house - work shockingly well. Bossy coding can handle these too, giving you more control and ensuring the foundations are solid. But as you try to move from one house to a town, the challenges multiply. Towns require infrastructure, coordination and long-term planning. You need roads, water, electricity - systems that interconnect reliably. Similarly, larger software projects need strong architecture, clear patterns and explicit design decisions to scale effectively.
Right now, models can handle aspects of this - they can propose structures and manage dependencies - but without technical guidance, expanding a small prototype into a larger application quickly becomes brittle. Bossy coding helps bridge this gap: because you architect the foundations from the start and guide each step, it's much easier to extend the project in a controlled way. Pure vibe coding, by contrast, tends to layer features on top of whatever exists, which works beautifully for small projects but struggles as the system grows. I suspect many devs think they are vibe coding when they are, in fact, bossy coding. It's an inevitability - if you're technical, you can't help but get involved (for now at least).
Future models will perform this much better and do this by default. They will break down large problems and solve them incrementally across a huge number of steps. They might still lose alignment along the way as the task grows, but they will eventually get much better at refactoring and navigating huge codebases. I imagine one day soon the "contractor" will be smart enough to stitch their own decisions together, instead of needing to be told exactly what to do at every turn. We're already starting to see more signs of this with the most advanced models (e.g., Opus 4.5 in Claude Code), but these are still very much being put through their paces (myself included). I want to let that balloon go and let the agents soar, but we're just not quite there yet at scale.
It feels inevitable that in the future we won't need to read or understand code at all. Once new, more advanced models come out they can simply tidy the mess underneath. Or, perhaps there will always be a mess and we'll simply never know. The world has a lot of legacy and most of it is a mess. It's not like every piece of human-written software is perfectly crafted, after all. AI-generated code might be messy and redundant underneath but function perfectly, a bit like the human brain. We understand very little about the brain's low-level wiring and it looks like a chaotic conglomeration of cells with massive redundancy, yet it works. We'll probably just rely on "AI experts" to explain the output of our own systems to us.
We aren't even at the point where AI is writing entire programming languages yet; we just assume everything will be written in the common languages we currently use. If we let AI write its own languages - more efficient, more effective and machine-optimised - we'll be in a whole new ball game. We won't be able to understand these esoteric systems and will rely on the machines to translate. This feels like a dangerous path. This is what Bostrom warned about in Superintelligence, with competence outpacing comprehensibility. The system works fantastically, but in ways we no longer understand or can safely correct. Alignment is a very real concern.
Maybe I migrate to this bossy coding mode of working because I can't quite let go - I don't think this is the case though, I feel I'm getting great value from AI coding tools, but when letting them run fully wild things break down a little.
Manual software development could become like knitting.
Once an essential skill for many, but since industrialisation increased the pace to warp speed, it is now largely a hobby. We'll do it for the satisfaction of the craft, not because it's the most efficient way.
Vibe coding is astonishing - a glimpse into the future where everyone gets a custom, AI-generated window into the world. Bossy coding (or agentic engineering in more technical speak) is a more practical, grounded approach to ensure the foundations are solid enough for a project to actually grow. I'm well aware this is existentially limited, but it's effective for adept developers right now and certainly seems to be the best approach for maximising the models we have (particularly the cheaper models - not everyone has access to $200 per month max plans!). Who knows where we will be in a few months' time?