Vibe coding is the practice of shipping production software by talking to AI in natural language — and 8 months in, with 500k.io running on it (currently $9,500 MRR and 5K monthly visits), I can confirm it works for solo founders if you treat it as engineering discipline applied to AI, not as “magic.” Most of what’s written about vibe coding online is either hype (“anyone can build apps!”) or dismissive (“it’s just slop”). Both miss the actual practice.
This article is what 8 months of real vibe coding looks like. Not the demos. Not the Twitter threads. The actual workflow that ships software people use and pay for.
If you’ve read Claude Code first 30 days, Plan Mode tutorial, and Cursor for non-engineers, this article is the meta-layer that connects them into a working operating system.
What vibe coding actually is
The term “vibe coding” was popularized by Andrej Karpathy in early 2025 to describe the practice of building software by describing it in plain English to an AI assistant. The “vibe” part is the conversational tone — you’re not writing code; you’re describing what you want and reviewing what the AI produces.
By 2026 the term has matured. The serious practitioners aren’t “vibing” loosely — they’re applying engineering discipline (specifications, testing, version control) to AI-augmented development. The non-serious practitioners are still vibing loosely and producing software that breaks in production within a week.
| Loose vibe coding | Disciplined vibe coding | |
|---|---|---|
| Prompts | ”Build me a thing” | Detailed specifications with file paths, tests, failure modes |
| Output review | ”Looks good, ship it” | Read every diff, run tests, monitor in production |
| Version control | None or random commits | Git discipline, semantic commits, easy rollback |
| Production readiness | Demos only | Tested, monitored, capable of running for months |
| What breaks | Almost everything | Edge cases caught early |
This article describes disciplined vibe coding. The loose version is fun but doesn’t ship real products.
The 4 pillars of my workflow
Eight months in, my vibe coding workflow rests on 4 pillars. Skip any one and the system degrades.
Pillar 1 — The specification (CLAUDE.md)
The single most important file in any vibe-coded project is the spec. I call mine CLAUDE.md (because I use Claude Code primarily). It’s at the root of every project and Claude Code reads it on every session.
What lives in CLAUDE.md:
- What the project is (1-2 paragraphs)
- The stack, locked decisions
- Voice/style rules (banned phrases, conventions, examples)
- The non-negotiables (security, privacy, deletion rules)
- The Definition of Done for any task
- The roadmap pointer (where to find the active sprint)
My 500k.io CLAUDE.md is 580 lines. The Kreators AI internal CLAUDE.md is 410. These files grew from 80-line starters over 6-8 months. Each rule was added because a specific bad output happened once and shouldn’t happen again.
The discipline: every time the AI produces something I didn’t want, I update CLAUDE.md instead of just fixing the output. The file accumulates wisdom over time. By month 4, the file is doing 70% of the quality enforcement.
Pillar 2 — Plan Mode for anything multi-file
For any task that touches more than 2 files, I use Plan Mode. The AI proposes a step-by-step plan; I review every step; I edit if needed; I approve.
The reason this matters: in non-Plan mode, the AI starts editing immediately. By the time you see the first edit, the next 5 are already happening. In Plan Mode, you see the entire intended sequence first. You catch problems before they ship.
Specific example from May 2026: I asked Claude Code to migrate /blog to /journal. Plan Mode came back with a 14-step plan touching 51 files. Step 11 was wrong (it would have modified a file I didn’t want changed). I edited the plan, regenerated, approved. The execution was clean.
Without Plan Mode, that migration would have been a half-correct mess that took 2-3 hours to clean up. With Plan Mode, it took 11 minutes total.
Pillar 3 — Commit discipline
Every working change goes to git within minutes. Not at end of day. Not at end of session. Every working change.
My commit rhythm:
- Small change works → commit
- Bigger change works → commit
- Test passes → commit
- New feature → commit before adding the next one
The reason: vibe-coded software has unpredictable failure modes. The cost of “lost an hour of work because I didn’t commit” is real. The cost of “I want to revert this change but I committed 5 things on top of it” is much higher.
I commit ~15-25 times per week on 500k.io. Many of those commits are 1-line. The discipline isn’t about ceremony; it’s about keeping the rollback granularity tight.
Pillar 4 — Monitoring in production
Anything I deploy gets monitoring. The bare minimum: Slack alerts on errors. The full version: Plausible for analytics, Cloudflare logs for infrastructure, Resend for transactional email delivery, a heartbeat check for each cron job.
When vibe-coded software fails, you want to know within 5 minutes, not 5 days. The cost of monitoring is ~30 minutes per project to set up. The cost of NOT monitoring is “I discovered the cron job hasn’t run in 6 days when I noticed Stripe revenue dropping” — which has happened to me once and I won’t repeat.
For the specific monitoring stack I use, see n8n + AI workflows, which includes 3 monitoring workflows.
What I’ve shipped in 8 months (the receipts)
To make the workflow concrete, here’s what 8 months of vibe coding has produced:
| Project | Description | Status | Notes |
|---|---|---|---|
| 500k.io | The site, Astro + custom components | Production | Live, ~5K visits/mo |
| Agent swarm | 8 named agents with memory + outputs | Production | Runs content factory |
| Notion-briefs MCP | MCP server for content briefs | Production | Personal use |
| Citation tracker (n8n + Notion) | Daily AI citation probe | Production | Runs daily 11am UTC |
| Newsletter draft assembly | Weekly newsletter draft from articles | Production | Fires Fri 5am UTC |
| Lead enrichment pipeline | Tally → Clearbit → Notion | Production | Triggered per form |
| Stripe revenue digest | Daily Slack post | Production | Daily 7am UTC |
| LinkedIn post scheduler | Article → LinkedIn draft | Production | Per article |
| Dead-link monitor | Weekly site crawl | Production | Mondays 4am UTC |
| Auto-internal-links script | Suggests + opens PR | Production | Per article |
| Synapse daily check-in | Replies queued for review | Production | Daily 9am UTC |
| Subscription audit | Monthly tool cost review | Production | 1st of month |
| Cold email reply triage | Inbox triage with classification | Production | Per reply |
| Content factory orchestrator | Brief → draft → audit → commit | Production | Per brief |
| ~33 smaller automation glue scripts | Various one-off and recurring | Production | Various |
Total: ~47 production-running pieces of software shipped in 8 months. Lines of code I personally typed: maybe 200. Lines of code AI produced: ~25,000+.
Of these 47, six have had production issues that required >1 hour of debugging. None has caused permanent data loss or revenue impact. The hit rate is 87% “works without major issue from launch” — which is honestly better than my prior life as an engineer-managing-engineers.
What vibe coding does NOT do well
The hype says vibe coding can do anything. It can’t. Here’s what I avoid vibe coding:
Doesn’t work 1 — Deep refactors without context
Asking Claude Code to “refactor this 3000-line file into 5 smaller modules” works ~60% of the time. The other 40% of the time, the refactor introduces subtle bugs because the AI doesn’t fully understand cross-file dependencies. For these, I either Plan Mode aggressively (multiple rounds of plan editing) or do the refactor manually.
Doesn’t work 2 — Security-critical code
Authentication. Authorization. Payment processing logic. Cryptography. I do NOT vibe code these from scratch. I use battle-tested libraries (Lucia, Better Auth, Stripe SDK, etc.) and only vibe code the integration layer on top. The downside risk is too high.
Doesn’t work 3 — Complex distributed systems
Anything involving 5+ services with coordination requirements (event sourcing, distributed transactions, eventual consistency) gets weird with vibe coding. The AI tends to produce code that works in isolation but breaks under concurrency. For solo founder work, I rarely need this. If you do, hire a real engineer.
Doesn’t work 4 — Performance-critical code
I once vibe-coded a CSV processing script that was 50x slower than necessary. The code was correct, just inefficient. For performance-critical work, you need someone who can think about Big-O and memory profiles. AI can do it but only with explicit prompting; it won’t optimize by default.
The specification skill (the thing that actually matters)
The single biggest skill that separates good vibe coding from bad: writing specifications.
A bad spec:
“Make a script that pulls Stripe data.”
A good spec:
“Build a Python script
scripts/stripe_revenue_digest.pythat:
- Authenticates with Stripe via STRIPE_API_KEY env var
- Pulls all
charge.succeededevents from the last 24 hours (using created_gte)- Groups charges by customer email
- Outputs a markdown table sorted by total amount descending, columns: customer email, charge count, total amount (USD)
- Posts the markdown to Slack channel #morning-numbers via webhook (URL in SLACK_WEBHOOK_URL env var)
- Handles Stripe rate limits with exponential backoff (1s, 2s, 4s, max 3 retries)
- Logs failures to stderr; exits with code 0 on success, 1 on failure
- Has a top-of-file comment explaining what the script does in 3 lines”
The good spec is 8x longer than the bad one. The AI output for the good spec is 10x more useful than for the bad one. Specification time investment: 3 minutes. Output quality difference: night and day.
This is the skill founders should practice. It’s not about typing fast. It’s about thinking precisely about what you want before asking for it. The AI is the compiler; the founder is the architect.
What 8 months of practice has changed for me
Three personal shifts I didn’t expect:
Shift 1 — I’m a better product thinker now
Writing specifications forced me to think harder about WHAT I want before HOW it gets built. By month 6, my product instincts are sharper than they were when I was running a $35M agency. Specification practice is product practice in disguise.
Shift 2 — I’m dramatically faster at MVP-ing ideas
Pre-vibe-coding, an idea I wanted to test required hiring a contractor ($2K-$5K) or learning to code (months). Now an idea costs me 3-6 hours of vibe coding to MVP. I’ve tested 4 product ideas in 8 months. Two of them died fast (good — saved months). One is still alive (Synapse Circle). One is in stealth.
Shift 3 — I trust the agent more, not less
Counter-intuitively, the more vibe coding I do, the more I trust Claude Code. Not blindly — I trust it with the discipline applied. CLAUDE.md, Plan Mode, monitoring. Within that framework, I can hand off tasks I wouldn’t have trusted any team member with after 30 days of work together.
The 30-day vibe coding ramp
If you’re starting today, the ramp:
| Week | Focus |
|---|---|
| 1 | Install Cursor, build first .cursorrules file, ship 3 small one-file projects |
| 2 | Try Claude Code, write your first CLAUDE.md (200+ lines), ship 1 small project |
| 3 | Add Plan Mode to your workflow, try a multi-file task with Plan Mode |
| 4 | Ship your first production-grade automation (e.g., a daily digest), wire monitoring |
By day 30, you should have shipped 4-6 small things. None will be perfect. All should run. The compounding from there is the next 60-90 days of refining your CLAUDE.md and finding the niche where vibe coding earns its keep for your business.
When to graduate beyond vibe coding
There’s a point where vibe coding plateaus. For most solo founders, that point is somewhere around $25K-$50K MRR. At that scale, you have a real codebase, real users, and real consequences for bugs. The shift:
- Vibe coded MVPs → refactored into production-grade code (manually or by hiring an engineer)
- Solo development → small team with one real engineer joining
- “It works” → “It works AND is maintainable by people other than me”
Don’t graduate too early. Don’t refuse to graduate when the time comes. The transition typically happens around 18-24 months from solo start, in my experience.
The honest single-paragraph vibe coding verdict
Vibe coding is the practice of shipping production software via natural-language AI conversations, applied with engineering discipline. It works for solo founders building tools, automation, internal apps, and small SaaS up to ~$50K MRR. It doesn’t work for deep refactors, security-critical code, or complex distributed systems. The single skill that matters most is specification writing — the AI is the compiler, you’re the architect. After 8 months and 47 shipped projects, the workflow holds up. The hype is overstated; the practice is real.
For the wider workflow, see Claude Code first 30 days, Plan Mode tutorial, Cursor for non-engineers, and building your first MCP server.
FAQ
Is 'vibe coding' a real thing or just a meme?
It's both. The term started as a Twitter joke about people building apps by 'vibing' with AI instead of writing code. By 2026 it's a real practice — solo founders shipping production software without writing the code themselves. The meme stuck because the practice works. I've been doing it for 8 months and shipped 500k.io plus the agent swarm without typing a function from scratch.
What's the difference between vibe coding and just using ChatGPT for code?
Scope and discipline. Vibe coding is shipping production tools that run continuously — not asking ChatGPT for a one-off script. It requires a workflow (CLAUDE.md, Plan Mode, commit discipline), not just prompts. The pattern is closer to managing a junior engineer than to asking a chatbot for code.
Will my vibe-coded software break in production?
Yes, sometimes. Every piece of software breaks; vibe-coded software is no exception. The risk profile is different: bugs are more likely in edge cases the prompt didn't specify, less likely in well-defined logic. The mitigation is the same as any engineer's: tests, monitoring, and a rollback plan. I've shipped 47 things vibe-coded; ~6 have had production issues; all were fixable in under 2 hours.
Can vibe coding scale beyond a solo founder?
Up to a point. For solo founder or 2-person operations, yes — see 500k.io and The Kreators AI's internal tooling. Beyond 4-5 people, the lack of typed code reviews, deep architecture decisions, and traditional engineering rigor starts to matter. Vibe coding is for shipping fast at small scale. Larger systems need real engineers.
What's the single biggest skill that separates good vibe coders from bad ones?
Specification writing. Bad vibe coders type vague prompts and accept whatever comes out. Good vibe coders write specifications — what the code does, what files it touches, what tests it passes, what failure modes are acceptable. The specification IS the code, in a sense. The AI is just the compiler.