A new divide emerged in software development this year. Some developers started building entire applications through natural language prompts, prioritising speed over architecture. Others took a less extreme path, using AI as a coding companion to accelerate work while keeping control over design decisions. Understanding when to use each approach and its real tradeoffs has become essential.
What is vibe coding?
Vibe coding means describing what you want in plain language and letting AI generate the entire application. Platforms like Lovable.dev, Bolt, and v0 enable this: you say "build me an app to help teach adults algebra," and in return, you receive a fully functioning application. The goal is less about the perfect architecture and more about iterating rapidly (think working in a permanent hackathon mode). The lines are blurring, too. Tools like Cursor and Claude, typically associated with AI-assisted development, can also be used for full vibe coding if you let them. Hand over complete control, accept every suggestion, let the agent push the commits, and you're vibe coding regardless of the tool.
How does vibe coding excel?
The speed is genuinely transformative. You can move from concept to working prototype in hours rather than weeks. This enables fast market validation, meaning you can test whether users actually want something before investing in its proper development. It also widens the scope of participation. Those who cannot write code are now able to build working prototypes as opposed to waiting in a queue for an engineering resource.
For MVPs and early experiments, vibe coding removes enormous friction. You get instant scaffolding, including authentication flows, databases, and functionality, without needing to configure (or in any depth) understand anything. The question of "should we build this?" becomes something an individual or a team can answer within a matter of hours.
What are the real costs of vibe coding?
Does this sound too good to be true? The downsides are more serious than they initially appear, and they compound rapidly over time.
Invisible technical debt: The code works, so it's tempting to keep building on it; in fact, the hackathon-style approach of vibe coding almost encourages this. The problem is that vibe-coded applications often have architectures which are brittle, a poor separation of concerns and an inconsistent use of patterns. Overall, this creates a mess, and particularly for the less technical individual who often uses this approach, this may not become apparent until something in production breaks. By that point, a handful of more features may have been placed on top of the original mess, creating an even bigger problem.
Debugging woes. When you didn't write the code, understanding why something fails requires reverse-engineering someone else's (or something else's) logic. This is manageable for small applications, but becomes increasingly painful as complexity grows.
Onboarding is harder. When nobody understands how something works ‘under the hood’, documentation is sparse or nonexistent, and nobody can explain why architectural choices were made, onboarding risks are both brittle and long-winded.
Deep architectural thinking can't be prompted. Performance optimisation, complex state management, security, and system design require understanding that current AI cannot provide end-to-end.
What is AI-Assisted Development?
AI-assisted development utilises tools like Cursor, Copilot, or Claude to accelerate the development process while the engineer remains in the driving seat. The AI acts more like a sparring partner, suggesting code, catching bugs, generating boilerplate, and speeding up routine tasks. The primary difference from vibe coding is that developers make the overall architectural decisions and maintain ownership of the business logic.
The mental model matters. A common metaphor used when discussing AI-assisted development is that it is like pair-programming with a junior developer. In some ways, this is true, but it is like pairing with someone who has unusual strengths and some extreme blind spots. They're extraordinarily fast and have broad knowledge, but there are no clarifying questions, they don't understand your codebase's history, and they can suggest solutions with overconfidence. The senior engineer's job, reviewing, questioning, and correcting, absolutely doesn't go away.
Where does AI-assisted development excel?
For experienced developers, the productivity gains are substantial. Code patterns get enforced consistently across the team. Routine tasks, writing tests, updating documentation, and implementing standard operations take a fraction of the time. I performed an upgrade of a UI library in a mobile application, which required me to modify the syntax of a large number of imports. What would have taken some time a few years ago was achieved in minutes. When used well, AI assistance frees senior engineers to focus on the architecture that actually requires human thought.
What are the real costs of AI-assisted development?
The need for pre-existing skills: AI-assisted development makes good developers faster; it doesn't make non-programmers into programmers. You need enough expertise to evaluate suggestions, catch errors, and make architectural decisions that the AI cannot. Accepting the suggestions blindly comes with risks similar to vibe coding.
Generic solutions are the default: The AI solves the problem in front of it, not the system around it. Without careful prompting and context, you get generic solutions that may fix the immediate issue but drift from your architectural vision. It doesn't know your performance requirements, your state management patterns, your users, or the domain-specific edge cases that will bite you later.
Over-reliance is risky: When suggestions come easily, the temptation to accept them without critical thinking can slip in. Teams can gradually drift into a mode where "code that works" and "code we understand" are two different things, and the gap widens without anyone noticing.
Top stories on AI
Emma Williams
Brenden Cambier
Peter Eysermans
Brenden Cambier
When should you use each approach?
There's no binary choice here, but the decision framework is clearer than it might seem.
How to consider pre-product-market fit?
Early-stage startups can lean heavily toward vibe coding. Speed and flexibility matter more than architectural elegance when you're still discovering what to build. Rapid prototyping enables you to test ideas without the overhead of full-scale engineering. The tradeoff of taking on technical debt is acceptable because you're validating an idea, not building a production system.
Just enter this phase with clear eyes: know you're borrowing against the future, and don't pretend the debt doesn't exist. You will need a plan to pay this back later if the idea works.
How to consider post-product-market fit?
Once you've found product-market fit, the game changes, you need systems that can handle growth, both in traffic and in team size. Serving a growing customer base with degrading performance, or onboarding engineers who can't understand the codebase, will cost you. Left unchecked, you risk losing the very gains that vibe coding gave you in the early days. This is when AI-assisted development makes more sense: maintaining velocity while building something sustainable.
What about the mindset split?
The choice also reflects different perspectives and roles. The Product-minded individual will often lean toward vibe coding because it operates at the application level rather than the implementation level. This means that they can stay focused on what the product does rather than how it works. Engineering-minded individuals typically prefer AI-assisted development because they care about the how: the architecture, the patterns, the long-term maintainability and extensibility.
Neither approach is wrong. The key is matching the approach to your current position.
Looking to the future of AI-generated code and vibe coding
The landscape is shifting fast, and some concerning additional risks are emerging. AI models increasingly train on AI-generated code, including vibe-coded applications, which risks creating a feedback loop that degrades suggestion quality over time. Meanwhile, developers who rely heavily on AI assistance from the start of their careers may never build the same depth of understanding as those who came before, even if they develop sharper prompting instincts instead. As more code is generated rather than written, the ability to debug it becomes rarer, precisely when it becomes more essential. The developers who can make sense of unfamiliar, AI-generated codebases may be the scarcest resource of all.
How do I make it all work?
The most successful teams don't pick a side; they match the tool to the moment. Vibe coding for early experiments and rapid validation. AI-assisted development for systems that need to scale and last. The key is understanding these tradeoffs viscerally, not just intellectually. Use both, learn where each breaks down, and build team norms around when to reach for which.
Member discussion