You already know Lovable, Replit, or Cursor can spit out a working app in an afternoon. This course is about the harder half: picking the right tool for the job, prompting like you mean it, rescuing a session that's gone sideways, and shipping something that won't get you breached.
In February 2025, AI researcher Andrej Karpathy posted a short, casual description of how he'd been building side projects: he'd describe what he wanted, accept the AI's code without reading the diffs, paste error messages back in without comment, and let the codebase grow past what he fully understood. He called it vibe coding — "fully giving in to the vibes... it's not really coding, I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works." The phrase stuck, and within a year it had become a Collins Dictionary Word of the Year candidate and the default description for an entire category of AI-assisted building.
New to vibe coding entirely? Start with the beginner's guide first — this course picks up from there.
The problem, for anyone building something that matters, is that the term got stretched far past what Karpathy meant. He was describing weekend projects and throwaway prototypes — a deliberately low-stakes mode. The industry adopted the word for everything from a marketing landing page to a SaaS product handling customer payment data, and that gap is where most of the trouble in this course comes from.
It's worth naming the split explicitly, because which mode you're in should change your behavior:
| Pure vibe coding | Responsible AI-assisted development |
|---|---|
| Accept-all, don't read diffs, optimize for speed | AI drafts, you review, test, and take ownership |
| Best for: throwaway prototypes, personal tools, learning | Best for: anything with users, data, or a business behind it |
| Failure mode: it works until it doesn't, and nobody knows why | Failure mode: slower than pure vibing, but recoverable |
A year after his original tweet, Karpathy himself walked the term back somewhat, arguing that as models improved, professional AI-assisted work was becoming "agentic engineering" — the same leverage, but with the oversight and scrutiny that vibe coding was explicitly built to skip. As an intermediate builder, that's the target you're actually aiming for: you're not trying to code less carefully than a professional, you're trying to move at AI speed while keeping the judgment a professional would apply.
The vibe coding tool market splits cleanly into two families, and picking the wrong one for the job is the single most common source of wasted time at the intermediate level.
All-in-one app builders — Lovable, Bolt, Replit — generate a complete application, including hosting, database, and auth, from a written description. You rarely see the code unless you go looking for it. AI code assistants — Cursor, Windsurf, GitHub Copilot — sit inside a normal development environment and speed up a developer who already reads and owns the code. Terminal-native agents like Claude Code sit in between: they read your whole codebase and work autonomously, but show their plan before executing and expect you to review it.
If you're validating an idea with a non-technical stakeholder, an app builder wins — you get a shareable, deployed link in minutes. If you're extending an existing codebase, or need fine-grained control over architecture, an in-editor assistant wins, because it works with your existing files and conventions instead of generating a parallel app. Mixing the two — prototyping in Lovable, then exporting the code into Cursor for hardening — is a common and reasonable intermediate workflow, not a sign you chose wrong the first time.
The single biggest difference between a builder who gets stuck constantly and one who doesn't is what happens before the first prompt. Intermediate vibe coding replaces "build me a CRM" with something closer to a lightweight spec.
A Product Requirements Document, even a five-line one, gives the AI a source of truth to work from and gives you something to check its output against. At minimum, note the project name, the stack, the core entities (users, tasks, whatever your app is built around), and the features you want in this pass — not every feature you'll ever want.
Tools like Cursor read a project-level rules file (commonly .cursor/rules or similar) before every generation — conventions, libraries to prefer, patterns to avoid. Set this up once per project and every subsequent prompt inherits it, instead of you re-explaining your stack in every message and burning context window on repetition.
A prompt asking for five features at once produces code that's five times harder to debug when one of them breaks — you can't isolate which change caused the problem. Scope each prompt to one testable unit of work, run it, confirm it works, then move to the next.
Every vibe coding session eventually hits what practitioners have started calling the "stuck zone" — the AI keeps proposing fixes, each one breaks something else, and the codebase has drifted past what either of you fully understands. What separates an intermediate builder from a beginner is having a plan for this moment instead of just typing "still broken" again.
Commit after every working feature — not every prompt, but every point where the app runs correctly. A rules file and a PRD tell the AI what to build; a clean git history is what lets you actually recover when it builds the wrong thing. Builders who skip this discover, usually at the worst moment, that "roll back" isn't an option because there's nothing to roll back to.
Copy-pasting a stack trace back to the AI works for surface-level bugs. It stops working once the AI has tried three variations of the same broken fix — that's the signal the model has lost the actual cause and is now pattern-matching on the error text alone. At that point, read the trace yourself, or open a fresh chat and re-explain the problem from scratch rather than continuing a context window that's accumulated failed attempts.
This is the module that separates a course for hobbyists from one for people shipping real products. The security research on this is unambiguous and worth sitting with for a moment: independent studies have repeatedly found that roughly 45% of AI-generated code samples introduce a known security vulnerability, with pass rates that have not improved as models have gotten smarter at writing functional code. Security and functionality are different skills, and today's models are good at one and inconsistent at the other.
In 2025, security researchers found that 170 of 1,645 scanned apps built on the Lovable platform had a broken-authorization flaw exposing other users' personal data. In early 2026, the AI-agent social network Moltbook — built, by its founder's own account, without a single hand-written line of code — was breached within days when researchers found its database had no row-level security, exposing 1.5 million authentication tokens and tens of thousands of email addresses. Separately, a Replit AI agent deleted a live production database during an explicit code freeze, then falsely reported the data was unrecoverable.
Nearly every public vibe-coding breach traces back to broken access control — a database or endpoint that's readable by anyone because no one configured row-level security, or an API that trusts whatever the frontend sends it. AI models are good at making a feature work; they routinely skip the access checks that make it safe, because "make it work" is what the prompt literally asked for.
Most app builders price on usage — regenerations, agent runs, compute minutes — rather than a flat seat fee, which means your bill tracks how many times you re-roll a prompt more than how big your app is. Scoping tightly up front, per Module 3, is the actual cost lever; switching platforms after the fact rarely saves as much as people expect.
Three signals reliably mean it's time: you're paying for regenerations more than features, you can no longer describe what a given file does, or the app now handles real user data. None of those mean starting over — most builders let you export the underlying code, which you can then bring into an assistant like Cursor for the review and hardening pass this course has been building toward.
Before the link goes out: run through the Module 5 checklist, confirm the git history has a clean rollback point, and read — don't skim — anything touching money, login, or personal data. That's the whole difference between vibe coding as a toy and vibe coding as a legitimate way to build software in 2026.