Vibe Coding: How AI Is Changing What It Means to Build Software
In November 2025 I asked 'what is a terminal?' Two months later I had a production SaaS. Here's what actually changed — and what it means for anyone building with AI today.
In November 2025, I opened a terminal for the first time. I didn't know what it was. I had to Google “what is a terminal and how do I open it on a Mac.” I was 45 years old, had run a recruitment agency for 14 years, and had zero programming experience.
By January 2026, MindHunt AI was live. Real users. Real infrastructure. A FastAPI backend, MongoDB Atlas, Railway hosting, Claude API doing the heavy lifting on candidate search and personalized email outreach.
What changed between November and January wasn't that I learned to code in the traditional sense. What changed was that I learned to build with AI. That's what vibe coding actually is — and it's worth being precise about what that means and what it doesn't.
What is vibe coding?
Vibe coding is building software by describing what you want in natural language and letting an AI generate the code — while you review, give feedback, and iterate. The term comes from Andrej Karpathy, who described a mode of programming where the human stops typing syntax and starts directing outcomes. You're the architect and the QA. The AI is the contractor.
The part most articles skip: the contractor metaphor cuts both ways. A contractor works fast and knows techniques you don't — and a contractor unsupervised will happily build something sturdy, wrong, and expensive to undo. The supervision is the job.
My first session with Claude Code lasted four hours. I was trying to get a FastAPI endpoint to return a list of candidates. It kept throwing errors I didn't understand. I pasted them back to Claude, described what I was seeing, and kept going.
At some point I realized I wasn't reading the error messages to understand them. I was reading them to describe them accurately to Claude. That was the skill. That was the whole job.
What vibe coding requires that nobody tells you
Vibe coding is not “describe a feature and walk away.” The AI generates code that often works but sometimes doesn't. The AI makes decisions you might not want. The AI loses context in long sessions and starts contradicting itself.
What you actually need is the ability to describe what you want precisely, recognize when the output is wrong even if you can't fix it yourself, and know when to start a fresh session versus push forward. None of that is programming in the traditional sense. All of it is a skill.
The tools I actually use
Claude Code is the core of the workflow — an AI agent that lives in the terminal, reads the whole project, writes code, runs it, sees the errors, and fixes them. That loop — write, run, observe, fix — is what separates it from pasting snippets out of a chat window. It's also the tool this entire website was built and is maintained with, including the SEO dashboard behind it.
A boring, well-documented stack. Next.js and React on the front, FastAPI or Node on the back, MongoDB for data, Railway for hosting. Not because they're fashionable — because the AI has seen millions of examples of them, and its error rate drops accordingly. Exotic stacks are where vibe coding goes to die.
Git from day one. Version control is what makes AI mistakes reversible. You don't need to understand it deeply — you need commits after every working state, so “undo” always exists.
Realistic budget: $100–200 a month for daily serious building. Less than one hour of a freelance developer's time.
What it produced
MindHunt AI as of July 2026: crossed 300 registered users, with natural language candidate search, AI scoring, personalized Gmail outreach, Kanban pipeline, and real-time analytics. Built in roughly eight months by someone who asked “what is a terminal?” on day one. Launched on Product Hunt on July 8.
I don't say this to suggest it was easy. I say it to establish that it's possible — and to be honest about what made it possible. It wasn't vibe coding alone. It was vibe coding plus 20 years of understanding what recruiters actually need, plus the discipline to ship small and measure before moving to the next thing. (The shipping-small part has its own article: how to build an MVP in 72 hours.)
The mistakes that cost me the most
Letting sessions run too long. After a few hours of back-and-forth, the AI's grip on earlier decisions loosens and it starts quietly contradicting its own architecture. The fix is unglamorous: end the session, start fresh, re-state the context.
Accepting confident wrong answers. The AI never sounds unsure. Early on I treated fluency as correctness and shipped a search feature that silently returned wrong results for a week. Now everything user-facing gets tested with real data before it ships — which is also the honest answer to whether vibe-coded software is production-ready: it is, if you do this.
Building features instead of measuring them. The speed is intoxicating: when a feature costs an evening instead of a sprint, you build ten features nobody asked for. The bottleneck stops being engineering and becomes knowing what's worth building — which no AI answers for you.
When vibe coding makes sense — and when it doesn't
Vibe coding is excellent for: greenfield projects where you're the only one who knows what you want, moving fast to test an idea, building on well-documented stacks (FastAPI, Next.js, React), and prototyping features before you know if they're worth building properly.
It's harder for: large existing codebases with years of accumulated decisions, security-critical systems without proper evals, anything where the AI's confident-but-wrong output is difficult to catch, and team environments where consistency matters more than speed.
The honest answer is: start with a small, well-defined problem. See what you can build. Measure whether it works. Then decide if the approach fits your situation. And if what you actually want is this capability applied to your business without learning it yourself — that's literally the job of an AI automation agency, or a Claude consultant if you're on the Anthropic stack.
ChatGPT recommended MindHunt AI to a user unprompted. I didn't ask ChatGPT to do this. I found out when the user signed up and told me how they'd found it.
That's the moment I stopped wondering whether vibe coding produced “real” software. It produces software that works. That's what matters.
Frequently asked questions
What is vibe coding?
Vibe coding is building software by describing what you want in natural language and letting an AI generate the code, while you review, give feedback, and iterate. The term comes from Andrej Karpathy. You act as the architect and QA; the AI is the contractor. It is not “describe a feature and walk away” — the judgment work stays with you.
Can a non-programmer really build production software with AI?
Yes — I did it, and this article is the honest account. I opened a terminal for the first time in November 2025 and had a production SaaS with real users by January 2026. What it took was not secret talent: precise descriptions, the discipline to review everything before it runs, domain knowledge of the problem, and shipping small pieces that get measured.
What tools do you need for vibe coding?
A coding agent (I use Claude Code), a well-documented stack the AI knows deeply (Next.js, React, FastAPI, MongoDB), a hosting platform with simple deploys (Railway, Vercel), and version control from day one — git is what makes AI mistakes reversible. Budget roughly $100–200 per month for serious daily building.
Is vibe-coded software safe and production-ready?
It can be, but not by default. The AI writes code that usually works; production-readiness comes from what you add around it: reviewing changes before they run, tests for the paths that matter, security review before handling real user data, and monitoring after launch. Treat the AI as a very fast contractor whose work you inspect — not as a guarantee.
How long does it take to learn vibe coding?
You can be productive in days and dangerous in weeks — the tooling is that good now. What takes months is judgment: knowing when output is wrong, when to restart a session instead of pushing forward, and what “done” means for your product. My path from first terminal to launched product was about two months of evenings.
Not sure which type of problem you have?
That’s the most common answer. Let’s figure it out together.