Collins Dictionary named “vibe coding” their Word of the Year for 2025. Andrej Karpathy coined the term in February, describing it as “fully giving in to the vibes, embracing exponentials, and forgetting that the code even exists.” Since then, the conversation has swung between breathless enthusiasm and deep skepticism.
Most vibe coding content falls into two camps. Camp one: non-programmers building todo apps and weather checkers, celebrating the democratization of software. Camp two: professional developers warning about the “vibe coding hangover” and “development hell” when working with AI-generated code.
I’m somewhere in the middle. I’m a CIO at an MSP, not a traditional developer, but I’m not starting from zero either. I took programming courses in college back in the late 90s and early 2000s – enough to understand loops, conditionals, and object-oriented concepts. Over the years I’ve picked up practical skills out of necessity: PowerShell for automation, JSON for APIs and configuration, SQL for database queries, enough HTML and CSS to be dangerous. I spend my days in ConnectWise, Azure, and Microsoft 365 administration. I understand architecture, databases, and APIs – I just don’t write React components for a living.
Over the past several months, I’ve been using vibe coding to build real production systems: internal business tools, client automation platforms, and most recently, a subscription-based SaaS product called Counted Doors.
Here’s what I’ve learned about what vibe coding actually is, what it isn’t, and how to make it work for real projects.
What I’m Building
Counted Doors is a resource platform for foster parents, kinship caregivers, and adoptive families. The name honors foster children who count their placements – each door represents another transition, another home, another count. I’ve fostered 13 children and adopted my daughter, so I know firsthand what resources foster parents actually need versus what well-meaning organizations think they need.
The tech stack is real: Next.js 16 with Turbopack on the frontend, deployed to Vercel. Azure SQL for the database. Azure Functions for the backend. Stripe for subscriptions. Microsoft Entra ID for authentication. The app includes user dashboards, a resource library with downloads, blog functionality, pricing tiers, and account management.
This isn’t a weekend prototype. It’s a production system with 457 deployment files and 75 npm packages.
What Vibe Coding Actually Looks Like
Let me show you what vibe coding isn’t: typing “build me a foster care app” and watching magic happen.
My Claude Code prompt for Counted Doors is over 400 lines. It specifies the tech stack, database schema, API endpoints, authentication flow, content categories, and development standards. Here’s a small sample of what I’m feeding the AI before any code gets written:
## Tech Stack Requirements
- Frontend: Next.js 16+ with App Router, TypeScript, Tailwind CSS
- Backend: Azure Functions (Node.js/TypeScript)
- Database: Azure SQL Database (Serverless tier)
- Auth: Microsoft Entra External ID
- Payments: Stripe
- Storage: Azure Blob Storage for downloads
- Deployment: Vercel (frontend), Azure (backend)
## Database Schema
CREATE TABLE Users (
Id UNIQUEIDENTIFIER PRIMARY KEY DEFAULT NEWID(),
EntraObjectId NVARCHAR(100) NOT NULL UNIQUE,
Email NVARCHAR(255) NOT NULL,
DisplayName NVARCHAR(255),
SubscriptionTier NVARCHAR(50) DEFAULT 'free',
StripeCustomerId NVARCHAR(255),
CreatedAt DATETIME2 DEFAULT GETUTCDATE()
);
CREATE TABLE Resources (
Id UNIQUEIDENTIFIER PRIMARY KEY DEFAULT NEWID(),
Title NVARCHAR(255) NOT NULL,
Description NVARCHAR(MAX),
CategoryId UNIQUEIDENTIFIER REFERENCES Categories(Id),
Tier NVARCHAR(50) NOT NULL, -- free, premium
FileUrl NVARCHAR(MAX),
...
);This continues for pages – API routes, component structure, authentication flows, error handling patterns. The AI is incredibly capable, but it needs context to produce anything useful.
The Reality: Four Failed Builds Before Success
Here’s my actual Vercel deployment history from the first day I pushed Counted Doors to production:
| Deployment | Status | Commit Message |
|---|---|---|
| #1 | ERROR | Initial project setup |
| #2 | ERROR | gitignore: Exclude Claude Code files |
| #3 | ERROR | fix: Exclude api folder from TypeScript compilation |
| #4 | READY | fix: Add vercel.json to configure Next.js output directory |
| #5 | READY | style: Update to Tailwind CSS v4 @theme syntax |
| #6 | READY | feat: Add public pages and SEO improvements |
Four failures before the first successful deployment. The AI generated code that compiled locally but broke in Vercel’s build environment. The fixes required understanding what Vercel expects, how Next.js handles TypeScript compilation, and why certain files needed to be excluded.
This is the reality of vibe coding that the hype cycle ignores. The AI doesn’t automatically know that your Azure Functions folder shouldn’t be processed by Next.js’s TypeScript compiler. You still need to understand your stack well enough to debug these issues.
The Tools I’m Using
My vibe coding toolkit has evolved over time. Here’s what works:
Claude Code in VS Code – This is the workhorse. I give it detailed prompts with project context, and it generates complete files, runs terminal commands, and iterates based on errors. The key is maintaining a CLAUDE.md file in each project with development standards and architectural decisions.
Vercel – Automatic deployments from GitHub. Every push triggers a build. Failed builds give you logs you can paste back to the AI for debugging.
GitHub – Version control that also serves as your project’s memory. Commit messages become documentation of what changed and why.
Azure for Backend – SQL Database, Functions, Blob Storage. The AI can generate Bicep templates for infrastructure-as-code, though I usually set up resources manually first and let the AI work with what exists.
n8n and Zapier – For automation that connects to external systems. Sometimes it’s easier to wire up integrations visually than to code them.
What Makes Vibe Coding Work
After building multiple production systems this way, I’ve identified what actually makes vibe coding successful versus what leads to that “development hell” people warn about.
Domain expertise matters more than coding skills. The reason I can build Counted Doors is that I know foster care. I know that placements often happen at night with zero warning, so resources need to be organized by urgency – what you need in the first hour versus the first week. I know that checklists should include practical items like “check smoke detector batteries” and “find out the child’s school schedule” that official agency paperwork never mentions. The AI can write the code, but it can’t know what foster parents actually need at 2am when a teenager arrives with nothing but a trash bag of clothes.
Detailed prompts produce better results than iteration. The more context you provide upfront, the less time you spend fixing issues later. My prompts include database schemas, API specifications, error handling patterns, and explicit instructions like “never use em dashes in generated content.” Front-loading this work pays dividends.
Development standards still apply. I maintain a standards document that the AI references for every project. No functions over 50 lines. No hardcoded values. Early returns to reduce nesting. Explicit error handling. The AI will follow these rules if you tell it to – and your codebase stays maintainable.
You need to understand architecture, not syntax. I don’t know React’s useEffect dependency array rules from memory. But those college programming courses gave me mental models for how code works – functions, loops, state, scope. Years of PowerShell scripting taught me to think in terms of inputs, outputs, and error handling. When I look at AI-generated TypeScript, I can follow the logic even if I couldn’t write it from scratch. I know that a SaaS platform needs authentication, authorization, database access, file storage, and payment processing. I know how those pieces connect. The AI handles the syntax; I handle the design.
Debugging is part of the process. When a build fails, I paste the error logs back to the AI. Usually it knows exactly what went wrong. Sometimes I need to do some research myself. This is normal. The “forget the code exists” framing is aspirational, not literal.
Add your .claude folder to .gitignore immediately. Ask me how I know. Your Claude Code session notes and project files can accidentally contain credentials, API keys, or sensitive client information that you definitely don’t want living in a public repository forever. Learn from my near-miss and add .claude/ and CLAUDE.md to your .gitignore before your first commit. Future you will send present you a thank-you card.
What Vibe Coding Isn’t Good For
I’ve also learned where vibe coding breaks down.
Complex business logic that requires deep understanding. When I built SmartDispatch, our internal ticket routing system, the AI could generate the code structure. But the actual dispatch logic – which technicians are qualified for which ticket types, how to handle escalations, what constitutes an emergency – required human judgment that I had to encode explicitly.
Security-critical code. Authentication flows, payment processing, access control. The AI can generate this code, but you need to understand it well enough to verify it’s correct. I don’t ship auth code I can’t explain.
Performance optimization. The AI writes functional code, but not necessarily efficient code. Database queries that work fine with 100 records might collapse with 10,000. You need to recognize these patterns.
Maintaining someone else’s vibe-coded project. The September 2025 “vibe coding hangover” articles had a point. If you inherit a codebase where nobody understood what the AI generated, debugging becomes archaeology. This is why I maintain standards documents and actually review what gets committed.
The Realistic Middle Ground
Vibe coding isn’t magic, and it isn’t irresponsible. It’s a new tool with genuine capabilities and real limitations.
For me – a CIO who understands IT architecture but doesn’t write frontend code daily – it’s transformative. I can build internal tools that would have required hiring a developer or purchasing off-the-shelf software that doesn’t quite fit. I can prototype ideas in hours instead of weeks. I can ship real products to real users.
But it requires work. Detailed prompts. Understanding your tools. Debugging failed builds. Maintaining standards. Reviewing generated code. The Y Combinator statistic that 25% of their Winter 2025 batch had 95% AI-generated codebases doesn’t mean those founders sat back and let the AI do everything. It means they directed the AI effectively while understanding what was being built.
If you’re considering vibe coding for a real project, here’s my advice:
Start with a detailed specification. Write out your database schema, API endpoints, and user flows before generating any code. The more you define upfront, the better the results.
Maintain development standards. Create a CLAUDE.md or similar file with your coding standards and reference it in every session. The AI will follow rules you give it.
Expect debugging. Build failures are normal. Error messages are feedback. This is software development, just with a different workflow.
Understand your stack. You don’t need to write React from memory, but you should know what Next.js does, how Vercel deployments work, and why your database schema matters. If you have some programming background – even if it’s rusty college coursework or scripting skills picked up on the job – that foundation helps you recognize patterns in AI-generated code and debug issues faster. If you’re starting from zero, consider spending time with basic programming concepts first. Understanding what a function does, how loops work, and what an API returns will make your vibe coding sessions dramatically more productive.
Own what you ship. If you can’t explain how your authentication works or why your API returns certain data, you’re not ready to deploy. The AI wrote it, but you’re responsible for it.
Vibe coding is real. It works. It has limitations. And for people with domain expertise and architectural understanding, it’s a genuine multiplier. Just don’t expect magic.