The Allure of “Just Describe What You Want”
It sounds magical. Open ChatGPT, Claude, or Cursor. Describe the app you want. Watch code appear. Copy, paste, run. It works. Ship it.
This is “vibe coding”—building software by describing what you want to an AI and accepting whatever it generates. No deep understanding required. No architecture decisions. Just vibes.
And for certain things, it’s genuinely useful. A quick UI mockup. A one-off script. A prototype to test an idea. A personal tool nobody else will use.
But somewhere along the way, vibe coding got confused with building real applications. People started shipping vibe-coded projects to production. To real users. Handling real data.
That’s when vibe coding stops creating apps and starts creating technical debt.
What Vibe Coding Actually Produces
Let’s be honest about what you get when you describe an app and accept generated code:
Code That Works (On the Happy Path)
The AI generates code that does what you asked—when everything goes right. User enters valid data? Works. Network connection stable? Works. Nobody tries anything unexpected? Works.
But production isn’t the happy path. Production is:
- Users entering
<script>alert('hacked')</script>into your form fields - Requests timing out halfway through a transaction
- Two users clicking the same button at the same millisecond
- Someone discovering your API endpoint accepts any request without authentication
Vibe-coded apps handle the demo. They don’t handle reality.
No Security Fundamentals
Ask an AI to build a login form. You’ll get a login form. But will it have:
CSRF Protection? Cross-Site Request Forgery lets attackers trick your users into performing actions they didn’t intend. A proper app includes CSRF tokens on every form submission. Vibe-coded apps? Maybe. Maybe not. Did you think to ask?
XSS Prevention? Cross-Site Scripting lets attackers inject malicious code that runs in your users’ browsers. Every piece of user-generated content needs proper escaping. Did the AI remember everywhere? Did you check?
SQL Injection Protection? The classic. User input goes into database queries without parameterization, and suddenly someone can read your entire database—or delete it. AI-generated code might use an ORM that protects you. Or it might string-concatenate user input directly into queries. Do you know which one you got?
Authentication That Actually Works? Session management. Token expiration. Password hashing with proper algorithms. Rate limiting on login attempts. Account lockout policies. Secure password reset flows.
These aren’t features. They’re the bare minimum. Vibe coding gives you a login form. It doesn’t give you secure authentication.
Obvious Optimizations Missing
AI generates code that works (sometimes). Not code that works efficiently.
- Loading entire database tables into memory to filter in code
- N+1 queries that hit the database hundreds of times for one page load
- No pagination on lists that grow to thousands of items
- Synchronous operations that should be background jobs
- No caching on data that rarely changes
- Images served uncompressed at original resolution
These aren’t edge cases. They’re the first things any experienced developer checks. In vibe-coded apps, they’re time bombs waiting for real usage.
The Part Nobody Talks About: Maintenance
Here’s the uncomfortable truth: deploying an app is the easy part. Maintaining it is where software actually lives or dies.
Day One vs. Day 100
Day One: App works. Users happy. You’re a genius.
Day 30: User reports a bug. You open the code. You don’t recognize it. The AI generated it, and you never really understood it. You ask the AI to fix the bug. It generates new code. Does the fix break something else? You’re not sure. Ship it anyway.
Day 60: You need to add a feature. The codebase has grown through accumulated AI generations. There’s no consistent architecture. Three different patterns for the same problem. Code that duplicates functionality in multiple places. You ask the AI to add the feature. It generates more code. The app gets bigger. Your understanding doesn’t.
Day 100: Something breaks in production. Users are complaining. You need to debug. But debugging requires understanding. You don’t understand—you vibed. The AI that generated the code doesn’t remember generating it. You’re searching through unfamiliar code, written in a style you didn’t choose, following patterns you don’t recognize.
This is technical debt. Not the “we should refactor this someday” kind. The “I don’t understand my own codebase” kind.
Updates Are Harder Than Deployments
- Dependencies have security vulnerabilities and need updates
- The framework released a new version with breaking changes
- A library you depend on got deprecated
- Your hosting provider changed their infrastructure
- New regulations require changes to how you handle data
Every update requires understanding what the code does and how changes affect it. When you vibed the original code into existence, you didn’t build that understanding. Now you need it, and it doesn’t exist.
You can ask AI to update the code. But AI doesn’t understand your specific codebase, your specific users, your specific requirements. It generates plausible code. Plausible isn’t the same as correct.
What Vibe Coding Is Actually Good For
This isn’t a blanket condemnation. Vibe coding has legitimate uses:
Quick UI Mockups
Need to visualize an interface before committing to building it properly? Vibe coding is perfect. Generate a mockup, show stakeholders, iterate on the concept. Throw away the code and build it right if the idea is validated.
One-Off Scripts
A script to rename 500 files. A data transformation you’ll run once. A quick automation for your personal workflow. No users. No maintenance. No problem.
Learning and Exploration
Trying to understand how something works? Generate an example, study it, learn from it. The code isn’t production—it’s education.
Prototypes and Proofs of Concept
Testing whether an idea is feasible before investing in proper development. The key word is “before.” The prototype isn’t the product.
Personal Tools
Apps only you will use, with data only you care about, with security implications only you bear. Your risk, your choice.
Simple Static Sites
A portfolio page. A landing page. Content that doesn’t change and doesn’t handle user data. Low stakes, low complexity, low risk.
What Requires More Than Vibes
The line is clear: when other people depend on your software, vibes aren’t enough.
User Data
The moment your app stores someone else’s information, you’re responsible for protecting it. Password hashing. Encryption at rest. Access controls. Audit logs. Secure deletion. These aren’t optional features—they’re obligations.
Financial Transactions
Payment processing. Account balances. Anything involving money. The consequences of bugs aren’t “that’s annoying”—they’re “someone lost money” or “someone got charged twice” or “we’re liable for fraud.”
Authentication and Authorization
Who can access what? Are you sure? Role-based access control sounds simple until you realize every endpoint, every data query, every action needs proper checks. Miss one, and you have a security hole.
Regulatory Compliance
GDPR. HIPAA. PCI-DSS. SOC 2. Regulations exist because the stakes are high. Compliance requires understanding exactly what your code does with data. “I vibed it” isn’t an answer auditors accept.
Anything That Needs to Scale
Ten users is different from ten thousand. What works in development breaks under load. Scaling requires understanding bottlenecks, optimizing queries, implementing caching, managing connections. You can’t scale what you don’t understand.
Anything That Needs to Be Maintained
If you’re planning to run this software for more than a few months, you’re planning to maintain it. Maintenance requires understanding. Vibe coding trades future understanding for present speed. That trade has a cost.
The Real Cost of Vibe Coding in Production
We’ve seen what happens when vibe-coded applications hit reality:
The Rewrite: Six months after launch, the team realizes they can’t maintain what they built. They understand neither the code nor the architecture. They start over, properly this time. Six months of work discarded.
The Security Incident: Customer data exposed because nobody verified the authentication actually worked correctly. Legal liability. Reputation damage. Mandatory disclosure.
The Performance Crisis: The app worked great with 100 users. At 10,000, it collapsed. No obvious fix because nobody understood why it was slow. Emergency rewrite of core systems.
The Compliance Failure: An audit revealed the application didn’t actually meet requirements. Not maliciously—nobody knew what the code actually did. Failed audit. Lost contract.
The Maintenance Trap: Every bug fix introduces new bugs. Every feature takes longer than the last. The team is afraid to change anything. Eventually, they’re spending all their time maintaining and none building.
This is technical debt. Not theoretical debt. Real cost, measured in rewrites, incidents, failures, and lost time.
The Alternative: AI-Assisted, Human-Understood
The answer isn’t “never use AI for coding.” AI is genuinely useful for accelerating development when used correctly.
The difference is:
Vibe Coding: Describe what you want → Accept generated code → Ship it → Hope for the best
AI-Assisted Development: Understand requirements → Design architecture → Use AI to accelerate implementation → Review and understand generated code → Verify security and performance → Test thoroughly → Ship with confidence → Maintain with understanding
AI becomes a tool in the hands of someone who knows what good code looks like. Not a replacement for that knowledge.
What Good AI-Assisted Development Looks Like
The developer understands the problem domain. They know what the application needs to do, what the edge cases are, what the security requirements are.
Architecture decisions are intentional. The structure of the application is designed, not emerged from accumulated generations.
Generated code is reviewed. Not just “does it run” but “is this the right approach, is it secure, is it efficient, will it be maintainable.”
Security is verified, not assumed. CSRF tokens present. XSS prevention in place. SQL injection impossible. Authentication correct. Not hoped—verified.
Performance is considered. Query patterns examined. Caching strategies implemented. Load testing performed. Not “it seems fast enough on my machine.”
The codebase is understood. Developers can explain what any piece of code does and why. They can debug without asking AI what their own code means.
When to Vibe and When to Build
| Situation | Approach |
|---|---|
| Quick mockup to test an idea | Vibe it |
| Personal tool for yourself | Vibe it |
| One-off script you’ll run once | Vibe it |
| Learning how something works | Vibe it |
| Prototype to validate a concept | Vibe it |
| Anything with real users | Build it properly |
| Anything with user data | Build it properly |
| Anything involving money | Build it properly |
| Anything requiring compliance | Build it properly |
| Anything you’ll maintain long-term | Build it properly |
The question isn’t “can AI generate this code?” The question is “what happens when this code runs in production for the next three years?”
Building Apps That Last
At Cambonu, we build AI applications that go into production and stay there. That means:
- Security fundamentals built in from the start
- Architecture designed for the specific problem
- Code that the team understands and can maintain
- Performance optimized for real-world usage
- Documentation that makes future updates possible
We use AI in our development process—it’s 2026, we’d be foolish not to. But AI assists developers who understand what they’re building. It doesn’t replace that understanding.
The result is applications that work on day one and still work on day 500. Applications that can be updated, scaled, and maintained. Applications that handle edge cases, security threats, and real-world usage.
Not vibes. Not technical debt. Real applications.
Need an AI application built properly? Book a consultation to discuss your project.
About Cambonu
We help businesses create practical AI adoption plans and custom AI applications tailored to their existing infrastructure, budget, and goals. No cookie-cutter solutions. No vibe coding. Projects that actually work beyond the demo phase.
