Vibe Coding

The Complete Guide to AI-Native Software Development

22 chapters. 200+ prompts. Updated monthly. The only vibe coding resource that evolves as fast as the field.

01. The Moment Everything Changed

On February 2, 2025, Andrej Karpathy — former OpenAI co-founder, former Tesla AI director, and one of the most respected voices in machine learning — posted what would become one of the most consequential tweets in software development history:

"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. I just see stuff, say stuff, run stuff, and copy-paste stuff, and it mostly works." — Andrej Karpathy, February 2, 2025

Within weeks, the term had gone viral. Within a month, Merriam-Webster added "vibe coding" as a slang and trending term. By December 2025, Collins English Dictionary named it their Word of the Year.

But vibe coding didn't just enter the dictionary. It entered the economy. It entered boardrooms. It entered the workflows of millions of developers. And it sparked one of the fiercest debates the software industry has seen in decades.

The Timeline

02. What Vibe Coding Actually Is

Strip away the hype, and vibe coding is a specific practice with specific characteristics.

Vibe coding is an AI-assisted software development approach where a developer describes what they want in natural language, an AI model generates the code, and the developer evaluates the result through execution rather than code review. The developer does not read, edit, or attempt to understand the generated code. They test whether it works, and if it doesn't, they feed the error back to the AI.

</div>

  **2.** Accept the generated code without reading it

  **3.** Run it

  **4.** Does it work? Ship it. Doesn't work? Move to Loop 2.

  This is the happy path. For simple features, you may never leave this loop.

</div>

  **2.** Accept the fix without reading it

  **3.** Run it again

  **4.** Repeat until resolved or move to Loop 3.

  Most errors resolve within 1-3 iterations of this loop. The AI sees the error, understands the context, and fixes it.

</div>

  **2.** Describe the desired outcome differently, with more context

  **3.** Return to Loop 1

  This is the escape hatch. If the AI gets stuck in a loop of broken fixes, go back to a clean state and try a different approach. This is why checkpoints matter — always have a rollback point.

</div>

03. The Philosophy: Trusting the Machine

Vibe coding isn't just a technique. It's a philosophical stance about the relationship between developers and code.

The End of Code as Sacred Text

For decades, programming culture has treated source code as something to be crafted, reviewed, optimized, and understood. Code reviews are rituals. Clean code is a moral virtue. Understanding every line is a professional obligation.

Vibe coding rejects this entirely. It treats code as a disposable intermediary between human intent and running software. The code doesn't matter. The behavior matters.

This is not as radical as it sounds. Most software professionals already interact with layers of abstraction they don't fully understand:

• Few web developers read TCP packet internals

• Few application developers audit their compiler output

• Few React developers understand the fiber reconciliation algorithm

• Few SQL users trace query execution plans for every query

  Vibe coding simply adds another layer: the AI becomes the compiler for natural language.

  The Four Pillars

  🎯

  Intent Over Implementation

  "What should this do?" replaces "How should I build this?"

  ⚡

  Speed Over Elegance

  Working software now beats perfect code later

  🤖

  Trust the AI

  Accept all, don't read diffs, let the machine handle it

  📈

  Results-Oriented

  Does it work? That's the only metric that matters

  The Abstraction Argument

  Supporters frame vibe coding as the natural progression of programming abstraction:

  1950s

  Machine Code → Assembly

  "You don't need to write binary opcodes anymore!"

  1970s

  Assembly → C

  "You don't need to manage registers anymore!"

  1990s

  C → Python / Java

  "You don't need to manage memory anymore!"

  2010s

  Frameworks / Cloud

  "You don't need to manage servers anymore!"

  2025

  Natural Language → Code

  "You don't need to write code anymore!"

  At each transition, purists warned that developers were losing essential skills. At each transition, the expanded abstraction enabled more people to build more things.

  ⚠️

  **The counter-argument is real, though:** Every previous abstraction still had deterministic behavior. Assembly always compiles the same way. C always allocates memory the same way. AI code generation is probabilistic — the same prompt can produce different code each time, with different bugs. This is a genuinely new kind of abstraction layer.

04. The Spectrum: Five Levels of AI-Assisted Development

Vibe coding is not binary. In practice, developers operate along a spectrum. Understanding where you sit — and where you should sit for a given project — is critical.

  **When to use:** Security-critical code, regulatory requirements, environments where AI tools are prohibited.

</div>

  **Tools:** GitHub Copilot, VS Code AI extensions

  **Code understanding:** 100% — you review everything

  **When to use:** Production code, team projects, anything you need to maintain

</div>

  **Tools:** Cursor Composer, Claude Code, Codex CLI

  **Code understanding:** 70-90% — you review most things

  **When to use:** Professional development, startup codebases, any code that needs to scale

</div>

  **Tools:** Cursor Agent, Claude Code, Bolt.new

  **Code understanding:** 30-60% — architecture yes, implementation details no

  **When to use:** MVPs, internal tools, prototypes headed toward production

</div>

  **Tools:** Bolt.new, Lovable, Replit Agent, v0

  **Code understanding:** 0-10% — you only test behavior

  **When to use:** Personal projects, throwaway prototypes, hackathons, idea validation

</div>

  **Tools:** Devin, Google Jules, OpenAI Codex (cloud mode)

  **Code understanding:** Review-based — you check the output, not the process

  **When to use:** Routine tasks, migrations, test generation, documentation, with human review gate

</div>

</div>

Take the interactive quiz at the end of this ebook to find out.

<button class="quiz-btn quiz-btn-primary" style="margin-top:0.5rem;" onclick="goTo('ch-quiz')">Take the Quiz &#8594;</button>

05. The Tools: A Complete Landscape (2025–2026)

The tooling ecosystem for AI-assisted development has exploded. The market is consolidating fast — with Cursor at $29.3B, Lovable at $6.6B, Cognition at $10.2B, and billion-dollar acquisition battles playing out in real time. Here's the current state of play across every major category.

AI-Native IDEs

Autonomous Coding Agents

Browser-Based Builders

The Infrastructure Layer: MCP

</div>

06. The Agent Revolution

The most significant development since Karpathy's tweet isn't better autocomplete. It's the emergence of autonomous coding agents — AI systems that independently plan, implement, test, and deploy software.

From Copilot to Colleague

What Agents Can Do Today

Modern coding agents reliably handle tasks that would take a junior developer 4-8 hours:

What Agents Still Struggle With

Cognition's own 2025 performance review of Devin put it well:

"Devin is senior-level at codebase understanding but junior at execution."

• Ambiguous requirements — agents make assumptions that may not match intent

• Complex architectural decisions — they can implement but struggle with system-level design

• Cross-system integration — tasks requiring deep understanding of multiple interconnected systems

• Security context — knowing when something is dangerous requires deployment context, not just code patterns

  The Parallel Execution Advantage

  Unlike human developers, agents can run multiple instances simultaneously, work 24/7, and process entire backlogs of tickets overnight.

  10x

  Faster file migrations (bank case study)

  14x

  Faster repo migrations (Oracle Java)

  20x

  Faster vulnerability remediation

  7.8m

  Average task completion (Devin)

07. Vibe Coding in Practice: Real Workflows

Theory is interesting. Practice is what matters. Here are four concrete workflows for different scenarios.

**Scenario:** You have a product idea and want a working prototype by Monday.

**Tools:** Bolt.new or Cursor + Claude • **Level:** 3-4

1. Write a detailed description (spend 20-30 min — it's the most important step)

  </div>

  <div class="tab-content" id="wf2">
    #### The Startup MVP

    **Scenario:** Building a real product for real users, fast.

    **Tools:** Claude Code + Cursor + v0 &bull; **Level:** 2-3

    1. Start with a product requirements document (even a rough one)
2. Use v0 to prototype key UI screens
3. Use Claude Code to scaffold the full architecture
4. Build feature-by-feature, testing each before moving on
5. Review auth code and data handling; accept UI code freely
6. Deploy to real hosting, set up monitoring
7. Plan a "hardening phase" for security-critical paths

    <div class="callout warning">
      <div class="callout-icon">&#9888;&#65039;</div>
      <div class="callout-content">**The trap:** Skipping step 7. Many YC startups vibe-coded their MVPs successfully but faced "development hell" when trying to scale without hardening.

</div>
    </div>
  </div>

  <div class="tab-content" id="wf3">
    #### The Enterprise Integration

    **Scenario:** Adding a feature to an existing production codebase.

    **Tools:** Claude Code or Devin + CI/CD pipeline &bull; **Level:** 5 with human gate

    1. Create a detailed ticket with acceptance criteria
2. Assign to an AI agent (Devin, Claude Code, or Jules)
3. Agent analyzes codebase, creates a plan, implements the change
4. Agent runs existing test suite and fixes failures
5. Agent opens a pull request
6. Human reviews: security, performance, architecture, edge cases
7. Merge after human approval

    This is Level 5 but with human review as the final gate. It's how most enterprises adopt AI coding in 2026.

  </div>

  <div class="tab-content" id="wf4">
    #### The Solo Creator

    **Scenario:** You're not a developer. You have an idea for an app.

    **Tools:** Lovable, Bolt.new, or Replit Agent &bull; **Level:** 4

    1. Describe your application as if explaining it to a friend
2. Let the builder create the first version
3. Use it yourself — note what's wrong or missing
4. Describe changes in plain language
5. Repeat until satisfied
6. Deploy using the platform's built-in hosting

    <div class="callout danger">
      <div class="callout-icon">&#128308;</div>
      <div class="callout-content">**Critical:** If your app handles user data, sensitive information, or payments, hire a security professional to review it before going live. The Lovable vulnerability study (170/1,645 apps) shows this isn't hypothetical.

</div>
    </div>
  </div>

08. Real-World Case Studies

These are documented, real examples — not hypotheticals.

</div>

</div>

</div>

</div>

</div>

</div>

</div>

</div>

</div>

</div>

</div>

09. The Numbers: Adoption and Impact

The data tells a clear story: AI-assisted development isn't a trend. It's a structural shift.

Adoption

Revenue & Growth

Valuations (Early 2026)

Productivity

Developer Sentiment (March 2026)

Cultural Impact

• Collins Dictionary Word of the Year 2026: "Vibe coding" (named again after 2025)
• MIT Technology Review: Named "Generative Coding" a 2026 Breakthrough Technology
• Merriam-Webster: Added as slang/trending term within one month of Karpathy's tweet
• Wikipedia: Full article with extensive sources and analysis
• Wall Street Journal: Reported widespread professional adoption (July 2025)
• Fast Company: Documented the "vibe coding hangover" (September 2025)
• arXiv: "Vibe Coding Kills Open Source" paper sparks open-source funding debate (January 2026)
• VibeX 2026: First academic workshop on vibe coding, scheduled at EASE conference in Glasgow
• Mainstream: Vibe coding is now a recognized methodology taught in bootcamps and referenced in enterprise strategy documents

10. The Dark Side: Security, Debt, and Failure

For every success story, there's a cautionary tale. The risks are real, documented, and in some cases severe.

The Tenzai Security Study

  **Key finding:** AI tools avoid generic security flaws but struggle where what makes code safe vs. dangerous depends on context.

</div>

</div>

</div>

11. The Great Debate

The software community is deeply divided. Understanding the strongest arguments on each side helps you form a nuanced view.

Programming languages have always moved toward higher abstraction. Assembly to C to Python. Each level lets developers focus on intent rather than implementation. Natural language is simply the next layer.

#### "It democratizes creation."

Millions of people have software ideas but lack years of training. Vibe coding lets a nurse build a patient tracking app, a teacher build a classroom tool, a small business owner build inventory management. The expansion of who can create software is historically significant.

#### "The speed advantage is transformative."

A prototype in hours instead of weeks. An MVP in days instead of months. The 25% of YC companies with 95% AI code didn't choose vibe coding for ideology — they chose it because they needed to move fast.

#### "Traditional code isn't as reliable as we pretend."

Human-written code has bugs, security vulnerabilities, and technical debt too. AI-generated code may have different failure modes, but the idea that human code is inherently reliable is a myth.

Software spending is ~60% maintenance. If nobody understands the codebase, maintenance is impossible. You're not saving time — you're borrowing it from the future at a ruinous interest rate.

#### "Security requires understanding, not just testing."

You can test whether a login form works. You can't easily test whether passwords are properly hashed, session tokens are cryptographically secure, or APIs have rate limiting — unless you read the code.

#### "It creates learned helplessness."

Developers who rely entirely on vibe coding lose fundamental skills. When the AI makes a mistake in a novel way, they have no fallback. Fragile teams build fragile systems.

#### "The economics don't work at scale."

Vibe coding is cheap upfront and expensive later. The $1.5 trillion tech debt projection isn't speculation — it's extrapolation from observed code churn, duplication, and architectural degradation.

The most reasonable position — and the one supported by data — is that vibe coding is a powerful tool with a specific and limited appropriate scope.

<div class="callout success">
  <div class="callout-icon">&#9989;</div>
  <div class="callout-content">
    **It excels for:** prototyping, validation, personal tools, learning, hackathons, and small-scale applications with limited security requirements.

  </div>
</div>
<div class="callout danger">
  <div class="callout-icon">&#10060;</div>
  <div class="callout-content">
    **It fails for:** production systems at scale, security-sensitive applications, regulated industries, and software that needs multi-year maintenance.

  </div>
</div>
**The winning model in 2026:** Vibe code the prototype, then bring in disciplined engineering for the production system. The companies dominating right now — the ones raising at $10B valuations, the ones with $1B ARR in six months — are all betting that this model scales. And the data supports them.

The critics are not wrong about the risks. But they are wrong about the trajectory. Every objection to vibe coding was once made about high-level languages, about frameworks, about cloud computing. The abstraction always wins. The question is never *whether* but *how*.

12. When to Vibe (and When Not To)

🟢 Green Light: Vibe Code Away

🟠 Yellow Light: Proceed with Caution

🔴 Red Light: Don't Vibe Code

13. Mastering the Craft: Advanced Techniques

If you're going to vibe code, do it well. These techniques separate productive vibe coders from frustrated ones.

The Art of the Initial Prompt

The single most important factor in vibe coding success. Spend 30 minutes writing a comprehensive description before generating a single line of code.

Weak vs. Strong Prompts

Key Patterns

  ```

    </div>
  </div>

  <div class="expand-section">
    <button class="expand-header" onclick="this.parentElement.classList.toggle('open')">
      <span class="expand-arrow">&#9654;</span> The "Explain Then Generate" Pattern
    </button>
    <div class="expand-body">
      For complex features, ask the AI to explain its approach before generating code:

      ```
Before writing any code, explain how you would implement
real-time collaborative editing in this application.
What approach? What trade-offs? Then implement it.

  This gives you architectural understanding even in a vibe coding workflow.

</div>

  - **Claude Opus 4.6 (via Claude Code)** — Complex reasoning, architecture, large codebases, agent teams for parallel work

**Good:** "When I click 'Add Task', nothing happens. Console shows: `TypeError: Cannot read property 'push' of undefined at TaskList.addTask (app.js:47)`. This started after I added drag-and-drop."

Include: **action** (what you did), **actual** (what happened), **expected** (what should happen), **error** (verbatim), **context** (what changed recently).

14. Building a Sustainable Workflow

Pure vibe coding is fast but fragile. Here's how to build a workflow that's both fast and sustainable.

Vibe code the 80% (UI, boilerplate, standard patterns).

15. The Business of Vibes

Vibe coding isn't just changing how software is built. It's changing the economics of software businesses.

The New Cost Structure

<p style="margin-top:1rem;"><em>This doesn't mean you never need engineers. It means you can validate before investing.</em></p>

The New Archetypes

The Talent Shift

Companies are increasingly hiring for:

• Specification specialists — translating business requirements into precise AI prompts

• System architects — designing overall structure that AI agents implement

• Security engineers — the human review layer catching what AI misses

• AI-fluent developers — working effectively with and reviewing AI-generated code

  Browse 670+ open AI/LLM positions at LLMHire — the dedicated job board for AI engineers, ML researchers, and prompt engineers.

16. What Comes Next

Now (Early 2026) — Already Happening

• AI-native development is the default. 84% of developers use AI tools. The question has shifted from "should we use AI?" to "how do we use it safely?"

• Agent teams are here. Claude Code's agent teams feature lets multiple AI agents work in parallel on different aspects of a project. This is the beginning of true AI-human hybrid teams.

• The open-source crisis. A January 2026 arXiv paper argues vibe coding threatens the open-source ecosystem: users no longer visit docs, file bugs, or engage with maintainers. Tailwind CSS docs traffic down 40%. Stack Overflow questions in structural decline. How maintainers get paid must change.

• Multimodal coding emerges. Voice-driven coding, visual programming interfaces, and screenshot-to-code workflows are entering mainstream tools.

• Consolidation is accelerating. The Windsurf saga — a $3B acquisition attempt, Microsoft blocking, Google poaching, Cognition acquiring — signals a market entering its consolidation phase. Wix acquired Base44 for $80M cash. Anthropic acquired Bun.

• "Agentic engineering" replaces "vibe coding" for professionals. Karpathy himself has moved beyond the term, now advocating for professionals orchestrating AI agents with oversight, not just vibes.

• The IDEsaster wake-up call. 30+ vulnerabilities across every major AI IDE, 24 CVEs, 1.8M developers at risk. AI code is 2.74x more likely to introduce XSS than human code.

• AI reviews AI code. Anthropic launched Code Review (March 9, 2026) — a multi-agent system inside Claude Code that automatically catches logic errors in AI-generated code. The "who reviews the reviewer" problem now has a commercial answer.

• Claude becomes the enterprise default. Anthropic committed $100 million to the Claude Partner Network (March 12–13, 2026), formalizing partnerships with Accenture, Deloitte, Cognizant, and Infosys. Enterprise AI standardization is no longer theoretical.

• Anthropic hits $380B valuation — Claude #1 on App Store. After refusing Pentagon weapons AI contracts, Anthropic became the most disruptive company in the world (TIME, March 2026). Claude overtook ChatGPT as the #1 app on Apple's App Store. The safety-first bet paid off.

• Agent documentation tooling matures. DeepLearning.AI (Andrew Ng's team) released Context Hub (March 9, 2026) — an open-source CLI tool that gives coding agents real-time access to current API docs, bridging the gap between training cutoffs and fast-moving APIs.

  Near-Term (Late 2026)

  • Security tooling catches up. Agentic security tools reviewing AI code in real-time. "Move security into the act of creation."

• Standardization emerges. Enterprise governance frameworks for AI-generated code.

• Agent orchestration matures. Specialized agents for frontend, backend, testing, security working in concert under a lead agent.

• Open-source funding models evolve. New models for compensating maintainers whose libraries power AI-generated code.

  Medium-Term (2027-2028)

  • Natural language becomes a programming interface. Not replacing code, but a legitimate authoring medium.

• AI-human hybrid teams are standard. Every team includes both human engineers and AI agents with defined roles.

• The maintenance problem gets addressed. AI tools that understand, refactor, and improve AI-generated code.

• Specialized domain models. Finance, healthcare, embedded — each gets domain-specific AI models.

  Long-Term (2029+)

  • Intent-driven development. Describe outcomes, constraints, quality attributes. AI handles the rest.

• Self-healing software. Applications that detect bugs in production and fix themselves.

• The abstraction continues. The role evolves from "code author" to "system designer and quality guardian."

  🔮

  **The fundamental question:** AI will write an increasing share of the world's software. The question isn't whether — it's how we ensure it's secure, reliable, and maintainable. The developers who thrive will master both modes: vibe code a prototype on Saturday, architect a production system on Monday.

  Conclusion

  In twelve months, vibe coding went from a tweet to a dictionary entry to a multi-billion-dollar industry. Cursor alone is valued at $29.3 billion. Lovable at $6.6 billion. A vibe-coded startup sold for $80 million. GitHub Copilot has 4.7 million paid subscribers. Now, in early 2026, it has become the defining methodology of a new era in software development.

  The numbers speak for themselves: Claude Code reached $1B ARR in six months. Cursor surpassed $1B ARR at a $29.3B valuation. Devin surpassed $155M ARR at a $10.2B valuation. GitHub Copilot crossed 4.7 million paid users. These are not experimental products. This is the new infrastructure of software creation.

  The promise is real and accelerating: agent teams working in parallel, multimodal coding interfaces, and tools so capable that 75% of Replit's AI users write zero code themselves. The barrier between idea and working software has never been lower.

  The challenges are evolving too: the open-source ecosystem faces an existential funding question, security remains a real concern with 69 vulnerabilities found across just 15 AI-built apps, and the "vibe coding hangover" of unmaintainable codebases is a documented phenomenon.

  But the answer has become clear. Vibe coding is not a fad to be dismissed or a silver bullet to be worshipped. It is a powerful methodology that belongs in every developer's toolkit. The developers who thrive in 2026 and beyond will be those who master the spectrum — knowing when to vibe code a prototype on Saturday, when to collaborate with agents on Monday, and when to insist on human-reviewed engineering for the critical 20%.

  The vibes are real. The exponentials are real. The opportunity is unprecedented.

  Embrace the vibes. Engineer the foundations. Build the future.

Chapter 17: The Complete Prompt Library

203+ production-ready prompts for every stage of AI-native development. Updated monthly.

How to Use This Library

Each prompt is tagged with:

• Difficulty: Beginner / Intermediate / Advanced / Expert
• Tool: Which AI tools it works best with
• Time: Expected completion time
• Category: What type of work it handles

The prompts are designed to be copy-pasted directly. Customize the bracketed [sections] for your specific project.

Category 1: Project Kickoff Prompts

1.1 The Complete Spec Prompt (Expert)

Tool: Claude Code, Cursor Composer | Time: 30-60 min generation

I'm building [product name], a [type of application] for [target audience].

## Product Vision
[One-sentence description of what this product does and why it matters]

## Target Users
- Primary: [who, age range, technical skill level, key pain point]
- Secondary: [who, why they'd use it]

## Core Features (MVP - Priority Order)
1. [Feature 1]: [User story: "As a [user], I want to [action] so that [benefit]"]
2. [Feature 2]: [User story]
3. [Feature 3]: [User story]

## Data Model
- [Entity 1]: [fields and types]
- [Entity 2]: [fields and types]
- Relationships: [Entity 1] has many [Entity 2], etc.

## Design Direction
- Style: [modern/minimal/playful/corporate/brutalist]
- Color palette: [primary hex, accent hex, background]
- Typography: [sans-serif/serif/mono, reference sites]
- Layout: [single page / multi-page / dashboard / wizard]
- Responsive: [mobile-first / desktop-first / both]

## Technical Stack
- Framework: [Next.js / React / Vue / Svelte / vanilla]
- Styling: [Tailwind / CSS Modules / styled-components]
- Database: [Supabase / Firebase / localStorage / Prisma+PostgreSQL]
- Auth: [Supabase Auth / NextAuth / Clerk / none]
- Hosting: [Vercel / Netlify / Railway]

## What Success Looks Like
- A user can [core workflow] in under [N] steps
- The app loads in under [N] seconds
- [Specific measurable outcome]

## What This Is NOT
- Not a [common misunderstanding]
- Don't include [feature to avoid]
- Don't over-engineer [aspect]

Build the complete MVP. Start with the data model, then core layout, then features in priority order.

1.2 The Weekend Prototype Prompt (Beginner)

Tool: Bolt.new, Lovable, Replit Agent | Time: 15-30 min

Build a [type of app] that solves this problem: [describe the pain point in one sentence].

The main user is [who] and they need to:
1. [Core action 1]
2. [Core action 2]
3. [Core action 3]

Design: Clean and modern. Use [color] as the accent color. Dark mode preferred.
Store data in localStorage.
Make it work on mobile.

Keep it simple. I'd rather have 3 features that work perfectly than 10 that are buggy.

1.3 The "Clone This" Prompt (Intermediate)

Tool: Cursor, Claude Code | Time: 1-2 hours

Build a simplified version of [well-known app, e.g., Trello/Notion/Slack].

Include ONLY these features from the original:
1. [Feature to clone]
2. [Feature to clone]
3. [Feature to clone]

DO NOT include: [features to skip]

Match the general layout and UX patterns of the original but use your own design.
Use [tech stack]. Deploy-ready for Vercel.

Focus on making the core interaction feel as smooth as the original.

1.4 The Landing Page Prompt (Beginner)

Tool: v0, Bolt.new | Time: 15-30 min

Create a conversion-optimized landing page for [product name].

Product: [One line description]
Target audience: [Who would buy this]
Price: [Price point or "Free"]

Sections (in order):
1. Hero: Headline "[compelling headline]", subheadline "[supporting text]", CTA button "[button text]"
2. Problem: 3 pain points the audience faces
3. Solution: How the product solves each pain point (with icons or illustrations)
4. Social proof: [testimonials / stats / logos / "As seen in"]
5. Features: 3-6 key features with brief descriptions
6. Pricing: [pricing tiers if applicable]
7. FAQ: 4-5 common questions with answers
8. Final CTA: Repeat the main call-to-action

Design: Professional, trustworthy. Primary color [hex]. Lots of whitespace.
Mobile-responsive. Fast-loading (no heavy images).
Include Open Graph meta tags for social sharing.

Category 2: Feature Addition Prompts

2.1 Authentication System (Advanced)

Tool: Claude Code, Cursor | Time: 1-2 hours

Add a complete authentication system to this [framework] application.

Requirements:
- Email/password signup with email verification
- Login with session management (HTTP-only cookies, not localStorage)
- Password requirements: minimum 8 chars, 1 uppercase, 1 number, 1 special char
- "Forgot password" flow with email reset link (expires in 1 hour)
- "Remember me" option (extends session to 30 days, default is 24 hours)
- Rate limiting: max 5 failed attempts per IP per 15 minutes, then 30-min lockout
- CSRF protection on all auth forms
- Secure headers: HSTS, X-Content-Type-Options, X-Frame-Options

Auth provider: [Supabase Auth / NextAuth / Clerk / custom JWT]

Protected routes: [list routes that require auth]
Public routes: [list routes that don't require auth]

After login, redirect to [dashboard/home/previous page].
Show clear error messages for: wrong password, account not found, account locked, email not verified.

Write tests for: successful login, failed login, signup validation, session expiry, rate limiting.

2.2 Payment Integration (Advanced)

Tool: Claude Code | Time: 2-3 hours

Add [Stripe / Paddle] subscription billing to this application.

Products:
- Free tier: [what's included, usage limits]
- Pro tier: $[price]/month - [what's included]
- [Optional: Enterprise tier: $[price]/month - [what's included]]

Implementation:
1. Pricing page showing all tiers with feature comparison
2. Checkout flow: user selects plan -> [Stripe Checkout / Paddle Overlay] -> redirect to success page
3. Webhook handler for: subscription.created, subscription.updated, subscription.cancelled, invoice.payment_failed
4. User dashboard showing: current plan, next billing date, usage this period, upgrade/downgrade buttons
5. Usage tracking: count [what metric] per billing period, enforce limits on free tier
6. Graceful downgrade: when subscription cancelled, access continues until period end
7. Failed payment handling: 3 retry attempts over 7 days, then downgrade to free

Store subscription status in [Supabase / database].
Add middleware to check subscription status on protected API routes.
Show upgrade prompts when free users hit limits.

Environment variables needed:
- [STRIPE_SECRET_KEY / PADDLE_API_KEY]
- [STRIPE_WEBHOOK_SECRET / PADDLE_WEBHOOK_SECRET]
- [STRIPE_PRO_PRICE_ID / PADDLE_PRO_PRICE_ID]

2.3 Real-Time Features (Advanced)

Tool: Claude Code, Cursor | Time: 2-4 hours

Add real-time [collaboration / notifications / live updates] to this application.

What should update in real-time:
- [Specific data that changes: "new messages", "task status changes", "user presence"]

Technology: [Supabase Realtime / Socket.io / Pusher / Server-Sent Events]

Requirements:
- Changes made by User A appear for User B within [1 second / 500ms]
- Show [typing indicators / presence dots / live cursors] for active users
- Handle disconnection gracefully: show "reconnecting..." banner, auto-reconnect with exponential backoff
- Dedup messages that arrive during reconnection
- Don't poll - use persistent connections
- Fallback to polling if WebSocket connection fails

Optimize for:
- [N] concurrent users per [room / document / channel]
- Messages/updates of approximately [size] bytes each
- Mobile networks with intermittent connectivity

Show connection status indicator (green dot = connected, yellow = reconnecting, red = offline).

2.4 Search and Filter System (Intermediate)

Tool: Any | Time: 30-60 min

Add search and filtering to the [items/products/posts] list in this application.

Search:
- Full-text search across: [field 1], [field 2], [field 3]
- Debounced input (300ms delay before searching)
- Show "X results for 'query'" count
- Highlight matching text in results
- Empty state: "No results for 'query'. Try different keywords."

Filters:
- [Filter 1]: [type: dropdown/checkbox/range] with options [list options]
- [Filter 2]: [type] with options [list options]
- [Filter 3]: [type] with options [list options]
- Date range: from/to date pickers
- Sort by: [option 1 / option 2 / option 3], ascending/descending

Behavior:
- Filters combine with AND logic (search + filter1 + filter2)
- Show active filter count as badge on filter button
- "Clear all filters" button when any filter is active
- URL params reflect current filters (shareable filtered views)
- Persist last-used filters in localStorage

Performance:
- Client-side filtering for under 1000 items
- Server-side (API) filtering for larger datasets
- Show loading skeleton while filtering

Category 3: UI/UX Prompts

3.1 Dashboard Layout (Intermediate)

Tool: v0, Cursor | Time: 30-60 min

Build a dashboard layout for [application type].

Layout:
- Left sidebar: navigation menu (collapsible on mobile, icons + labels)
- Top bar: user avatar + dropdown menu, notification bell with count badge, search bar
- Main content area: responsive grid that adapts from 1 to 3 columns

Sidebar navigation items:
1. [Icon] Dashboard (home)
2. [Icon] [Section 1]
3. [Icon] [Section 2]
4. [Icon] [Section 3]
5. [Icon] Settings
6. [Icon] Help

Dashboard home shows:
- Row 1: 4 stat cards ([Metric 1]: [value], [Metric 2]: [value], etc.)
- Row 2: Main chart (line chart showing [metric] over [time period]) + recent activity feed
- Row 3: Quick actions grid (3-4 action cards with icons)

Design: [light/dark] theme. Accent color: [hex].
Use Tailwind CSS. Smooth transitions on sidebar toggle.
Mobile: sidebar becomes a hamburger drawer overlay.

3.2 Form with Validation (Beginner)

Tool: Any | Time: 15-30 min

Build a multi-step form for [purpose, e.g., "user onboarding", "job application", "event registration"].

Steps:
1. [Step name]: Fields: [field1 (type, required?), field2, field3]
2. [Step name]: Fields: [field4, field5, field6]
3. [Step name]: Review all entered data + submit button

Validation:
- Email: valid format + show error immediately on blur
- Phone: format as (XXX) XXX-XXXX as user types
- Required fields: show red border + error message
- [Custom validation]: [describe rule]

UX:
- Progress indicator showing current step (1/3, 2/3, 3/3)
- "Back" and "Next" buttons (Next disabled until current step is valid)
- "Save as draft" option (localStorage)
- Smooth slide transition between steps
- Auto-focus first field on each step
- Show success animation on submit

Accessible: proper labels, aria attributes, keyboard navigation (Tab through fields, Enter to submit).

3.3 Data Table (Intermediate)

Tool: Any | Time: 30-60 min

Build a data table component for displaying [data type, e.g., "user list", "order history", "inventory"].

Columns:
1. [Column]: [type: text/number/date/status/avatar] - [width: narrow/medium/wide]
2. [Column]: [type] - [width]
3. [Column]: [type] - [width]
4. Actions: Edit, Delete, [custom action]

Features:
- Sort by clicking column headers (asc/desc, show arrow indicator)
- Select rows with checkboxes (select all, bulk actions)
- Inline editing: click cell to edit, Enter to save, Escape to cancel
- Pagination: 10/25/50 per page selector, page numbers, total count
- Responsive: on mobile, switch to card layout (one card per row)
- Empty state: illustration + "No [items] yet. Create your first one."
- Loading state: skeleton rows while data loads

Styling: Clean borders, alternating row colors, hover highlight.
Status column: colored badges (green=active, yellow=pending, red=inactive).

Category 4: API and Backend Prompts

4.1 REST API Scaffold (Advanced)

Tool: Claude Code | Time: 1-2 hours

Build a REST API for [application] with these resources:

Resources:
1. [Resource 1, e.g., "Users"]:
   - Fields: [id, name, email, role, created_at, updated_at]
   - Endpoints: GET /api/users, GET /api/users/:id, POST /api/users, PUT /api/users/:id, DELETE /api/users/:id

2. [Resource 2]:
   - Fields: [list fields]
   - Endpoints: [list CRUD endpoints]
   - Relationships: [belongs_to Resource1, has_many Resource3]

Response format (all endpoints):
Success: { data: {...}, meta: { page, limit, total } }
Error: { error: { code: "VALIDATION_ERROR", message: "Email is required", details: [...] } }

Requirements:
- Input validation with descriptive error messages
- Pagination: ?page=1&limit=20 (default limit=20, max=100)
- Filtering: ?status=active&role=admin
- Sorting: ?sort=created_at&order=desc
- Rate limiting: 100 requests per minute per IP
- CORS configured for [allowed origins]
- Request logging (method, path, status, duration)

Auth: Bearer token in Authorization header.
- Public endpoints: [list]
- Authenticated endpoints: [list]
- Admin-only endpoints: [list]

Framework: [Next.js API routes / Express / Fastify / Hono]
Database: [Supabase / Prisma / Drizzle]

4.2 Database Schema Design (Advanced)

Tool: Claude Code | Time: 30-60 min

Design a database schema for [application type].

Entities:
1. [Entity 1]: [description of what it represents]
   - Required fields: [list]
   - Optional fields: [list]
   - Unique constraints: [list]

2. [Entity 2]: [description]
   - Fields: [list]
   - References: [Entity 1] (one-to-many / many-to-many)

Business rules:
- [Rule 1, e.g., "A user can only have one active subscription"]
- [Rule 2, e.g., "Orders must have at least one line item"]
- [Rule 3, e.g., "Soft delete for users, hard delete for sessions"]

Generate:
1. SQL migration file with CREATE TABLE statements
2. Indexes for common query patterns: [list queries, e.g., "find users by email", "get orders by date range"]
3. Row-level security policies (if Supabase)
4. Seed data: 10-20 realistic sample records per table
5. TypeScript types matching the schema

Optimize for: [read-heavy / write-heavy / balanced]
Database: [PostgreSQL / MySQL / SQLite]

Category 5: Testing and Quality Prompts

5.1 Comprehensive Test Suite (Advanced)

Tool: Claude Code | Time: 2-4 hours

Write a comprehensive test suite for this [application/module].

Testing framework: [Vitest / Jest / Playwright / Cypress]

Coverage targets:
- Unit tests: all utility functions and business logic (aim for 90%+)
- Integration tests: all API endpoints (happy path + error cases)
- Component tests: all interactive components (user events + state changes)
- E2E tests: [list 3-5 critical user flows]

For each test, include:
- Clear descriptive name: "should [expected behavior] when [condition]"
- Arrange-Act-Assert structure
- Realistic test data (not "test123" or "foo bar")
- Error case coverage (invalid input, timeout, auth failure)
- Edge cases ([list specific edge cases for this app])

Mock strategy:
- External APIs: mock with [MSW / jest.mock / vi.mock]
- Database: use [test database / in-memory / fixtures]
- Time-dependent tests: mock Date.now()
- File system: use temp directories

Run the complete suite after writing. Fix any failures.
Generate a coverage report.

5.2 Security Audit Prompt (Expert)

Tool: Claude Code | Time: 1-2 hours

Perform a security audit of this codebase. Check for:

1. Authentication & Authorization:
   - Are passwords hashed with bcrypt/argon2 (not MD5/SHA)?
   - Are sessions stored securely (HTTP-only cookies, not localStorage)?
   - Is CSRF protection implemented on state-changing requests?
   - Are API keys and secrets in environment variables (not hardcoded)?
   - Are authorization checks on every protected endpoint (not just frontend)?

2. Input Validation:
   - Is all user input validated server-side (not just client-side)?
   - Are SQL queries parameterized (no string concatenation)?
   - Is HTML output sanitized to prevent XSS?
   - Are file uploads validated (type, size, name)?
   - Are URL redirects validated against an allowlist?

3. Data Protection:
   - Is sensitive data encrypted at rest?
   - Is HTTPS enforced (HSTS headers)?
   - Are API responses filtered (no password hashes, internal IDs leaking)?
   - Is PII handled according to GDPR/CCPA requirements?
   - Are error messages generic (no stack traces to users)?

4. Infrastructure:
   - Are dependencies up to date (no known CVEs)?
   - Are security headers set (CSP, X-Frame-Options, etc.)?
   - Is rate limiting configured on auth and API endpoints?
   - Are CORS origins restricted (not "*")?
   - Are logs sanitized (no passwords or tokens in logs)?

For each issue found:
- Severity: Critical / High / Medium / Low
- Location: file path and line number
- Description: what's wrong and why it matters
- Fix: specific code change to resolve it
- Test: how to verify the fix works

Prioritize fixes by severity. Implement Critical and High fixes immediately.

Category 6: Refactoring and Optimization Prompts

6.1 Performance Optimization (Advanced)

Tool: Claude Code | Time: 1-2 hours

This application is slow. Analyze and optimize performance.

Symptoms:
- [Specific symptom: "initial page load takes 4+ seconds"]
- [Specific symptom: "scrolling is janky with 500+ items"]
- [Specific symptom: "API response takes 2+ seconds"]

Investigate and fix:
1. Bundle size: analyze with [next/bundle-analyzer or similar], remove unused dependencies, implement code splitting
2. Rendering: identify unnecessary re-renders, add React.memo/useMemo/useCallback where appropriate
3. Data fetching: implement caching, pagination, reduce payload sizes
4. Images: lazy load below-fold images, use next/image or responsive srcset, serve WebP
5. Database: add missing indexes, optimize N+1 queries, implement connection pooling
6. Network: enable gzip/brotli, set proper cache headers, minimize HTTP requests

For each optimization:
- Before: [metric measurement]
- After: [expected improvement]
- Method: [specific code change]

Run Lighthouse audit before and after. Target scores: Performance >90, Accessibility >95.

6.2 Code Cleanup (Intermediate)

Tool: Claude Code, Cursor | Time: 1-2 hours

Clean up this codebase without changing any functionality.

Tasks:
1. Remove dead code: unused imports, unreachable functions, commented-out blocks
2. Consolidate duplicated logic: find similar code patterns and extract shared utilities
3. Fix naming: rename variables/functions that don't describe their purpose
4. Organize file structure: group related files, consistent naming conventions
5. Add TypeScript types: replace 'any' with proper types, add interfaces for data shapes
6. Fix linting issues: run [ESLint / Prettier] and fix all warnings/errors
7. Update dependencies: check for outdated packages, update non-breaking versions
8. Add JSDoc comments to exported functions (not internal helpers)

Rules:
- Make small, focused commits (one type of change per commit)
- Run tests after each change to ensure nothing breaks
- Don't refactor code that has pending changes or open PRs
- Keep the diff readable: don't auto-format unrelated files

Category 7: Deployment and DevOps Prompts

7.1 Production Deployment Checklist (Advanced)

Tool: Claude Code | Time: 1-2 hours

Prepare this application for production deployment on [Vercel / AWS / Railway].

Pre-deployment checklist:
1. Environment variables: create .env.example with all required vars (no values), verify all are set in [hosting platform]
2. Error tracking: set up [Sentry / LogRocket / Bugsnag] for runtime error monitoring
3. Analytics: add [Vercel Analytics / Google Analytics / Plausible] for usage tracking
4. SEO: verify meta tags, Open Graph, Twitter cards, sitemap.xml, robots.txt
5. Performance: run Lighthouse, fix any scores below 80
6. Security: run npm audit, fix critical/high vulnerabilities, verify security headers
7. Database: verify connection pooling, set up backups if applicable
8. Caching: configure CDN caching headers, implement stale-while-revalidate for API routes
9. Monitoring: set up uptime monitoring (e.g., UptimeRobot, Checkly)
10. Domain: configure custom domain, SSL, www redirect

Create a deployment script or CI/CD pipeline that:
- Runs tests
- Runs linter
- Builds the application
- Deploys to [platform]
- Runs smoke tests against the deployed URL
- Notifies [Slack / Discord / email] on success/failure

Category 8: AI Agent Orchestration Prompts (Expert)

8.1 Multi-Agent Task Decomposition

Tool: Claude Code (subagents) | Time: 2-4 hours

I need to [describe large task, e.g., "add a complete user profile system with settings, avatar upload, activity history, and notification preferences"].

Decompose this into subtasks that can be worked on in parallel:

1. Data layer: schema changes, migrations, API endpoints
2. UI components: form components, display components, layouts
3. Business logic: validation rules, permission checks, notification triggers
4. Tests: unit tests, integration tests, E2E tests

For each subtask:
- Define the interface/contract (inputs, outputs, data shapes)
- List dependencies on other subtasks
- Identify which can run in parallel vs. must be sequential

Then implement each subtask, integrating them at the defined interfaces.
Run the full test suite after integration to catch any contract mismatches.

8.2 Codebase Analysis and Improvement Plan

Tool: Claude Code | Time: 1-2 hours

Analyze this entire codebase and create an improvement plan.

Evaluate:
1. Architecture: Is the structure scalable? Are concerns properly separated?
2. Code quality: Consistency, readability, duplication, complexity (cyclomatic)
3. Error handling: Are errors caught, logged, and presented well?
4. Testing: Coverage, quality of tests, missing edge cases
5. Security: Common vulnerabilities (OWASP Top 10 applicable ones)
6. Performance: Obvious bottlenecks, missing optimizations
7. Developer experience: Build time, hot reload, debugging ease

Output:
- Score each category 1-10 with specific evidence
- Top 5 improvements ranked by impact/effort ratio
- Specific action items for each improvement
- Estimated time for each action item

Don't fix anything yet. Just analyze and plan.

Category 9: Content and Data Prompts

9.1 Seed Data Generator (Beginner)

Tool: Any | Time: 15-30 min

Generate realistic seed data for this application.

Data needed:
- [N] [entity type, e.g., "users"] with: [fields]
- [N] [entity type, e.g., "products"] with: [fields]
- [N] [entity type, e.g., "orders"] with: [fields]

Rules:
- Use realistic names (not "Test User 1")
- Dates spread across the last [time period]
- Prices/amounts in realistic ranges for [industry]
- Status distribution: [e.g., "60% active, 30% pending, 10% cancelled"]
- Include edge cases: [e.g., "one user with no orders, one product with 0 stock"]
- Relationships should be consistent (orders reference real user IDs and product IDs)

Output format: [JSON / SQL INSERT statements / TypeScript constants / CSV]

9.2 API Documentation Generator (Intermediate)

Tool: Claude Code | Time: 30-60 min

Generate comprehensive API documentation for all endpoints in this application.

For each endpoint, document:
- Method and path (e.g., GET /api/users/:id)
- Description (one sentence)
- Authentication required? (yes/no, what type)
- Request: headers, query params, body schema with types and validation rules
- Response: status codes, body schema for success and each error case
- Example request (curl command)
- Example response (JSON)

Format: [Markdown / OpenAPI 3.0 spec / Swagger]
Include a table of contents.
Group endpoints by resource.
Add rate limiting info if applicable.

Category 10: Platform-Specific Prompts

10.1 Chrome Extension (Advanced)

Tool: Claude Code | Time: 2-4 hours

Build a Chrome Extension (Manifest V3) that [core functionality].

Features:
- Popup: [describe popup UI and what it shows]
- Content script: [what it does on web pages, e.g., "highlights [elements]"]
- Background service worker: [what it handles, e.g., "API calls, storage sync"]
- Options page: [settings the user can configure]

Permissions needed: [activeTab, storage, tabs, etc. - minimize permissions]

Storage:
- Use chrome.storage.sync for: [settings that sync across devices]
- Use chrome.storage.local for: [data that stays local]

Communication:
- Content script <-> Background: chrome.runtime.sendMessage
- Popup <-> Background: direct access to chrome.storage

Include:
- manifest.json with all required fields
- Icon set (16x16, 48x48, 128x128) - use simple colored SVG converted to PNG
- README with installation instructions (load unpacked)
- Privacy policy text (required for Chrome Web Store submission)

Test on these sites: [list 3-5 target websites]

10.2 CLI Tool (Intermediate)

Tool: Claude Code | Time: 1-2 hours

Build a command-line tool in [Node.js / Python / Go / Rust] that [core functionality].

Commands:
- [tool] init: [what it sets up]
- [tool] [command 1] [args]: [what it does]
- [tool] [command 2] [args]: [what it does]
- [tool] --help: show all commands with descriptions

Features:
- Colored output (green for success, red for errors, yellow for warnings)
- Progress bars for long operations
- Interactive prompts for required input (with defaults)
- Config file (~/.toolrc or .toolrc in project root)
- --verbose flag for debug output
- --json flag for machine-readable output
- Meaningful exit codes (0 success, 1 error, 2 usage error)

Error handling:
- Clear error messages with suggested fixes
- Never show stack traces (unless --verbose)
- Graceful handling of Ctrl+C

Package for distribution via [npm / pip / brew / cargo].
Include README with installation, usage examples, and config reference.

Prompt Patterns Reference Card

The Constraint Sandwich

Do [action].
Include: [must-have list]
Do NOT include: [exclusion list]
Match existing: [patterns/styles to follow]

The Iterative Refinement

[After seeing initial output]
Keep: [what works]
Change: [what needs to change]
Add: [what's missing]
Remove: [what's unnecessary]
Don't touch: [what shouldn't change]

The Context Dump

Here's the current state:
- File: [path] does [function]
- File: [path] does [function]
- The bug is in: [location]
- Error message: [exact text]
- This worked before I: [recent change]
- I've already tried: [attempts]
Fix the bug without changing [protected areas].

The Scope Lock

ONLY modify [specific files/functions].
Do NOT touch: [protected files]
Do NOT change: [protected behavior]
Do NOT add: [unwanted additions]
Keep the diff as small as possible.

The Quality Gate

Before considering this done:
1. All existing tests pass
2. New tests cover: [specific scenarios]
3. No TypeScript errors (strict mode)
4. No ESLint warnings
5. Lighthouse performance score > [N]
6. [Custom quality criterion]

Category 11: MCP & Agent Team Prompts (New — March 2026)

11.1 MCP Server Discovery Prompt (Intermediate)

Tool: Claude Code | Time: 5-10 min

Search for MCP servers that can help with [task domain — e.g., "database management", "file processing", "API integration"].

For each relevant server:
1. What it does and what tools it exposes
2. How to install/configure it
3. Example tool calls I can make through it
4. Any security considerations (auth tokens, permissions)

Then add the best match to my Claude Code MCP config and verify it works with a test call.

11.2 Agent Team Task Decomposition (Advanced)

Tool: Claude Code Agent Teams | Time: 15-30 min

I need to [describe complex task — e.g., "add OAuth login with Google and GitHub, including database schema, API routes, and frontend components"].

Break this into parallel agent tasks:
1. Identify which subtasks can run simultaneously
2. Identify dependencies between subtasks
3. For each subtask, specify: scope, files to touch, acceptance criteria
4. Assign each to the right agent type (Explore for research, general-purpose for implementation)
5. Define the merge strategy for combining results

Execute with agent teams. Each agent should work in isolation and produce a clear deliverable.

11.3 MCP-Powered Research Pipeline (Advanced)

Tool: Claude Code + MCP | Time: 10-20 min

Using available MCP tools, research [topic] and produce a structured report:

1. Use web search MCP to find the latest data on [topic]
2. Use file system MCP to check if we have existing content on this topic
3. Cross-reference findings with our codebase for relevance
4. Produce a markdown report with:
   - Key findings (with source URLs)
   - Relevance to our project
   - Recommended actions
   - Code changes needed (if any)

Save the report to [output path].

Category 12: Agentic Engineering Prompts (New — March 2026)

Andrej Karpathy coined "agentic engineering" in early 2026 to describe the discipline of designing, orchestrating, and supervising AI agents that autonomously write, test, and deploy code. These prompts operationalize that workflow.

12.1 Supervised Agent Loop (Advanced)

Tool: Claude Code, Codex CLI | Time: 30-60 min per iteration

You are operating as a supervised autonomous agent. Follow this loop:

1. READ: Analyze the current state of [codebase/feature/module] — files, tests, dependencies, open issues
2. PLAN: Propose a concrete plan with numbered steps. Each step must specify: what changes, which files, expected outcome
3. WAIT: Present the plan and STOP. Do not implement until I approve or modify

After I approve:
4. IMPLEMENT: Execute each step, committing after each logical unit
5. VERIFY: Run the test suite, linter, and type checker. Report results
6. REPORT: Summarize what changed, what passed, what failed, and what you recommend next

Rules:
- Never skip the WAIT step. Human approval is required before implementation
- If any test fails after implementation, diagnose and fix before proceeding
- If a step requires a decision between multiple approaches, present options with trade-offs
- Keep commits small and reversible
- Log every file you read or modify

Current task: [describe what needs to be done]
Acceptance criteria: [list specific, testable criteria]

12.2 Agent-Driven CI/CD Pipeline (Expert)

Tool: Claude Code + GitHub Actions | Time: 1-2 hours setup, then autonomous

Set up an agentic CI/CD workflow where AI agents handle the full lifecycle of a code change:

Phase 1 — Agent writes code:
- Agent receives a task description from [Linear / GitHub Issue / Slack]
- Agent creates a feature branch, implements the change, writes tests
- Agent opens a draft PR with a structured description

Phase 2 — Agent reviews code:
- A second agent (or agent team) reviews the PR for:
  - Security vulnerabilities (OWASP Top 10)
  - Performance regressions
  - Test coverage gaps
  - Style and convention compliance
- Review comments are posted on the PR

Phase 3 — Human gate:
- PR is marked ready for review only after agent review passes
- Human reviewer sees both the code and the agent's review analysis
- Human approves, requests changes, or rejects

Phase 4 — Agent deploys:
- On merge, agent monitors the deployment pipeline
- If deployment fails, agent diagnoses the failure and either auto-fixes or escalates
- Agent posts deployment confirmation with health check results

Implement this for:
- Repository: [repo URL or path]
- CI platform: [GitHub Actions / GitLab CI / CircleCI]
- Deploy target: [Vercel / AWS / Railway]
- Notification channel: [Slack / Discord webhook URL]

Include rollback triggers: if error rate exceeds [N]% within [M] minutes post-deploy, auto-revert.

12.3 Multi-Agent Code Review (Advanced)

Tool: Claude Code Agent Teams | Time: 15-30 min

Perform a multi-perspective code review of [PR number / branch / file set] using specialized agent roles:

Agent 1 — Security Auditor:
- Check for injection vulnerabilities, auth bypass, data exposure
- Verify input validation and output encoding
- Flag hardcoded secrets or overly permissive CORS
- Reference OWASP Top 10 and CWE IDs for any findings

Agent 2 — Performance Engineer:
- Identify N+1 queries, missing indexes, unoptimized loops
- Check for memory leaks, unnecessary re-renders, large bundle imports
- Estimate impact: "This will add ~Nms to response time because..."

Agent 3 — Architecture Reviewer:
- Evaluate against existing patterns in the codebase
- Flag violations of established conventions
- Identify coupling, missing abstractions, or wrong layer placement
- Check if the change scales for [expected load / data volume]

Synthesis:
- Combine all three reviews into a single summary
- Categorize findings: Must Fix (blocks merge) / Should Fix (before next release) / Consider (future improvement)
- For each Must Fix, provide a specific code suggestion

Output the review as a structured markdown report I can paste into the PR.

Category 13: MCP & Tool Integration Prompts

New category added March 2026 as MCP becomes standard infrastructure for AI-native development.

13.1 MCP Server Bootstrap (Intermediate)

Tool: Claude Code | Time: 30-60 min

Create a production-ready MCP server in TypeScript that exposes [service name] to AI tools.

Service to wrap: [e.g., "our internal Postgres database", "Stripe API", "Linear project management"]

Resources to expose:
- [Resource 1]: [description and schema — e.g., "list of open tasks with id, title, status, assignee"]
- [Resource 2]: [description and schema]

Tools to implement:
- [Tool 1]: [action — e.g., "create_task(title, description, assignee)"]
- [Tool 2]: [action — e.g., "update_status(task_id, new_status)"]

Requirements:
- TypeScript strict mode
- Input validation with Zod schemas
- Error messages that are AI-readable (not just HTTP codes)
- Rate limiting: max [N] calls per minute
- Logging of all tool invocations with timestamp and caller info
- Auth via environment variable API key
- README with setup instructions and example Claude Code config block

Security requirements:
- Read-only by default; tools that write require explicit "write_mode: true" config flag
- Reject any resource URI that attempts path traversal or contains shell metacharacters
- Log and reject requests exceeding [N] tokens in a single call

Output: Complete server/index.ts, package.json, README.md, and .env.example

13.2 MCP Workflow Chaining (Advanced)

Tool: Claude Code | Time: 1-2 hours

Design and implement a multi-step workflow using MCP tool chaining for: [workflow description]

Example workflow: "When a new GitHub issue is labeled 'bug', automatically:
1. Read the issue and linked code file
2. Write a failing test that reproduces the bug
3. Attempt a fix
4. Create a PR with the fix and test linked to the original issue"

My MCP servers available:
- GitHub MCP (@modelcontextprotocol/server-github)
- Filesystem MCP (@modelcontextprotocol/server-filesystem)
- [any others]

Workflow to implement: [describe your workflow in plain English]

Requirements:
- Each step should verify its output before proceeding to the next step
- If any step fails, log the failure state and stop (don't proceed with partial data)
- Human-in-the-loop checkpoint after [step N]: show summary and ask for confirmation before proceeding
- Final output: summary of all actions taken with links to created artifacts

Implement as a Claude Code workflow with a CLAUDE.md that documents how to trigger it.

13.3 MCP Security Audit (Expert)

Tool: Claude Code | Time: 15-30 min

Audit the MCP configuration in this project for security risks.

Check the following:
1. Permissions scope — are any MCP servers granted broader access than their use case requires?
   - filesystem: should only need the project directory, not ~/
   - github: should be read-only unless explicitly creating PRs
   - database: should use a read-only connection string for query-only workflows

2. Secret handling — are API keys and tokens:
   - Stored in environment variables (not hardcoded in settings.json)?
   - Excluded from version control (.gitignore includes .env and settings.json)?
   - Rotated recently (< 90 days)?

3. Tool invocation logging — is there an audit trail for:
   - Which tools were called?
   - What arguments were passed?
   - What was returned?

4. Community server provenance — for each non-official MCP server installed:
   - Is it from a verified publisher?
   - When was it last updated?
   - Does the package.json match the advertised functionality (no unexpected network calls)?

5. Blast radius — if an MCP server is compromised, what's the worst case?
   - Can it read files outside the project?
   - Can it make outbound network calls?
   - Can it modify production data?

Output: Security report with PASS/FAIL/WARN for each check, plus specific remediation steps for any failures.

Category 14: AI Code Review & Quality Assurance Prompts

Added March 14, 2026 — Responding to Anthropic's Code Review launch and the growing need for systematic AI-generated code quality gates.

14.1 Claude Code Review Gate (Intermediate)

Tool: Claude Code | Time: 5-10 min per PR

Review the changes in this git diff for logic errors, security issues, and integration risks.

Focus areas:
1. Logic correctness: Does the code do what the PR description claims? Walk through the happy path and 2-3 edge cases.
2. Security: Check for injection vulnerabilities, auth bypasses, and data exposure. Reference OWASP Top 10.
3. Integration assumptions: Does this code make assumptions about external services, database schemas, or API contracts that aren't validated?
4. Error handling gaps: What happens when network calls fail, database is unavailable, or inputs are malformed?
5. Performance: Will this code degrade under load? Flag any N+1 queries, synchronous file I/O, or unbounded loops.

For each issue found:
- Severity: CRITICAL / HIGH / MEDIUM / LOW
- Location: file:line
- Problem: what's wrong
- Fix: concrete code suggestion or approach

Conclude with: APPROVE / REQUEST_CHANGES / BLOCK with a one-sentence rationale.

14.2 Context Hub API Accuracy Check (Intermediate)

Tool: Claude Code with Context Hub MCP | Time: 10-20 min

I'm using [library/API name] version [X.Y.Z] in this codebase.

Using Context Hub to pull the current API docs, verify:
1. All method signatures in [file.ts / module name] match the current API spec
2. Deprecated methods that have replacement alternatives
3. Breaking changes in the last 3 minor versions that affect our usage
4. Any authentication or rate-limiting changes we should be aware of

For each discrepancy:
- File and line where we use the outdated API
- Current correct signature
- Migration path (with code example)

Output a migration checklist sorted by priority.

14.3 Multi-Agent Parallel Quality Review (Expert)

Tool: Claude Code with agent teams | Time: 20-40 min

Spin up a quality review using agent teams for this pull request.

Agent roles to create:
1. Security Agent: Focus exclusively on vulnerabilities, auth, input validation, secrets
2. Logic Agent: Focus on correctness, edge cases, business rule compliance
3. Performance Agent: Focus on database queries, caching opportunities, bundle size impact
4. Test Coverage Agent: Check which new code paths lack test coverage; write tests for critical gaps

Each agent should:
- Work independently on its area
- Output findings in the format: [SEVERITY] [FILE:LINE] [DESCRIPTION] [SUGGESTED FIX]
- Flag items that need human judgment before proceeding

After all agents complete, synthesize findings into a unified PR review comment, deduplicating overlapping findings and ordering by priority.

Final output: A ready-to-paste GitHub PR comment with all findings.

Category 15: Supply Chain Security Prompts (New — March 2026)

Added in response to the PHANTOMRAVEN npm campaign (March 2026) — 88 packages using Remote Dynamic Dependencies to bypass registry scanners. These prompts help you audit and harden your dependency chain when using AI coding tools.

15.1 npm Dependency Security Audit Prompt (Intermediate)

Tool: Claude Code, Cursor Composer | Time: 15-30 min

Audit all dependencies in this project's package.json for supply chain security risks.

For each dependency:
1. Check if the package name could be a typosquat of a popular package (e.g., "util-logger-enhanced" vs "util-logger")
2. Identify any postinstall/preinstall/install scripts — list them explicitly
3. Flag any scripts that contain URL fetching (https://, fetch, axios, request, got)
4. Check for packages with very low download counts (<1000/week) that are in production dependencies

For flagged packages:
- Package name
- Risk type: TYPOSQUAT / REMOTE_DYNAMIC_DEPENDENCY / LOW_REPUTATION / SUSPICIOUS_SCRIPT
- The specific script or pattern that triggered the flag
- Recommended action: REMOVE / REPLACE_WITH / INVESTIGATE

Then check our .npmrc or npm config:
- Is ignore-scripts set? (Recommended for CI)
- Is package-lock.json committed and up to date?
- Are we using npm ci in CI pipelines instead of npm install?

Output: A prioritized security remediation list for our dependency chain.

15.2 AI-Generated Package Validation Prompt (Advanced)

Tool: Claude Code | Time: 10-20 min

I'm about to install the following packages that were suggested by an AI coding agent:
[paste package list or package.json]

Before I run npm install, perform a supply chain security pre-check:

1. For each package:
   - Is this a real, well-known package? (Check name against known-good packages)
   - Does the name match any typosquat patterns? (Common patterns: adding -enhanced, -helper, -core, -utils, -wrapper)
   - Is there a more official/canonical package that does the same thing?

2. For the overall dependency set:
   - Any packages that are redundant (installing two packages that do the same thing)?
   - Any packages that AI tools commonly hallucinate (packages that sound plausible but don't exist or are malicious)?
   - Are all packages available on the official npm registry at npmjs.com?

3. Generate the safe install command:
   - If any package is suspicious: exclude it and explain why
   - Include --ignore-scripts if any package has postinstall scripts
   - Suggest npm ci if a lockfile exists

Output: SAFE TO INSTALL / REVIEW REQUIRED / DO NOT INSTALL with specific reasoning for each package flagged.

15.3 Postinstall Script Inspector Prompt (Expert)

Tool: Claude Code with file system access | Time: 20-40 min

Scan all packages in our node_modules directory for Remote Dynamic Dependency (RDD) patterns.

This is a supply chain security audit targeting the PHANTOMRAVEN attack class (March 2026), where malicious packages appear clean to static scanners but fetch payloads from external URLs during install or runtime.

For each package in node_modules/:
1. Read package.json and extract: scripts.postinstall, scripts.preinstall, scripts.install
2. If any script exists: read the script file it references
3. Flag the package if the script contains ANY of:
   - URL fetching: https://, http://, fetch(), require('https'), require('http')
   - Command execution with dynamic content: execSync, exec, spawn, child_process
   - File writes to system locations: /etc/, /usr/, ~/.ssh/, ~/.bashrc
   - Environment variable exfiltration: process.env being sent to external URL
   - Base64 decoding followed by eval/exec (obfuscation pattern)

For each flagged package:
- Package name and version
- Script type (postinstall/preinstall/install)
- Exact suspicious line(s)
- Risk classification: CRITICAL (remote fetch + exec) / HIGH (exec with env vars) / MEDIUM (network access only) / LOW (local file operations)
- Recommended action

Output: JSON report of all findings, sorted by severity. Safe packages can be omitted.

Category 16: Cursor Automations Prompts

Added March 16, 2026 — event-driven automation workflows using Cursor 2.6+ Automations.

16.1 PR Security Review Automation (Intermediate)

Tool: Cursor Automations 2.6+ | Trigger: GitHub PR Opened | Time: 2-3 min per PR

Review this pull request for security vulnerabilities and code quality issues.

## Security Checks
1. SQL injection risks — any database queries with user-controlled input concatenated as strings
2. Missing input validation — API endpoints that accept user data without sanitizing/validating
3. Hardcoded credentials or secrets — passwords, API keys, tokens in code or config files
4. Missing authentication checks — routes or functions that should require auth but don't
5. XSS vulnerabilities — user input rendered in HTML without escaping
6. Overly permissive CORS — origins: '*' or missing Content-Security-Policy headers

## Quality Checks
1. TypeScript strict mode violations — any 'any' types, missing return types, unsafe casts
2. Missing error handling — async operations without try/catch, promises without .catch()
3. Obvious logic errors — off-by-one errors, wrong comparison operators, inverted conditions

## Output Format
For each issue found:
- **Severity**: CRITICAL / HIGH / MEDIUM / LOW
- **File**: [filepath:line]
- **Issue**: [one sentence description]
- **Fix**: [corrected code snippet if < 10 lines]

If no issues found, post exactly: "✅ Security review passed — no issues found."

16.2 Automated Changelog Entry Generator (Beginner)

Tool: Cursor Automations 2.6+ | Trigger: GitHub PR Merged | Time: 1-2 min per merge

A pull request was just merged. Generate a changelog entry for it.

PR Title: [PR title]
Author: [PR author]
Files changed: [list of changed files]
PR description: [PR body]

Determine the entry type:
- feat: New feature or capability added
- fix: Bug fix or error correction
- perf: Performance improvement
- security: Security patch or hardening
- refactor: Code restructuring without behavior change
- docs: Documentation updates only

Generate: `[type]: [concise description] ([PR number])`

Rules:
- Under 100 characters
- Present tense ("add", "fix", "update")
- Focus on user-facing change, not implementation detail
- If PR touches multiple areas, generate separate entries

Output ONLY the changelog line(s), nothing else.

16.3 Incident First Responder Automation (Advanced)

Tool: Cursor Automations 2.6+ | Trigger: PagerDuty P1/P2 Alert | Time: 3-5 min per incident

A production incident was just triggered. Perform automated initial diagnosis before the on-call engineer responds.

Alert name: [alert title]
Alert description: [alert body]
Triggered at: [timestamp]

Diagnosis Steps:
1. Review all commits in the past 24 hours — note files changed and summaries
2. Identify which files/functions match keywords in the alert
3. Analyze error handling patterns in those functions for known failure modes

Output Format:
**🚨 Automated Incident Analysis**

**Top 3 Most Likely Causes:**
1. [Cause] — [file:function] — [why likely]
2. [Cause] — [file:function] — [why likely]
3. [Cause] — [file:function] — [why likely]

**Recent Changes That May Be Related:**
- [commit hash] — [description] — [changed files]

**Immediate Debugging Suggestions:**
- Check [specific endpoint/function] for [specific condition]

*Automated code analysis only — verify against live logs.*

This library is updated monthly with new prompts based on emerging tools, patterns, and reader requests. Last updated: March 16, 2026.

18. Tool Comparison Matrix

A living comparison of every major vibe coding tool. Updated monthly.

AI-Native IDEs

Autonomous Agents

Browser Builders (No-Code)

Choosing Your Stack

</div>

19. The Security Playbook

A practical guide to hardening vibe-coded applications before they touch real users.

</div>

</div>

</div>

</div>

</div>

</div>

</div>

Review this codebase for OWASP Top 10 vulnerabilities.
For each issue found: severity (Critical/High/Medium/Low),
file and line number, what's wrong, the fix, and how to test it.
Prioritize by severity.

</div>

Chapter 20: Video Tutorials -- Embedded Remotion-Generated Walkthroughs

Bite-sized, binge-worthy video tutorials that show real vibe coding workflows in action. Each video is 60-120 seconds, focused on one specific technique, and embedded directly in the interactive ebook using Remotion components. Updated monthly with 2-4 new videos.

Why Video Tutorials Inside an Ebook

Reading about vibe coding is one thing. Watching a real app materialize from a single prompt in under ninety seconds is something else entirely.

Traditional ebooks give you text and screenshots. This one gives you motion. Every video in this chapter is a self-contained Remotion composition -- a React component that renders to video. That means each tutorial is versioned, reproducible, and embedded natively in the interactive ebook without relying on external hosting. You can watch them inline, pause on any frame, and in the web version, interact with the code snippets directly.

The videos are grouped into three series, each designed for a different purpose:

1. Prompt to Product -- Viral-format demonstrations of complete apps built from single prompts. Optimized for shareability and shock value.
2. The Prompt That... -- Educational deep-dives with a comedic edge. Each video dissects one prompt and its unexpected consequences.
3. Tool Face-Off -- Head-to-head comparisons between competing tools, scored on speed, quality, and developer experience.

Every video follows the same production pipeline: markdown script, Remotion composition with screen recordings and motion graphics, AI-generated narration, and branded end cards. The result is a library that grows over time and works across platforms -- full-length on YouTube, clipped for TikTok/Reels/Shorts, and embedded here in the ebook.

Video Series 1: "Prompt to Product" (Viral Potential)

Each video in this series shows a complete, functional application being built from a single natural-language prompt. A real-time countdown timer runs in the corner. The screen recording is unedited -- what you see is what actually happened. The final reveal shows the deployed app running in a browser.

Series format:

• Duration: 60-90 seconds
• Structure: Hook (3s) -> Prompt reveal (5s) -> Countdown build (40-70s) -> Reveal + deploy (10s) -> End card (5s)
• Visual signature: Neon countdown timer in the top-right corner, split-screen showing prompt on the left and the AI's output on the right
• Audio: Fast-paced electronic background track, AI text-to-speech narration, keystroke and notification sound effects

Video #1: 60-Second SaaS (Bolt.new)

Title/Hook: "I built a $9/month SaaS in 60 seconds"

Tool: Bolt.new

Concept: Starting from a completely blank Bolt.new session, a single prompt generates a fully functional micro-SaaS -- a link shortener with analytics, user accounts, and a Stripe-ready pricing page. The countdown timer hits zero just as the app deploys.

Tone: Breathless, slightly disbelieving. The narration captures the genuine absurdity of how fast this is.

Script Outline (170 words): Open on a blank browser tab. The narrator says: "I'm going to build a SaaS product that charges $9 a month. I have 60 seconds." The countdown starts. Cut to the Bolt.new interface. The prompt appears on screen as it is typed: a link shortener with user authentication, click analytics dashboard, custom short domains, and a pricing page with free and pro tiers. Bolt.new starts generating. The split screen shows the prompt on the left, the live preview assembling on the right -- components appearing in real time, a login form, a dashboard with charts, a pricing table with toggle between monthly and annual. The timer passes 30 seconds. The app is taking shape. At 50 seconds, the deployment starts. At 58 seconds, a live URL appears. The timer hits zero. Cut to the deployed app in a fresh browser: working signup, working dashboard, working pricing page. End card: "Total cost: $0. Total code written by a human: 0 lines."

Visual Concepts for Remotion:

• CountdownTimer component: neon green digits, pulses red below 10 seconds, shakes at 3-2-1
• SplitScreenBuild composition: left panel shows the prompt text animating in typewriter-style, right panel shows a screen recording of Bolt.new's live preview
• DeploymentFlash animation: when the URL goes live, a burst animation radiates from the URL bar
• MetricCard end-card overlay: three floating cards showing "Time: 60s", "Lines of code: 0", "Cost: $0" with staggered fade-in
• Screen recording captured at 60fps, composited at 30fps for smooth playback

Video #2: Portfolio Speedrun (v0 + Vercel)

Title/Hook: "Your portfolio shouldn't take longer than your morning coffee"

Tools: v0 by Vercel, Vercel deployment

Concept: A developer's portfolio website -- hero section, project grid, about page, contact form, dark mode toggle -- goes from blank prompt to live Vercel deployment while a coffee timer ticks down. The coffee metaphor runs throughout: the video opens with pouring coffee, and each section of the site appears as the coffee cools.

Tone: Relaxed and conversational, contrasting with the speed of what is happening on screen. The humor comes from the mismatch between the casual narration and the absurd pace.

Script Outline (180 words): Open on a close-up of coffee being poured. The narrator says: "The average developer spends 3 weeks on their portfolio. I'm going to finish mine before this coffee is cool enough to drink." Cut to v0. The prompt describes a developer portfolio: dark theme, animated hero with a typewriter effect showing "I build things," a responsive project grid pulling from a JSON file, an about section with a timeline, a contact form, and a dark/light mode toggle. v0 generates the first component. The narrator walks through what is appearing while keeping the tone casual -- "Oh, that's a nice grid layout... didn't ask for that hover effect but I'm keeping it." At 40 seconds, the design is complete. The code is exported to a GitHub repo. Vercel picks up the push and begins deploying. The narrator takes a sip of coffee. The Vercel build completes. The live site loads: responsive, polished, with real content. "Still too hot to drink. I should probably build a second portfolio."

Visual Concepts for Remotion:

• CoffeeTimer component: a coffee cup illustration in the corner with a steam animation, a circular progress ring around it representing time
• ComponentAssembly animation: each section of the portfolio slides into a wireframe layout, then fills in with color and content -- like a blueprint becoming a building
• v0Preview screen capture: the v0 interface generating components in real time
• VercelDeploy animation: a minimal deployment progress bar styled in Vercel's black-and-white aesthetic, with the URL appearing at the end
• Smooth crossfade transitions between the coffee close-up and the screen recording

Video #3: The $0 Startup (Lovable)

Title/Hook: "This app makes money. I didn't write a single line."

Tool: Lovable

Concept: A non-technical founder builds a complete SaaS product using only Lovable -- from idea to deployed, revenue-generating application. The video emphasizes that the person building this has no programming background. The "reveal" is not just the app, but a real Stripe dashboard showing the first payment.

Tone: Inspirational but grounded. Not "anyone can do this" hype -- more "here's exactly what the process looks like when you've never coded before."

Script Outline (190 words): Open on a text overlay: "I'm not a developer. I'm a marketing manager." The narrator continues: "Last month, I had an idea for a tool that helps freelancers track their invoices. This morning, I built it." Cut to Lovable. The prompt is detailed and specific -- it describes an invoice tracker with client management, recurring invoice templates, PDF export, and a simple dashboard showing outstanding payments. Lovable begins generating. The narration explains the key decisions: why the prompt specifies Supabase for the backend, why it asks for Row Level Security so each user only sees their own data, why it mentions Stripe Connect for future payment processing. At 45 seconds, the app is running in Lovable's preview. The narrator tests the core workflow: create a client, generate an invoice, export to PDF. Everything works. At 70 seconds, the app deploys. Cut to a real Stripe dashboard showing a $12 test payment. "I didn't write code. I didn't hire a developer. I described what I needed. Total investment: a Lovable subscription and one afternoon of prompt writing."

Visual Concepts for Remotion:

• IdentityCard intro animation: a business-card-style overlay showing "Marketing Manager" with a crossed-out "Developer" beneath it
• PromptAnnotation overlay: as the prompt scrolls, key phrases highlight and small tooltip annotations explain why each detail matters (e.g., "Row Level Security" highlights with a note: "This keeps each user's data private")
• WorkflowDemo screen recording: the invoice creation flow captured step-by-step with zoom-ins on important UI elements
• StripeReveal animation: the Stripe dashboard slides in from the bottom with a cash register sound effect and a subtle confetti particle burst
• Color palette shifts from grayscale (the "before") to full color (the "after") as the app comes to life

Video #4: Clone Wars (Cursor)

Title/Hook: "I showed AI a screenshot of Notion. Here's what happened."

Tool: Cursor (Agent mode with Composer)

Concept: A screenshot of Notion's interface is fed to Cursor's AI, along with a prompt asking it to recreate the core functionality. The video follows the agent as it plans the architecture, generates the components, and builds a working Notion-like workspace -- pages, blocks, drag-and-drop, slash commands -- all from a single image and a paragraph of context.

Tone: Playful and slightly mischievous. The "clone wars" framing leans into the controversy of AI-generated clones while keeping it lighthearted.

Script Outline (185 words): Open on a screenshot of Notion's interface. The narrator says: "This is Notion. 400 engineers built this over 10 years. I'm going to see how close AI can get in 2 minutes." The screenshot is dragged into Cursor's Composer. The prompt is brief but precise: recreate a note-taking workspace with a sidebar, nested pages, rich text blocks, slash command menu for adding headers/lists/toggles, and drag-to-reorder blocks. Cursor's agent starts planning. An overlay shows the agent's thought process -- the file tree it is creating, the components it has decided to build, the libraries it is installing. At 30 seconds, the first components render: a sidebar with a page tree. At 60 seconds, the editor is working: typing, formatting, slash commands. At 90 seconds, drag-and-drop is functional. The narrator does a side-by-side comparison with the original screenshot. Some elements are strikingly close. Others are clearly AI-generated. "Is it Notion? No. Could you use it? Absolutely. Did a human write any of this code? Not a single character."

Visual Concepts for Remotion:

• ScreenshotToCode opening animation: the Notion screenshot dissolves pixel-by-pixel into code characters, which then reassemble into the cloned interface
• AgentThinking overlay: a semi-transparent sidebar showing Cursor's agent plan as it generates -- file names, component tree, dependency list, appearing in real time
• SideBySide comparison frame: original Notion on the left, clone on the right, with a slider the viewer can conceptually drag between them
• FileTicker bottom bar: a scrolling ticker showing file names as they are created ("sidebar.tsx... editor.tsx... slash-commands.tsx..."), styled like a stock ticker
• Cursor's interface captured with visible agent actions highlighted

Video #5: The Debug Olympics (Claude Code)

Title/Hook: "Can AI fix a bug faster than Stack Overflow?"

Tool: Claude Code

Concept: A real, nasty bug -- the kind that would send a developer to Stack Overflow for an hour -- is presented to Claude Code. The screen is split: on the left, a simulated "Stack Overflow search" shows the traditional debugging path (finding related questions, reading answers, trying solutions). On the right, Claude Code analyzes the error, traces the root cause through multiple files, and delivers a working fix. A race timer tracks both sides.

Tone: Competitive and high-energy, like a sports broadcast. The narration calls the race like a commentator.

Script Outline (175 words): Open on a terminal showing a cryptic error: a React hydration mismatch caused by a timezone-dependent date format in a server component. The narrator, in a sports-announcer voice: "In the left corner, the defending champion: Stack Overflow and pure human tenacity. In the right corner, the challenger: Claude Code. The bug: a hydration error that has already cost this developer 45 minutes. Let the race begin." The split screen activates. Left side: a browser opens Stack Overflow, searches the error message, scrolls through three different answers, tries a solution that does not work, goes back. Right side: Claude Code receives the error, opens the relevant files, traces the date formatting issue across server and client components, identifies the mismatch, proposes a fix, and applies it. Claude Code finishes in 23 seconds. The left side is still reading the second Stack Overflow answer. "The AI finished before the human found the right question to ask."

Visual Concepts for Remotion:

• RaceTimer dual countdown: two stopwatches side by side, one for each approach, styled like a sports scoreboard with team colors (orange for Stack Overflow, purple for Claude)
• SplitRace composition: left and right panels with independent screen recordings, separated by a glowing dividing line
• DebugTrace animation: on Claude Code's side, colored lines connect the error message to the relevant files, showing the AI's reasoning path like a detective's evidence board
• VictoryFlash animation: when Claude Code finishes, its panel pulses with a winner overlay while the Stack Overflow panel dims
• BugAnatomy end card: a diagram showing the root cause of the bug, making the video educational as well as entertaining

Video Series 2: "The Prompt That..." (Educational + Humor)

This series takes a single prompt and follows it to its logical (and sometimes illogical) conclusion. Each video is educational at its core -- you learn prompt engineering techniques, tool capabilities, and common pitfalls -- but the framing is comedic. The "The Prompt That..." naming convention is designed for curiosity-driven clicks.

Series format:

• Duration: 90-120 seconds
• Structure: Setup (10s) -> The prompt (10s) -> The process (40-60s) -> The twist/result (20-30s) -> Lesson learned (10s) -> End card (5s)
• Visual signature: The prompt text is always displayed on a "sticky note" style card that stays pinned to the screen throughout the video
• Audio: Conversational narration, comedic timing with beat pauses, sound effects for emphasis

Video #6: The Prompt That Built a Game

Title/Hook: "The Prompt That Built a Game"

Tool: Claude Code + Remotion (for the game rendering)

Concept: A single, carefully crafted prompt generates a complete browser game -- not a trivial one, but a polished arcade game with physics, particle effects, a scoring system, leaderboard, and mobile touch controls. The video walks through the prompt's structure, explaining why each sentence matters, then shows the game coming to life.

Tone: Enthusiastic and educational. The narrator genuinely enjoys playing the result.

Script Outline (190 words): Open on the prompt, displayed as a sticky note. The narrator reads it aloud, pausing to annotate key phrases: "Notice I specified 'physics-based' -- without this, the AI defaults to simple collision rectangles." "I said 'particle effects on collision' -- this forces the AI to implement a particle system, which makes the game feel premium." The prompt is sent to Claude Code. The terminal comes alive with file creation. The narrator explains the AI's architectural decisions as they happen: "It chose HTML Canvas over DOM elements -- good call for performance." "It's implementing a game loop with requestAnimationFrame -- exactly right." At 50 seconds, the game runs for the first time. It has bugs: a sprite clips through a wall. The error is pasted back. At 65 seconds, the game runs cleanly. The narrator plays it for 20 seconds, showing the physics, particles, and scoring in action. "One prompt. One paste of an error message. A game that would have taken a junior developer a week. The lesson: specificity in your prompt is not optional. Every adjective earns its keep."

Visual Concepts for Remotion:

• StickyNote component: a yellow sticky note pinned to the top-left corner showing the prompt text, with annotations appearing as red-marker circles and arrows when the narrator highlights key phrases
• TerminalStream animation: Claude Code's terminal output rendered as a scrolling feed with syntax-highlighted file paths and code snippets
• GameEmbed live composition: the actual game running inside a Remotion frame, capturing real gameplay
• AnnotationBubble overlays: speech-bubble callouts pointing to specific lines in the prompt, explaining why they matter
• BeforeAfter bug-fix transition: a glitch effect when the bug appears, clean dissolve when it is fixed

Video #7: The Prompt That Broke Everything

Title/Hook: "The Prompt That Broke Everything"

Tool: Bolt.new

Concept: A seemingly reasonable prompt -- "refactor the entire codebase to use TypeScript strict mode" -- is applied to a working JavaScript project. The video documents the cascade of failures: type errors multiply exponentially, the AI tries to fix them but introduces new ones, the build breaks, and the project enters what the narrator calls "the error spiral." The video then shows the recovery: how to scope refactoring prompts correctly.

Tone: Darkly comedic, building to genuine relief. The narrator treats the error messages like a horror movie.

Script Outline (185 words): Open on a working application. Green checkmarks everywhere. The narrator says: "This app works perfectly. It has 47 files, zero bugs, and 100% of its tests pass. I am about to destroy it with one sentence." The prompt appears: "Refactor this entire codebase to use TypeScript strict mode with no 'any' types." The AI begins. At first, it looks productive -- .js files become .tsx files. Then the errors start. The error count appears as a rising counter in the corner: 12... 47... 134... 312. The narrator's tone shifts from confident to concerned to horrified. "It's adding type assertions everywhere. Those are band-aids. The types are lying." At 60 seconds, the build fails completely. The recovery begins: the narrator shows how to scope the same refactoring into small, file-by-file prompts with test verification between each step. The error count drops. The builds pass. "The lesson: AI can refactor anything. But 'anything' and 'everything at once' are different requests."

Visual Concepts for Remotion:

• ErrorCounter component: a large, prominent counter in the top-right that ticks up with each new TypeScript error, turning from green to yellow to orange to red as the count increases, with screen-shake at milestones (100, 200, 300)
• CascadeVisualization animation: errors displayed as falling dominoes or multiplying cells, visually representing the chain reaction
• HealthBar component: a video-game-style health bar for the project, draining as errors accumulate, flashing red at critical levels
• RecoveryTimeline animation: a horizontal timeline showing the correct approach -- small, scoped prompts with green checkmarks between each step
• Split-screen during recovery: the broken approach on top (red-tinted), the correct approach on the bottom (green-tinted)

Video #8: The Prompt That Got Me Fired (Hypothetically)

Title/Hook: "The Prompt That Got Me Fired (Hypothetically)"

Tool: Claude Code

Concept: A developer accidentally uses a vibe coding workflow on a production codebase -- accepting all changes without review, pushing without tests, deploying on a Friday afternoon. The video is a dramatized worst-case scenario that teaches real lessons about when NOT to vibe code. Every mistake is a real mistake that real developers have made.

Tone: Mock-serious, documentary style. Presented like a true-crime investigation of a deployment gone wrong.

Script Outline (180 words): Open on a dramatic title card: "INCIDENT REPORT: February 14, 2026." The narrator, in a deadpan documentary voice: "The following is a reconstruction of actual events. Names have been changed. The code has not." The prompt is revealed: a developer asked the AI to "update the user billing logic to handle the new pricing tiers" on the production branch. Without reading the diff. Without running tests. On a Friday at 4:47 PM. The AI changed the billing calculation -- and introduced a rounding error that charged every customer $0.01 extra per transaction. The video shows the cascade: the deploy, the first customer complaint, the Slack messages, the rollback attempt that failed because there was no checkpoint. "By Monday morning, 47,000 transactions were affected." The recovery section shows what should have happened: feature branch, test suite, staging deployment, code review. "Vibe coding is a superpower. And like every superpower, using it in the wrong context has consequences."

Visual Concepts for Remotion:

• IncidentReport styling: the entire video uses a corporate incident report aesthetic -- monospace fonts, timestamps, severity indicators, redacted sections
• SlackMessages animation: recreated Slack-style message bubbles appearing with increasing urgency ("@channel anyone else seeing billing discrepancies?", "this is not a drill")
• TimelineOfFailure component: a horizontal timeline with red flags marking each mistake (no branch, no tests, no review, Friday deploy)
• RollbackFail animation: a dramatic "FAILED" overlay with klaxon-style visual pulse when the rollback does not work
• ChecklistReveal end animation: the correct process appearing as a green checklist, each item checking off with a satisfying animation

Video #9: The Prompt That Replaced My Intern

Title/Hook: "The Prompt That Replaced My Intern"

Tool: Cursor + Claude Code

Concept: A tech lead has a list of 23 tedious but necessary tasks that would normally be assigned to a junior developer or intern: rename variables to follow conventions, add JSDoc comments to exported functions, update deprecated API calls, create missing test stubs, fix all ESLint warnings. One prompt handles all of them. The video compares the estimated "intern hours" with the actual AI minutes.

Tone: Sympathetic and slightly guilty. The narrator acknowledges the awkwardness of the topic while being honest about the productivity gains.

Script Outline (175 words): Open on a task list -- 23 items, each with an estimated time: "Rename callbacks to follow naming convention (2 hours)," "Add JSDoc to all exported functions (4 hours)," "Update deprecated moment.js calls to dayjs (3 hours)." Total estimate: 34 hours of intern work. The narrator says: "I used to give this list to our summer intern. It would take them a full work week. This morning I gave it to the AI." A single, structured prompt appears, listing all 23 tasks with clear specifications. Claude Code begins. A progress bar tracks completed tasks. The terminal output shows files being modified, tests passing. At 45 seconds, 23 of 23 tasks are done. The narrator reviews the changes: "The variable renames are consistent. The JSDoc comments are accurate. The moment-to-dayjs migration handles edge cases I didn't think of." Total time: 8 minutes. "The intern now works on architecture decisions and feature design. The AI handles the checklist."

Visual Concepts for Remotion:

• TaskBoard component: a kanban-style board with 23 cards, each sliding from "To Do" to "In Progress" to "Done" as the AI completes them
• TimeComparison split bar: a bar chart comparing "Intern: 34 hours" vs "AI: 8 minutes," with the AI bar barely visible next to the intern bar
• ProgressTracker overlay: "3/23 complete... 11/23... 19/23..." with each milestone triggering a small celebration animation
• DiffPreview popups: brief glimpses of the actual code changes (before/after) for two or three of the most interesting tasks
• Warm color palette (no cold, "replacing humans" vibe) -- the end card explicitly shows the intern now working on more interesting problems

Video #10: The Prompt That Even My Mom Could Use

Title/Hook: "The Prompt That Even My Mom Could Use"

Tool: Lovable

Concept: The narrator's actual non-technical parent uses Lovable to build a small app -- a recipe organizer -- from scratch, using only natural language. The video is screen-recorded over the parent's shoulder (with permission). The charm is in the completely non-technical prompt language: "I want a thing where I can put my recipes and find them later, like a cookbook but on the computer."

Tone: Warm, genuine, and slightly humorous. The non-technical language in the prompts is endearing, not mocking.

Script Outline (185 words): Open on a text overlay: "I gave my mom a Lovable account and one instruction: build whatever you want." Cut to the screen. The prompt is typed in plain, non-technical English: "I want to save my recipes. Each recipe should have a name, the ingredients, the steps, and a photo. I want to search by ingredient so when I have chicken I can find all my chicken recipes. Make it pretty with a warm color like my kitchen." Lovable generates the app. The narrator points out that "make it pretty with a warm color like my kitchen" resulted in a terracotta-and-cream color scheme that actually looks good. The recipe form works. The search works. Photo upload works. The narrator's parent adds a real recipe -- handwritten notes visible on the desk for reference. The app works exactly as described. "She didn't say 'database.' She didn't say 'component.' She didn't say 'responsive.' She said 'like a cookbook but on the computer.' And that was enough."

Visual Concepts for Remotion:

• HandwrittenOverlay styling: the prompt text appears in a handwriting-style font rather than monospace, reinforcing the non-technical nature
• KitchenWarmth color grading: the entire video has a warm, slightly golden color grade -- cozy and approachable
• RecipeCard animation: when the generated app shows a recipe, it animates like flipping a page in a physical cookbook
• SearchDemo screen recording: the ingredient search in action, with a zoom-in on the results filtering in real time
• QuoteCard end overlay: "She said 'like a cookbook but on the computer.' And that was enough." in large, warm-toned typography

Video #11: The Prompt That Fooled the Senior Dev

Title/Hook: "The Prompt That Fooled the Senior Dev"

Tool: Claude Code

Concept: A blind code review experiment. A senior developer is shown two pull requests: one written by a mid-level human developer, one generated entirely by AI from a single prompt. The senior reviews both, provides feedback, and guesses which is which. The reveal shows whether they guessed correctly -- and what the AI code got right that the human code got wrong (and vice versa).

Tone: Fair and balanced. This is not an "AI is better" video -- it is an honest comparison that reveals strengths and weaknesses on both sides.

Script Outline (195 words): Open on two code editors, labeled "Developer A" and "Developer B." The narrator explains: "A senior engineer with 12 years of experience is going to review two implementations of the same feature -- a real-time notification system. One was written by a mid-level developer in 6 hours. The other was generated by Claude Code from a single prompt in 4 minutes. The reviewer doesn't know which is which." Cut to the review. The senior developer's comments appear as overlays: "Developer A has clean separation of concerns... but this error handling is naive." "Developer B's type safety is impressive... but this abstraction feels over-engineered." The senior guesses: "A is the human, B is the AI. The human code feels more intentional. The AI code is technically thorough but lacks personality." The reveal: they got it backwards. Developer A was the AI. Developer B was the human. The narrator unpacks the implications: the AI's code was structurally cleaner, but the human's code had more creative architectural choices. "Neither was strictly better. They were differently excellent."

Visual Concepts for Remotion:

• BlindReview split screen: two code panels with neutral labels ("Developer A" / "Developer B"), no visual hints about origin
• ReviewComment overlays: the senior developer's comments appear as GitHub-PR-style review annotations, sliding in from the right margin
• GuessReveal animation: the labels flip over like cards, revealing "AI" and "Human" with a dramatic pause and sound effect
• ComparisonMatrix end card: a radar chart comparing both implementations across axes (readability, type safety, error handling, architecture, creativity, performance)
• Neutral color scheme throughout -- neither side gets a "winner" color until the analysis section

Video Series 3: "Tool Face-Off" (Comparison)

This series puts competing tools head-to-head on identical tasks. Same prompt, same requirements, same hardware. The evaluation is structured and scored across consistent categories: speed, code quality, developer experience, and output completeness. These are the videos developers watch before choosing their next tool.

Series format:

• Duration: 90-120 seconds
• Structure: Rules (10s) -> Tool A attempt (30-40s) -> Tool B attempt (30-40s) -> Scoring (15s) -> Verdict (10s) -> End card (5s)
• Visual signature: Boxing-match / tournament-bracket aesthetic with tool logos in corners, round numbers, and scorecard overlays
• Audio: Sports-style narration, bell sounds between rounds, dramatic pause before verdict

Video #12: Round 1 -- IDE Showdown (Cursor vs Claude Code vs Codex CLI)

Title/Hook: "Round 1: IDE Showdown -- Cursor vs Claude Code vs Codex CLI"

Tools: Cursor (Agent mode), Claude Code, OpenAI Codex CLI

Concept: All three tools receive the same prompt: build a task management API with authentication, CRUD operations, and automated tests. The video captures all three attempts simultaneously using a triple split-screen. Each tool is scored on time to completion, test pass rate, code quality (measured by a linting score), and developer experience (subjective rating of the interaction).

Tone: Fair, analytical, and energetic. This is a sports broadcast, not a product review. Every tool gets genuine praise for its strengths.

Script Outline (200 words): Open on a tournament bracket graphic. The narrator, in an announcer voice: "Three tools. One prompt. One winner. This is the IDE Showdown." The prompt appears: a task management REST API with JWT authentication, full CRUD, input validation, pagination, and a test suite. The rules: no human intervention after the prompt is submitted, tools are scored on four categories, each worth 25 points. "Round 1: Speed." The triple split-screen activates. Cursor's agent starts planning, showing its step-by-step approach. Claude Code opens multiple files simultaneously, working fast. Codex CLI takes a methodical, file-by-file approach. Time stamps appear as each tool finishes. "Round 2: Tests." Each tool's test suite runs. Pass rates appear on the scoreboard. "Round 3: Code Quality." ESLint scores flash on screen. "Round 4: Developer Experience." The narrator rates the interaction quality: how clear was the agent's communication, how easy was it to follow along, how much manual intervention was needed. The scorecard fills in. The verdict is revealed. "All three built a working API. The differences are in the details."

Visual Concepts for Remotion:

• TournamentBracket intro animation: a bracket graphic with tool logos, styled like a boxing event poster
• TripleSplit composition: three equal panels running simultaneous screen recordings, each with a tool logo badge and running timer in the corner
• Scoreboard component: a four-category scoring grid that fills in during the verdict section, each score animating from 0 to its final value
• RoundBell transition: a boxing bell sound and "ROUND 2" text between each scoring category
• VerdictCard final overlay: total scores, category winner badges, and a nuanced text verdict ("Best for speed: X. Best for quality: Y. Best for beginners: Z.")

Video #13: Round 2 -- Builder Battle (Bolt.new vs Lovable vs Replit Agent)

Title/Hook: "Round 2: Builder Battle -- Bolt.new vs Lovable vs Replit Agent"

Tools: Bolt.new, Lovable, Replit Agent

Concept: The browser-based builders compete on a task suited to their strengths: build a complete landing page with a waitlist form, social proof section, feature comparison, and email capture that stores submissions to a real database. Scoring covers design quality, functionality, mobile responsiveness, and deployment speed.

Tone: Enthusiastic and visual. Since these are design-heavy tools, the video emphasizes how each app looks and feels rather than focusing purely on code.

Script Outline (190 words): Open on the challenge card: "Build a startup landing page with working waitlist signup. You have 3 minutes." Each builder gets the same prompt: a landing page for a fictional AI writing tool called "DraftPilot," with a hero section, three feature cards, a testimonial carousel, a pricing comparison, and a waitlist form that saves emails to Supabase. The triple split-screen shows all three tools working simultaneously. The narrator calls attention to interesting differences in real time: "Bolt.new went straight for the hero section -- it's already looking polished." "Lovable is building the database connection first -- solid fundamentals." "Replit Agent just asked a clarifying question about the color scheme -- that's a nice touch." At 90 seconds, the designs are compared side-by-side: mobile views, desktop views, scroll behavior, form functionality. Each tool's waitlist form is tested with a real email submission. The scoring covers design (how good does it look), function (does the form actually save data), responsiveness (mobile rendering), and speed (time to deployable state). "Each builder has a personality. The question is which personality matches yours."

Visual Concepts for Remotion:

• BuilderCard intro: each tool's logo on a playing-card-style design, dealt onto the screen like a card game
• DesignComparison frame: all three landing pages shown as browser mockups on a desk, with the ability to zoom into each one
• MobilePreview animation: each landing page shrinks into a phone-shaped frame to show mobile rendering, side by side
• FormTest overlay: a live-action hand typing a test email into each form, with a green checkmark when the submission succeeds
• PersonalityCard end graphic: each tool gets a one-line personality description ("Bolt.new: The Speed Demon," "Lovable: The Perfectionist," "Replit Agent: The Conversationalist")

Video #14: Round 3 -- Agent Arena (Devin vs Jules vs Claude Code)

Title/Hook: "Round 3: Agent Arena -- Devin vs Jules vs Claude Code"

Tools: Devin, Google Jules, Claude Code

Concept: The autonomous agents tackle a more complex task: given an existing open-source project with 15 open issues, each agent is assigned 5 issues and must work independently to create pull requests. Scoring covers issue resolution rate, PR quality, test coverage of the fix, and how well the agent communicated its approach.

Tone: Analytical with a sense of drama. These are the most powerful tools in the landscape, and the comparison is genuinely informative for teams making purchasing decisions.

Script Outline (200 words): Open on a GitHub issues page showing 15 open issues. The narrator: "Welcome to the Agent Arena. Three autonomous AI agents. Five GitHub issues each. No human help. Who writes the best pull requests?" The issues range from a CSS bug to a database query optimization to a feature request for dark mode. Each agent receives its 5 issues and a cloned copy of the repo. The video shows a triple timeline: Devin working in its cloud VM, Jules working asynchronously through Google Cloud, Claude Code working in the terminal. Key moments are highlighted: "Devin just opened a PR for the CSS bug -- let's see the diff." "Jules is running the test suite before committing -- smart." "Claude Code found a related bug while fixing issue #7 and filed a new issue for it -- above and beyond." After all agents submit their PRs, a senior developer reviews them. Scoring: issues resolved (did the PR actually fix it), code quality (clean diff, no regressions), test coverage (did the agent add tests), and communication (how clear was the PR description and commit message). "At this level, the differences are subtle. But subtle differences matter at scale."

Visual Concepts for Remotion:

• GitHubBoard composition: a project board with issue cards, each card moving to the agent's column as they are assigned
• AgentTimeline triple track: three horizontal timelines showing each agent's progress -- commits appear as dots, PRs as flags, with timestamps
• PRReview overlay: a GitHub-style PR diff view showing the agent's changes, with the senior developer's review comments fading in
• ScoreRadar chart: a radar/spider chart for each agent across the four scoring dimensions
• ArenaStadium framing: the entire video is styled like an arena event, with spotlights, agent "entrances," and a final podium reveal

Video #15: Round 4 -- Speed vs Quality (Bolt vs Claude Code)

Title/Hook: "Round 4: Speed vs Quality -- Bolt.new vs Claude Code"

Tools: Bolt.new, Claude Code

Concept: This is the philosophical face-off: the fastest browser builder against the most thorough terminal agent. The same prompt -- a complete habit-tracking app with streaks, charts, and reminders -- goes to both tools. Bolt.new finishes in minutes. Claude Code takes longer but produces more robust code. The question is not "which is better" but "which is better for what."

Tone: Thoughtful and balanced. This video acknowledges that "better" depends entirely on context.

Script Outline (195 words): Open on a scale graphic: "Speed" on one side, "Quality" on the other. The narrator: "Every developer makes this trade-off. Today we make it explicit." The prompt: a habit tracker with daily check-ins, streak counting with freeze days, progress charts using a real charting library, push notification reminders, and data export. Bolt.new starts. The app assembles rapidly in the browser -- UI components appear, the habit list renders, the chart populates. Time: 3 minutes and 12 seconds. It looks good. It works. Claude Code starts. The terminal is busier -- it is setting up a proper project structure, adding TypeScript types, writing utility functions with edge case handling, creating a test file. Time: 14 minutes and 47 seconds. It also works. Now the comparison. The narrator stress-tests both: "What happens when the streak crosses a month boundary?" Bolt's version has a bug. Claude Code's handles it correctly. "What about the UI?" Bolt's is more visually polished out of the box. "Both answers are right. The question is what you need right now: a working prototype by lunch, or a production foundation by end of week."

Visual Concepts for Remotion:

• ScaleBalance component: a literal balance scale that tips toward speed (Bolt) or quality (Claude Code) as different criteria are evaluated
• DualTimer composition: two race-style timers, one for each tool, with the differential growing as Claude Code continues working after Bolt finishes
• StressTest overlay: identical test inputs applied to both apps simultaneously, with results appearing as pass/fail indicators
• ContextCard end graphic: two scenario cards -- "Choose Bolt when: hackathon, prototype, demo day" and "Choose Claude Code when: production, long-term project, team codebase" -- appearing side by side
• Warm vs cool color split: Bolt's side in warm oranges (energy, speed), Claude Code's side in cool blues (precision, depth)

Video Production Workflow

Every video in this chapter follows the same five-stage production pipeline. This section documents the pipeline so that new videos can be produced consistently and efficiently.

Stage 1: Script Writing

Every video begins as a markdown file. Scripts follow a strict format:

---
video_id: PTP-001
series: prompt-to-product
title: "I built a $9/month SaaS in 60 seconds"
duration_target: 60-90s
tool: Bolt.new
status: production
last_updated: 2026-02-25
---

## Hook (0:00 - 0:03)
[Opening visual description]
NARRATOR: "Opening line designed to stop the scroll."

## Setup (0:03 - 0:08)
[Screen state description]
NARRATOR: "Context setting. What we are about to do and why it matters."

## Build (0:08 - 0:55)
[Screen recording cues with timestamps]
NARRATOR: "Running commentary on what the AI is doing. Call out
interesting decisions. Keep energy high."

## Reveal (0:55 - 1:05)
[Final product display]
NARRATOR: "The payoff. Show the deployed result. Land the key stat."

## End Card (1:05 - 1:10)
[Branding overlay]
NARRATOR: "Call to action -- next video, ebook link, subscribe."

Script guidelines:

• Target 150-200 words of narration per video (approximately 2 words per second at conversational pace)
• Every sentence must earn its place -- if it does not advance understanding or maintain engagement, cut it
• Write the hook first. If the first 3 seconds do not compel a viewer to keep watching, rewrite them
• Include specific timestamps for visual cues so the Remotion composition can sync precisely
• Mark all screen recording segments with [SCREEN: tool_name, action_description] tags

Stage 2: Visuals (Remotion Compositions)

Each video is a Remotion composition -- a React component that renders frame-by-frame to produce video output. The compositions combine three types of visual content:

Screen Recordings

• Captured at 60fps using OBS Studio with a standardized window layout
• Tool interfaces are recorded at 1920x1080 with consistent browser chrome
• Mouse movements are smoothed in post-processing for cleaner playback
• Sensitive information (API keys, personal data) is redacted before compositing

Motion Graphics

• Countdown timers, score overlays, progress bars, and transitions are all Remotion components
• The component library includes: CountdownTimer, ScoreBoard, SplitScreen, ProgressTracker, TitleCard, EndCard, AnnotationBubble, CodeHighlight
• All motion graphics follow the EndOfCoding design system (see Branding below)
• Animations use spring physics for natural-feeling motion (useSpring from Remotion)

Code Animations

• Code snippets that appear in videos are rendered using a custom CodeBlock Remotion component
• Syntax highlighting uses the same theme across all videos (VS Code Dark+ variant)
• Code appears with a typewriter animation at a configurable speed
• Diff views use green/red highlighting with line-by-line reveal animations

Composition structure:

src/
  compositions/
    prompt-to-product/
      PTP001-SaaS60.tsx        # Main composition
      PTP001-assets/            # Screen recordings, images
    the-prompt-that/
      TPT001-Game.tsx
      TPT001-assets/
    tool-face-off/
      TFO001-IDEShowdown.tsx
      TFO001-assets/
  components/
    CountdownTimer.tsx
    ScoreBoard.tsx
    SplitScreen.tsx
    EndCard.tsx
    StickyNote.tsx
    CodeBlock.tsx
    ProgressTracker.tsx
    RaceTimer.tsx
  styles/
    theme.ts                   # Shared colors, fonts, spacing
    animations.ts              # Shared spring configs

Stage 3: Audio

Narration

• AI text-to-speech narration using ElevenLabs or equivalent high-quality TTS
• Voice profile: confident, conversational, slightly fast-paced (matching the energy of the content)
• Each script is narrated as a single take, then trimmed and aligned to visual cues in Remotion
• Pronunciation corrections are applied for technical terms (e.g., "Supabase" is "soo-puh-base," not "super-base")

Sound Design

• Background music: royalty-free electronic/lo-fi tracks from Epidemic Sound or Artlist, selected per series (energetic for Prompt to Product, chill for The Prompt That, competitive for Tool Face-Off)
• Sound effects library: keystroke clicks, notification chimes, deployment whooshes, error buzzes, success dings, countdown ticks, boxing bells
• Music ducking: background track volume drops 60% during narration, rises during visual-only segments
• Audio levels: narration at -14 LUFS, music at -24 LUFS, sound effects at -18 LUFS

Stage 4: Branding

Every video carries the EndOfCoding brand identity consistently:

Logo

• The EndOfCoding logo appears in the bottom-right corner throughout the video at 40% opacity
• Full logo displayed on the end card at 100% opacity with the tagline

Color Palette

• Primary: #6C5CE7 (electric purple) -- used for highlights, CTAs, and active states
• Secondary: #00D2D3 (cyan) -- used for accents, secondary information
• Background: #0F0F23 (deep navy) -- used for all dark backgrounds
• Surface: #1A1A2E (dark surface) -- used for cards and overlays
• Text: #FFFFFF at 90% opacity for primary text, 60% for secondary
• Success: #00E676 -- used for pass indicators, completion states
• Error: #FF5252 -- used for fail indicators, error states

Typography

• Titles: Inter Bold, 48px (scaled for video resolution)
• Body: Inter Regular, 24px
• Code: JetBrains Mono, 20px
• Captions: Inter Medium, 18px

End Card (last 5 seconds of every video)

• Full EndOfCoding logo centered
• Three cross-link buttons: "Watch Next Video" (left), "Read the Ebook" (center), "Subscribe" (right)
• Social handles displayed below
• Background: animated gradient using the primary/secondary colors

Stage 5: Distribution

Each video exists in multiple formats for different platforms:

Full-Length (YouTube + Ebook Embed)

• Resolution: 1920x1080 (16:9)
• Duration: 60-120 seconds
• Format: MP4 (H.264) for YouTube, WebM for ebook embed
• Hosted on YouTube with ebook embed via YouTube iframe or self-hosted WebM

Short-Form Clips (TikTok / Instagram Reels / YouTube Shorts)

• Resolution: 1080x1920 (9:16)
• Duration: 15-60 seconds
• Extracted from the most compelling segment of the full video
• Additional text overlays for silent autoplay viewing (captions burned in)
• Platform-specific crops handled by a Remotion VerticalCrop composition

Ebook Embed

• Lightweight WebM format with lazy loading
• Poster frame (thumbnail) displayed before playback
• Fallback: animated GIF preview with a "Watch Full Video" link to YouTube
• Accessible: full transcript available below each embedded video

SEO and Metadata

YouTube Optimization

• Title format: [Hook] | Vibe Coding Tutorial #[N]
• Example: "I built a $9/month SaaS in 60 seconds | Vibe Coding Tutorial #1"
• Description: 200-300 words including the full prompt used, tools mentioned, timestamps, and a link to the ebook chapter
• Tags: tool-specific tags (bolt.new, cursor, claude code), technique tags (vibe coding, AI coding, prompt engineering), outcome tags (build app fast, no code saas)
• Timestamps: every section of the video marked for YouTube chapters
• Cards: each video includes a card linking to the ebook at the 75% mark
• End screen: 20-second end screen with next video and subscribe prompts

Cross-Linking

• Each YouTube video description links to the corresponding ebook chapter
• Each ebook video embed links to the YouTube version for higher-quality playback
• Related videos are suggested at the end of each ebook section
• Playlists: one per series (Prompt to Product, The Prompt That, Tool Face-Off)

Embedding Videos in the Interactive Ebook

The interactive web version of this ebook uses Remotion's @remotion/player component to embed videos directly in the reading experience. This means videos are not external links -- they are native elements of the page, rendered inline alongside the text.

Technical Implementation

Each video is embedded using a VideoTutorial React component:

import { Player } from "@remotion/player";
import { PTP001 } from "../compositions/prompt-to-product/PTP001-SaaS60";

export const VideoTutorial = ({
  compositionId,
  title,
  duration,
  tools,
  transcript,
}: VideoTutorialProps) => {
  return (
    <section className="video-tutorial">
      <h3>{title}</h3>
      <div className="video-meta">
        <span className="duration">{duration}</span>
        <span className="tools">{tools.join(" + ")}</span>
      </div>
      <Player
        component={PTP001}
        compositionWidth={1920}
        compositionHeight={1080}
        durationInFrames={2700} // 90s at 30fps
        fps={30}
        controls
        style={{ width: "100%", maxWidth: 800 }}
      />
      <details className="transcript">
        <summary>View Transcript</summary>
        <p>{transcript}</p>
      </details>
    </section>
  );
};

Reader Experience

When a reader scrolls to a video in the ebook:

1. Poster frame -- A thumbnail of the most visually interesting moment loads immediately (lazy-loaded image, minimal bandwidth)
2. Play button overlay -- A single click starts playback. Videos do not autoplay
3. Inline controls -- Play/pause, scrub bar, volume, fullscreen, and playback speed (0.5x to 2x)
4. Transcript toggle -- A collapsible section below the video contains the full narration transcript, making the content accessible and searchable
5. Chapter links -- If the video references tools or concepts covered in other chapters, inline links appear below the video

Offline and Static Fallbacks

For the markdown and Word versions of the ebook (which cannot embed video):

• Each video section includes the full script as formatted text
• A QR code links to the YouTube version
• A static screenshot of the key moment serves as the visual anchor
• The caption reads: "Watch this tutorial: [YouTube URL]"

For the static HTML version (no JavaScript):

• An animated GIF preview (5-10 seconds, looped) provides a visual taste
• A prominent "Watch Full Tutorial" button links to YouTube
• The transcript is displayed by default (not collapsed)

Video Production Schedule

New videos are added on a monthly cadence. The production schedule follows the tool landscape -- when a major tool update ships, a new video is produced within two weeks to document the changed workflow.

The schedule prioritizes alternating between series to maintain variety. High-impact tool launches (new Cursor version, Claude Code update, new entrant) can preempt the schedule.

Video Index

A quick-reference table of all videos in this chapter:

Measuring Video Impact

Each video is tracked across platforms with the following metrics:

Engagement Metrics

• YouTube: watch time, average view duration, click-through rate on ebook links
• TikTok/Reels/Shorts: views, shares, saves, profile visits
• Ebook: play rate (percentage of readers who click play), completion rate, transcript expansion rate

Conversion Metrics

• YouTube-to-ebook click rate (tracked via UTM parameters in description links)
• Ebook-to-YouTube click rate (tracked via embed interaction events)
• New subscriber acquisition per video

Quality Metrics

• Audience retention curve (identifying where viewers drop off)
• Comment sentiment (positive/negative/neutral classification)
• Video-specific NPS from reader surveys

Videos with below-average retention in the first 5 seconds get their hooks rewritten. Videos with above-average ebook-to-YouTube conversion get promoted in the chapter ordering.

This chapter is updated monthly with 2-4 new videos as the vibe coding tool landscape evolves. Each update includes new video entries, refreshed comparisons when tools ship major versions, and community-requested tutorials. Last updated: March 2026.

21. Monthly Intelligence Brief: March 2026

What changed in the vibe coding world this month. Updated on the 1st of each month for subscribers.

Key Developments

Numbers Update

What to Watch in April 2026

• EU AI Act full applicability date: August 2, 2026. Second draft of AI content labeling Code of Practice due mid-March
• VibeX 2026 academic workshop at the EASE conference in Glasgow
• Potential Google I/O announcements on Jules and Gemini coding capabilities
• Cursor Automations vs Claude Code Agent Teams: who wins the always-on agent war?
• Pentagon/Anthropic resolution: will defense contracts return to Claude or solidify the split?
• GPT-5.4 adoption: will native computer use shift the enterprise AI coding market?
• Kilo Code growth: open-source challenger to watch — 1.5M users in first weeks
• Open source sustainability: new funding models and contribution gatekeeping evolving rapidly

Chapter 22: Community Showcase

Real projects built by real people using vibe coding. Updated monthly.

Welcome to the Showcase

This chapter is different from the rest of the book. It is not written by us -- it is written by you.

Every project featured here was built using the techniques, tools, and philosophies described in the preceding chapters. Some were built by seasoned developers experimenting with a new workflow. Others were built by people who had never written a line of code before picking up Cursor or Bolt.new. All of them went from idea to deployed software using AI-native development.

The community showcase exists for three reasons:

1. Proof that it works. Theory is useful. Seeing a non-technical product manager ship an internal dashboard in four hours is more useful.
2. Shared knowledge. Every submission includes the prompts that worked, the mistakes that cost time, and the metrics that followed. This is a living library of hard-won lessons.
3. Inspiration. The gap between "I should build something" and "I shipped something" is often just seeing someone in a similar position who already did it.

We review submissions monthly and feature the most instructive projects -- not necessarily the most impressive ones. A weekend prototype that taught the builder three critical lessons about prompt structure is more valuable here than a polished SaaS with no story behind it.

How to Submit Your Project

We welcome submissions from anyone who has built and deployed something using AI-native development tools. Your project does not need to be generating revenue. It does not need to be technically sophisticated. It needs to be real, deployed, and accompanied by an honest account of how it was built.

Submission Template

Copy the template below, fill it in, and submit it to showcase@endofcoding.com or post it in the #showcase channel on our community Discord.

## Project Submission

**Project Name:**
[Your project name]

**Live URL:**
[Link to the deployed project]

**Builder Name:**
[Your name or handle]

**Builder Background:**
[Developer / Designer / Product Manager / Non-technical / Student / Other]
[Brief bio: 1-2 sentences about your experience level and day job]

**Tools Used:**
[List all AI tools: Cursor, Claude Code, Bolt.new, v0, Lovable, Replit Agent, etc.]
[List supporting tools: Vercel, Supabase, Stripe, Tailwind, etc.]

**Timeline:**
[Time from first prompt to deployed: e.g., "6 hours over a weekend"]

**Key Prompts (1-3 of your best prompts that made the biggest difference):**

Prompt 1:
"""
[Paste the actual prompt text you used]
"""
Why it worked: [Brief explanation]

Prompt 2:
"""
[Paste the actual prompt text]
"""
Why it worked: [Brief explanation]

Prompt 3 (optional):
"""
[Paste the actual prompt text]
"""
Why it worked: [Brief explanation]

**What Went Right:**
- [Bullet point]
- [Bullet point]
- [Bullet point]

**What Went Wrong:**
- [Bullet point]
- [Bullet point]
- [Bullet point]

**Metrics (share what you are comfortable sharing):**
- Users: [number or range]
- Revenue: [if applicable]
- Other: [downloads, signups, press mentions, job offers, etc.]

**One Sentence of Advice for Someone Starting Today:**
[Your best tip]

Submission Guidelines

• Be honest. The community benefits more from "this broke three times and here's why" than from a highlight reel.
• Include real prompts. Paraphrased or sanitized prompts are less useful. Share the actual text you typed.
• Deployed means deployed. The project must be accessible at a URL or downloadable. Screenshots alone are not sufficient.
• One submission per project. You can submit multiple projects, but each gets its own entry.
• Updates welcome. If your project evolves significantly, resubmit with a note about what changed.

Featured Projects

Project 1: WaitlistWizard -- SaaS Micro-Tool Built in a Weekend

What it is: A standalone waitlist management tool for indie makers launching products. Users create a waitlist page with a custom domain, collect emails with referral tracking, and send launch-day notifications. Includes an analytics dashboard showing signup velocity, referral sources, and geographic distribution.

Builder Profile: Marcus Chen, 29. Full-stack developer at a mid-size fintech company during the week. Side-project builder on weekends. Had used GitHub Copilot for two years but had never tried a full vibe coding workflow until this project.

Tools Stack:

• Cursor (Composer mode with Claude 3.5 Sonnet) for all code generation
• Next.js 14 with App Router
• Supabase for database, auth, and real-time subscription counts
• Tailwind CSS for styling
• Vercel for hosting
• Resend for transactional emails
• Stripe for the $9/month pro tier

Build Timeline: 14 hours across a Saturday and Sunday. First prompt at 9 AM Saturday. Deployed and shared on X at 11 PM Sunday.

Key Prompts:

Prompt 1 -- The initial spec:

Build a waitlist management SaaS with Next.js 14 App Router and Supabase.

Core features:
1. Landing page builder: user creates a waitlist page with custom title,
   description, and color scheme. Each page gets a unique slug (/w/[slug]).
2. Email collection: visitors enter email, get position number.
   Referral link generated automatically. Each referral moves the referrer
   up 3 positions.
3. Dashboard: real-time count of signups, chart of signups over time,
   top referrers table, geographic breakdown (from IP geolocation).
4. Launch notification: one-click send to all collected emails.

Auth: Supabase Auth with GitHub and Google OAuth.
Database: Supabase PostgreSQL with RLS policies.
Styling: Tailwind with a clean, minimal aesthetic. Dark mode default.

Start with the database schema and RLS policies, then build the
dashboard, then the public-facing waitlist pages.

Why it worked: Front-loading the database schema and RLS policies meant the entire data layer was solid before any UI code was written. This prevented three or four rounds of restructuring that typically happen when you build UI first.

Prompt 2 -- Referral tracking logic:

Add referral tracking to the waitlist system.

When a user signs up for a waitlist:
1. Generate a unique referral code (8 char alphanumeric)
2. Create a shareable URL: [domain]/w/[slug]?ref=[code]
3. When someone signs up via a referral link, record the referral
4. Move the referrer up 3 positions in the queue
5. Send the referrer an email: "Someone joined through your link!
   You moved up to position [X]."

Store referral chains (who referred whom) for the dashboard analytics.
Prevent self-referral. Cap position boost at top 10% of the list.
Handle edge cases: expired waitlists, duplicate signups from same email,
referral codes for non-existent waitlists.

Why it worked: Explicitly listing edge cases in the prompt eliminated two bugs that would have appeared in production. The AI handled all four edge cases correctly on the first generation.

Prompt 3 -- The analytics dashboard:

Build the waitlist analytics dashboard. The user is logged in and
viewing their waitlist's stats.

Show:
- Total signups (big number with daily change indicator, green up/red down)
- Signup velocity chart (line chart, last 30 days, using Recharts)
- Top 10 referrers table (name, referral count, conversion rate)
- Geographic distribution (top 5 countries as horizontal bar chart)
- Recent signups feed (last 20, real-time updates via Supabase Realtime)

All data fetched server-side with React Server Components.
The recent signups feed is a Client Component with real-time subscription.
Loading states: skeleton UI for each card while data loads.
Empty states: friendly message + illustration when no data yet.

Why it worked: Separating server components from client components in the prompt gave the AI clear architectural guidance. The result needed zero restructuring.

Before/After: Marcus had previously attempted to build a similar waitlist tool using traditional development. He spent three weekends on it, got about 60% through the feature set, and abandoned it when the referral position tracking logic became tangled. With vibe coding, the complete feature set was done in one weekend, including features he had not originally planned (geographic analytics, real-time feed).

Lessons Learned:

• Specifying database schema first in the prompt produces dramatically better results than letting the AI infer it from feature descriptions.
• Supabase RLS policies generated by AI need manual review. Two of the four generated policies had overly permissive conditions that would have allowed users to read each other's waitlist data.
• The AI-generated Stripe webhook handler worked on the first try, which was surprising -- this had been a pain point in every previous project.
• Deploying to Vercel mid-build (after the first two hours) and testing against the real deployment caught three environment variable issues early.
• Total cost: $0 for the build (Cursor Pro subscription he already had). $20/month for Supabase Pro + Vercel Pro once users started arriving.

Outcome: Posted on X and Hacker News the following Monday. 340 upvotes on HN. 2,100 signups in the first week. 180 paying users ($9/month) within 60 days. Currently at $1,620 MRR and growing. Marcus has not yet quit his day job but is now building his second product using the same workflow.

Project 2: FieldSync -- Internal Tool Built by a Non-Technical PM

What it is: An internal field operations dashboard for a 40-person landscaping company. Tracks crew assignments, job status, equipment location, client notes, and daily route optimization. Replaced a mess of shared spreadsheets, WhatsApp groups, and sticky notes on the dispatch office wall.

Builder Profile: Rachel Torres, 34. Operations manager at GreenScape Landscaping in Austin, TX. No programming experience. Had taken one HTML course in college a decade ago. Uses Excel daily and considers herself "tech-comfortable but not technical."

Tools Stack:

• Bolt.new for initial prototype
• Lovable for UI refinement and additional features
• Supabase for database and auth
• Google Maps API for route display
• Vercel for hosting

Build Timeline: Three evenings after work (roughly 3 hours each) plus most of a Saturday. Total: approximately 16 hours.

Key Prompts:

Prompt 1 -- The initial description:

I manage a landscaping company with 8 crews of 5 people each.
Every morning I assign crews to jobs using a spreadsheet and a
WhatsApp group. I need an app that:

1. Shows today's jobs on a map with crew assignments
2. Lets me drag and drop to reassign crews to different jobs
3. Crews can update job status from their phones (not started /
   in progress / done / issue)
4. Tracks which equipment trailer is with which crew
5. Stores client notes that persist between visits
6. Shows me a daily summary: jobs completed, revenue, crew utilization

Make it simple. My crews are not tech people. The mobile view needs
to be dead simple -- big buttons, minimal text.

I want to log in as admin and see everything. Crews log in with a
simple PIN code and only see their assigned jobs for today.

Why it worked: Writing from the perspective of the actual problem -- not in technical terms -- gave the AI everything it needed. Rachel did not know what a "database" or "REST API" was. She described her day, and the AI built the system to match it.

Prompt 2 -- Fixing the mobile experience:

The crew mobile view is too complicated. They need to see ONLY:
- Their jobs for today, in order
- A big button to change status (green = done, yellow = issue)
- A notes field for each job
- Nothing else

Remove the navigation menu on mobile. Remove the map on mobile.
Remove the equipment section on mobile. Crews do not need any of that.
Just the job list and status buttons. Make the buttons large enough
to tap with work gloves on.

Why it worked: The first version had given crews the same interface as the admin. This prompt stripped it down to exactly what a landscaper standing in a yard with dirty gloves needs. The "work gloves" detail led the AI to generate oversized touch targets (minimum 56px) -- better than many professional mobile apps.

Before/After: Before: Rachel spent 45 minutes every morning in dispatch, managing the spreadsheet, texting crew leaders, and calling clients. Crews often arrived at jobs without knowing the client's gate code or special instructions. Equipment went missing for days because nobody tracked which trailer went where.

After: Morning dispatch takes 10 minutes. Crews see their assignments on their phones before they leave the yard. Client notes (gate codes, dog warnings, irrigation shutoff locations) carry over automatically between visits. Equipment tracking reduced "lost trailer" incidents from two per month to zero in the first quarter.

Lessons Learned:

• Non-technical builders should start with Bolt.new or Lovable, not Cursor. The visual feedback loop is critical when you cannot read code.
• The PIN-code authentication for crews was Rachel's most important design decision. Username/password would have been a non-starter for the field workers.
• Google Maps API costs added up faster than expected. Rachel switched to a static map image for the daily overview and only loads the interactive map when a crew lead taps a specific job. Monthly API cost dropped from $47 to $8.
• The AI initially built a beautiful but unnecessary crew scheduling Gantt chart. Rachel deleted the entire component with one prompt: "Remove the Gantt chart. We don't need it. Keep it simple."
• Having a real user (her dispatch coordinator, Maria) test the app on day two caught three usability issues that Rachel had missed.

Outcome: FieldSync has been in daily use at GreenScape for five months. All eight crews use it. Rachel estimates it saves 6 hours of administrative time per week across the company. The owner asked her to "sell it to other landscaping companies," which she is now exploring. Total build cost: $0 (Bolt.new free tier was sufficient for the prototype; Lovable's free tier handled the refinements). Ongoing cost: $25/month (Supabase) + $8/month (Google Maps API).

Project 3: Resonance -- Startup MVP That Got Into Y Combinator

What it is: An AI-powered customer feedback analysis platform. Companies connect their support channels (Zendesk, Intercom, email), and Resonance automatically categorizes feedback by theme, sentiment, and urgency. Surfaces product insights that typically take a research team weeks to compile.

Builder Profile: David Park and Jenna Liu, both 27. David is a former ML engineer at a mid-tier AI startup. Jenna was a product manager at Salesforce. Neither had built a full-stack consumer product before. They quit their jobs in September 2025 with savings to cover six months.

Tools Stack:

• Claude Code for backend architecture and API integrations
• Cursor for frontend development
• Next.js 14 with App Router
• Supabase for database, auth, and vector storage
• OpenAI API for embeddings and classification
• Anthropic API for summary generation
• Vercel for hosting
• Stripe for billing

Build Timeline: Three weeks from first prompt to a working MVP. One additional week for polish before the YC application. Total: four weeks with two people working full-time.

Key Prompts:

Prompt 1 -- System architecture:

Design the architecture for a customer feedback analysis platform.

Data flow:
1. INGEST: Connect to Zendesk, Intercom, and email (IMAP) to pull
   customer messages. Webhook listeners for real-time ingestion.
   Dedup messages that appear in multiple channels.

2. PROCESS: For each message:
   - Generate embedding (OpenAI text-embedding-3-small)
   - Classify sentiment (positive/neutral/negative/urgent)
   - Extract themes (use clustering on embeddings, auto-generate
     theme labels)
   - Score urgency (1-5 based on sentiment + keywords + customer tier)

3. STORE: PostgreSQL for structured data. Supabase pgvector for
   embeddings. Link every insight back to source messages.

4. SURFACE: Dashboard showing:
   - Theme clusters with message counts and trends
   - Sentiment distribution over time
   - Urgent items requiring immediate attention
   - Weekly auto-generated summary of top themes and shifts

Multi-tenant: each company sees only their own data. RLS enforced
at the database level. API keys scoped per integration per company.

Build the ingestion pipeline first. I want to connect a test Zendesk
instance and see messages flowing into the database within the first
session.

Why it worked: David wrote this prompt like a system design document. The level of specificity on data flow, multi-tenancy, and storage separation meant Claude Code generated a clean, well-separated architecture on the first pass. The instruction to get data flowing in the first session kept the AI focused on the critical path.

Prompt 2 -- The insight generation engine:

Build the weekly insight report generator.

Input: All feedback messages from the past 7 days for a given company.

Process:
1. Cluster messages by theme (using cosine similarity on embeddings,
   threshold 0.82)
2. For each cluster with 5+ messages:
   - Generate a theme label (3-5 words)
   - Count messages and calculate sentiment breakdown
   - Identify the most representative message (closest to centroid)
   - Compare to previous week: is this theme growing, shrinking, or new?
3. Rank themes by: (message_count * urgency_avg * growth_rate)
4. Generate executive summary using Claude:
   - 3 paragraphs maximum
   - Lead with the most important shift
   - Include specific numbers
   - End with a recommended action

Output: Structured JSON with themes array and summary text.
Store in reports table. Send via email to company admin.

Handle edge cases: company with fewer than 10 messages that week
(skip report, send "not enough data" note), themes that appear
for the first time (flag as "emerging"), themes that disappear
(flag as "resolved").

Why it worked: The mathematical specificity (cosine similarity threshold, minimum cluster size, ranking formula) gave the AI enough constraints to produce a working implementation without guessing. Jenna later said the ranking formula in the prompt became the actual production ranking formula -- it was that well-specified.

Before/After: Before: David and Jenna had a pitch deck, three notebooks of customer research, and a Figma prototype. No working software. Their previous attempt at building the MVP with traditional development (David coding the backend, contracting a frontend developer) had consumed six weeks and $12,000 in contractor fees with only the auth system and a basic dashboard to show for it.

After: A fully functional platform that could ingest from Zendesk, classify feedback, cluster themes, and generate weekly reports. Three beta customers were using it with real data. The YC demo showed live feedback flowing in and being categorized in real time.

Lessons Learned:

• The combination of Claude Code for backend/architecture and Cursor for frontend was more effective than using either tool alone. Claude Code handled the complex data pipeline logic better; Cursor was faster for UI iteration.
• AI-generated API integrations (Zendesk, Intercom) worked for the happy path but failed on pagination, rate limiting, and error recovery. These required manual intervention and were the primary source of bugs during beta.
• The multi-tenant RLS policies were the single highest-risk component. David reviewed every policy line by line -- this was not a place to vibe.
• Having three beta customers during the build, not after, changed everything. Real data exposed clustering issues that synthetic test data never would have.
• YC partners were not impressed by the fact that it was vibe-coded. They were impressed by the speed: four weeks from zero to three paying customers with real usage data.

Outcome: Accepted into Y Combinator W26 batch. Raised a $500K pre-seed round before the batch started. Currently at $8,400 MRR with 14 paying companies. David estimates the vibe coding approach saved them three months and $40,000+ in development costs compared to traditional development, which directly extended their runway.

Project 4: karandev.co -- Developer Portfolio That Landed a Job

What it is: A personal developer portfolio site with interactive project showcases, a working blog with MDX support, an AI chatbot trained on the builder's resume and projects, and a live "what I'm working on" status pulled from GitHub and Spotify APIs.

Builder Profile: Karan Patel, 22. Recent computer science graduate from a state university. Solid fundamentals in Python and Java from coursework, but limited experience with modern web frameworks. Had applied to 47 junior developer positions with a plain HTML resume site. Zero callbacks.

Tools Stack:

• Cursor (Composer mode) for all development
• Next.js 14 with App Router
• Tailwind CSS + Framer Motion for animations
• MDX for blog posts
• Vercel AI SDK + OpenAI for the resume chatbot
• GitHub API + Spotify API for live status widgets
• Vercel for hosting

Build Timeline: One full week of focused work during winter break. Approximately 40 hours total.

Key Prompts:

Prompt 1 -- Portfolio design direction:

Build a developer portfolio site that will make a hiring manager stop
scrolling. Next.js 14 App Router with Tailwind CSS.

Design: Dark theme. Subtle grain texture background. Smooth scroll.
Minimal but not boring. Accent color: electric blue (#3B82F6).
Typography: Inter for body, JetBrains Mono for code snippets.

Sections:
1. Hero: My name in large type. One-line tagline that rotates between
   3 phrases (typed animation effect). Small "scroll down" indicator.
2. About: 2-paragraph bio. Photo (circular, subtle border glow).
   Tech stack icons grid (React, Python, TypeScript, etc.) with
   hover tooltips.
3. Projects: 3-4 cards in a grid. Each card: screenshot, title,
   one-line description, tech tags, links to live demo + GitHub.
   Cards tilt slightly on hover (3D transform). Click to expand
   into full case study.
4. Blog: Latest 3 posts pulled from MDX files. Title, date, read time,
   excerpt. Link to full post.
5. Contact: Simple email form (Resend API). Social links row.

Page transitions: smooth with Framer Motion. Sections fade-in on scroll.
Performance: 95+ Lighthouse score. No layout shift.

Why it worked: The prompt read like a creative brief, not a feature list. Details like "grain texture background," "cards tilt slightly on hover," and "typed animation effect" gave the AI a visual vision to execute against. The Lighthouse score target acted as a quality gate.

Prompt 2 -- The resume chatbot:

Add an AI chatbot to the portfolio that answers questions about me.

It should be a small floating chat bubble in the bottom right corner.
When opened, it expands into a chat window. Powered by OpenAI GPT-4o-mini
via the Vercel AI SDK.

System prompt for the chatbot:
"You are a helpful assistant on Karan Patel's portfolio website.
You answer questions about Karan's skills, experience, projects,
and education based on the context provided. You are friendly,
concise, and professional. If asked something not covered in the
context, say you don't have that information and suggest emailing
Karan directly. Never make up information about Karan."

Context document (embed this in the system prompt):
[I will paste my resume and project descriptions here]

Features:
- Streaming responses (token by token appearance)
- Suggested starter questions: "What are Karan's top skills?",
  "Tell me about his projects", "What is his education background?"
- Rate limit: max 20 messages per session to control API costs
- Chat history persists in the browser session (sessionStorage)
- Mobile responsive: full-width chat panel on screens under 640px

Why it worked: Providing the exact system prompt within the development prompt eliminated a round of iteration. The rate limit and cost control details showed practical thinking that the AI translated directly into implementation.

Before/After: Before: A single-page HTML resume with a white background, Times New Roman font, and three bullet-pointed project descriptions. Karan described it as "what you'd get if you exported a Google Doc to HTML." Forty-seven applications sent. Zero interviews.

After: A polished portfolio with smooth animations, interactive project showcases, a working blog, and an AI chatbot that could answer recruiter questions about Karan's experience at 2 AM. The chatbot alone generated over 600 conversations in the first month.

Lessons Learned:

• The AI chatbot was the differentiator. Three interviewers specifically mentioned it. One said, "I asked your chatbot about your Python experience and it convinced me to bring you in."
• Framer Motion animations generated by AI worked but were initially too aggressive (elements flying in from all directions). Karan's best prompt was a one-liner: "Reduce all animations to subtle fades and slight upward slides. Nothing should feel like a PowerPoint transition."
• The Spotify "now playing" widget was a fun addition but caused a privacy concern Karan had not anticipated -- it was broadcasting his music taste to potential employers during interviews. He added a toggle to disable it.
• MDX blog setup took longer than expected. The AI-generated MDX configuration worked for basic posts but broke on code blocks with certain languages. This required actual debugging rather than prompt iteration.
• Total cost: $0 for the build. Approximately $3/month for the OpenAI API calls powering the chatbot (GPT-4o-mini is cheap at volume).

Outcome: Karan posted the portfolio on r/webdev, Twitter, and LinkedIn. The Reddit post received 1,200 upvotes. The portfolio has had 14,000 unique visitors in three months. He received 11 interview requests in the first two weeks after launching. Accepted a junior full-stack developer role at a Series B startup in San Francisco. Starting salary: $135,000 -- $30,000 more than the median offer for new grads from his university. His manager later told him: "The portfolio showed us you could ship, not just code."

Project 5: Dungeon of Echoes -- A Game Built by a Teenager

What it is: A browser-based roguelike dungeon crawler with procedurally generated levels, pixel art aesthetics, turn-based combat, and a permadeath mechanic. Players descend through floors, collect loot, fight monsters, and try to reach floor 50. Leaderboard tracks the deepest floor reached.

Builder Profile: Aiden Nakamura, 16. High school junior in Portland, OR. Plays video games constantly. Had completed a Python basics course on Codecademy and built a few simple scripts. No web development or game development experience. Started this project during a snow day when school was cancelled.

Tools Stack:

• Replit Agent for initial game prototype
• Claude.ai (free tier) for debugging and game design advice
• HTML5 Canvas for rendering
• Vanilla JavaScript (no frameworks)
• localStorage for save data and leaderboard
• Replit hosting (free tier)

Build Timeline: Two weeks of after-school sessions (2-3 hours each) plus two full weekend days. Total: approximately 35 hours.

Key Prompts:

Prompt 1 -- The game concept:

Build a roguelike dungeon crawler game in HTML5 Canvas and JavaScript.
No frameworks, just vanilla JS.

The player starts on floor 1 of a dungeon. Each floor is a grid of
rooms generated randomly. The player moves with arrow keys. Each room
can contain: nothing, a monster, a treasure chest, a health potion,
or stairs down to the next floor.

Combat is turn-based. Player and monster take turns attacking. Damage
is based on attack stat minus defense stat plus a random factor.
When a monster dies, it drops gold and maybe an item.

Items: sword (increase attack), shield (increase defense), potion
(restore health). Items have rarity levels: common (white), rare (blue),
epic (purple). Higher rarity = better stats.

Permadeath: when the player dies, the run is over. Show a death screen
with stats: floors cleared, monsters killed, gold collected, time played.

Visual style: 16x16 pixel art aesthetic using simple colored squares
and basic shapes. Dark background. The dungeon should feel gloomy.

Start with movement and room generation. Add combat second.
Add items third. Add the death screen last.

Why it worked: Breaking the build into a clear sequence (movement, then combat, then items, then death screen) matched how game development actually works -- you get the core loop right before adding layers. Aiden said the AI "built each layer perfectly because it always had the previous layer working first."

Prompt 2 -- Making combat feel satisfying:

Combat feels boring. When I attack a monster or it attacks me,
nothing happens visually. Make it feel impactful:

1. Screen shake: brief shake (3 frames) when any attack lands
2. Damage numbers: float upward from the target and fade out, red for
   damage, green for healing
3. Flash effect: the hit target flashes white for 2 frames
4. Death animation: when a monster dies, it fades out and drops
   pixel particles downward
5. Sound: I know we can't do real sound easily, so fake it --
   flash the screen border red briefly on hit to give visual "impact"

Keep the turn-based system. These are just visual effects layered on
top of the existing combat logic. Do not change how damage calculation
works.

Why it worked: The constraint "do not change how damage calculation works" prevented the AI from rewriting the combat system while adding effects. Aiden had learned from an earlier mistake where asking for "better combat" caused the AI to replace his entire combat module.

Before/After: Before: Aiden had tried to build a game three times previously. Attempt one: followed a YouTube tutorial for a platformer in Unity, got stuck on collision detection, gave up after four hours. Attempt two: tried Godot, spent a weekend learning the editor, never got past the main menu. Attempt three: started a text adventure in Python, finished it, but wanted something visual.

After: A fully playable, visually polished (for a browser game) roguelike with 50 floors of content, seven monster types, fifteen items, a working leaderboard, and combat that "actually feels fun to play" according to the comments on his Reddit post.

Lessons Learned:

• Replit Agent was the right starting point for a first-time game builder. The instant preview and zero-configuration hosting removed all friction.
• Game feel (screen shake, particles, damage numbers) transforms a boring prototype into something people want to keep playing. Aiden spent 20% of total time on these "polish" effects and considers it the best time investment.
• Procedural generation produced occasional unwinnable floors where the stairs were placed in a room surrounded by walls with no entrance. Aiden fixed this by adding a post-generation validation step -- a prompt asking the AI to "verify that every room with stairs is reachable from the spawn point. If not, regenerate."
• localStorage has a size limit. After extended play sessions with many leaderboard entries, the game crashed. Aiden learned about data size limits the hard way and added cleanup logic.
• Aiden's classmates became his QA team. They found six bugs in the first day, all of which Aiden fixed by pasting error descriptions into Claude.

Outcome: Posted on r/roguelikes and r/IndieGaming. The Reddit post received 480 upvotes. The game has been played over 8,000 times. Aiden's computer science teacher gave him extra credit and invited him to present the project to the class. He is now building a multiplayer version and has started learning React "for real" because he wants to understand what the AI was generating. He says: "Vibe coding got me through the door. Now I actually want to learn what's behind the door."

Project 6: The Copper Pot -- E-Commerce Site for a Small Business

What it is: A full e-commerce storefront for an artisanal cookware shop in Asheville, NC. Features a product catalog with high-resolution image galleries, size/finish variants, a shopping cart with saved-cart recovery, Stripe checkout, order tracking, and an admin panel for inventory management.

Builder Profile: Linda Brennan, 52. Owner of The Copper Pot, a brick-and-mortar cookware shop she has run for 18 years. Zero programming experience. Previously paid a local agency $8,500 to build a Shopify store that she found difficult to update and expensive to maintain ($79/month for Shopify Plus plus agency retainer for changes). Heard about vibe coding from her nephew who is a software developer.

Tools Stack:

• Lovable for storefront and admin panel
• Supabase for product database, auth, and image storage
• Stripe for payment processing
• Vercel for hosting
• Resend for order confirmation emails

Build Timeline: Five days of working on it during slow hours at the shop, plus two evenings. Total: approximately 20 hours.

Key Prompts:

Prompt 1 -- The storefront:

Build an online store for my cookware shop called "The Copper Pot."

I sell high-end copper pots, pans, and kitchen tools. My customers
are home cooks aged 35-65 who appreciate craftsmanship. The feel
should be warm, artisanal, and trustworthy. Think: exposed brick,
natural tones, and beautiful product photography.

Pages:
1. Home: hero image with tagline "Handcrafted Copper Cookware Since
   2008", featured products grid (6 items), testimonial carousel,
   Instagram-style gallery of kitchen photos
2. Shop: filterable product grid. Filters: category (pots, pans,
   tools, sets), price range, material. Sort by price, newest,
   popularity.
3. Product detail: large image gallery (click to zoom), product
   description, size/finish selector, price, add to cart button,
   "You might also like" section with 3 related products.
4. Cart: line items with quantity adjustment, subtotal, shipping
   estimate, proceed to checkout.
5. About: our story, photo of the shop, craftsmanship values.
6. Contact: form + shop address + embedded Google Map.

Colors: warm cream background (#FDF8F0), copper accent (#B87333),
dark text (#2D2926). Font: serif headers (Playfair Display),
sans-serif body (Lato).

Mobile must be perfect. Most of my customers browse on their phones.

Why it worked: Linda described her customers and brand feeling, not technical specifications. The AI translated "warm, artisanal, and trustworthy" and "exposed brick, natural tones" into a design that Linda said "looks exactly like my shop feels." The color hex codes were her nephew's contribution -- he helped her pick colors that matched her physical store's palette.

Prompt 2 -- Admin inventory management:

Add an admin panel that only I can access (password protected).

I need to:
1. Add new products: name, description, price, category, images
   (upload multiple), sizes available, stock count for each size
2. Edit existing products: change any field, reorder images
3. Mark products as "sold out" (shows badge on storefront but
   keeps the page live) or "hidden" (removes from storefront)
4. View orders: list with date, customer name, items, total,
   status (paid / shipped / delivered). Click to see full details.
5. Update order status and add tracking number (customer gets
   an email when I mark it as shipped)
6. Simple dashboard: total revenue this month, number of orders,
   top selling products

Keep it simple. I am not technical. Big buttons, clear labels.
When I upload images, automatically resize them for the web
(I take photos on my phone and they are very large files).

Why it worked: "I am not technical. Big buttons, clear labels." This single line shaped the entire admin interface. The AI generated an admin panel with a significantly simpler layout than a typical CMS, with confirmations on every destructive action and undo options. The automatic image resizing solved a real problem -- Linda's phone photos were 4MB each.

Before/After: Before: A Shopify store that cost $8,500 to build and $79/month to maintain. Linda could not update product descriptions without emailing her agency and waiting 48 hours. Adding new products required a $150/change agency fee. The site looked generic -- it used a standard Shopify theme that looked identical to thousands of other stores.

After: A custom storefront that matches The Copper Pot's physical brand identity. Linda updates products herself through the admin panel. No monthly platform fees beyond Supabase ($25/month) and Vercel ($0 -- free tier). Stripe charges are 2.9% + $0.30 per transaction (same as Shopify).

Lessons Learned:

• Lovable was the right tool for someone with zero programming experience. Linda never saw a line of code. She described what she wanted in plain English and refined the results visually.
• Product photography matters more than website design. Linda initially uploaded poorly lit phone photos and the site looked "cheap." Her nephew helped her photograph products with natural light, and the same site suddenly looked premium.
• Stripe integration through Lovable worked seamlessly for simple checkout. However, Linda needed to handle sales tax, which required adding a tax calculation service. This was the only part where she needed her nephew's help.
• The "saved cart recovery" feature (emailing customers who abandoned carts) was not in Linda's original plan. The AI suggested it during a prompt about the checkout flow. It recovers approximately $300-$400 in sales per month.
• Shipping calculation was the hardest problem. USPS API integration was unreliable, so Linda switched to flat-rate shipping tiers ($8 / $12 / free over $150), which was simpler and actually increased average order value.

Outcome: Online sales in the first three months: $23,400. Previous Shopify store's best three-month period: $9,100. The warm, custom design and improved product photography drove a 34% increase in conversion rate compared to the old Shopify store. Linda's monthly tech costs dropped from $79 (Shopify) + agency retainer to $25 (Supabase). She saved approximately $3,000 in the first year on platform and agency fees alone. Three other local shop owners have asked Linda to help them build similar stores.

Community Stats

Aggregated from 247 community submissions received between October 2025 and January 2026.

Submissions Overview

Builder Background Distribution

Most Popular Tools

Note: Percentages exceed 100% because most projects use multiple tools.

Supporting Technology

Build Time Distribution

Average time from first prompt to deployed: 18.4 hours Median time from first prompt to deployed: 14 hours

Project Categories

Outcome Metrics

Success Patterns

From analyzing all 247 submissions, the projects most likely to succeed shared these characteristics:

1. Specific problem, specific user. "A tool for landscaping dispatchers" beats "a project management app" every time.
2. Prompt specificity. Builders who shared detailed, structured prompts (average 150+ words per prompt) had measurably better outcomes than those using short, vague prompts.
3. Early deployment. Projects deployed within the first 25% of total build time had a 73% continuation rate. Projects that waited until "done" to deploy had a 41% continuation rate.
4. Real users during build. 82% of revenue-generating projects had at least one real user testing before the builder considered it complete.
5. Two tools, not five. The most successful builders typically used one primary AI coding tool and one supporting tool. Projects that used four or more AI tools had lower completion rates, likely due to context-switching overhead.

Monthly Spotlight

March 2026 Spotlight: FleetTrack

Category: B2B SaaS / Logistics Builder: Raj Patel, 27, operations analyst at a logistics company Tools: Claude Code (Opus 4.6), Next.js 16, Supabase, Mapbox, Vercel Build time: 18 hours over one weekend

The Story: Raj managed a fleet of 40 delivery vehicles using spreadsheets and phone calls. He had never written production code before but had been following vibe coding tutorials on the EndOfCoding YouTube channel. When his manager complained about the lack of real-time visibility into delivery routes, Raj decided to build a solution himself.

His opening prompt to Claude Code:

Build a real-time fleet tracking dashboard with Next.js 16 and Supabase.

Core features:
1. Map view showing all active vehicles with live GPS positions
   (use Mapbox GL JS). Each vehicle is a colored dot -- green for
   on-schedule, yellow for delayed, red for stopped.
2. Sidebar with vehicle list, sortable by status, driver name, or
   ETA to next stop. Clicking a vehicle centers the map and shows
   route history for today.
3. Driver mobile view: a simple page where drivers tap "Arrived"
   at each stop. Auto-captures GPS coordinates. Works offline and
   syncs when back online.
4. Daily summary: auto-generated at 6 PM showing total deliveries,
   average time per stop, vehicles that went off-route, and fuel
   estimates based on distance traveled.

Auth via Supabase magic link. Role-based: admin sees everything,
drivers see only their own route. Use Supabase real-time subscriptions
for live vehicle position updates.

The dashboard must feel fast. Sub-200ms updates on the map.

Raj had a working prototype by Saturday night. By Sunday evening, he had added route optimization suggestions using a simple nearest-neighbor algorithm. He deployed to Vercel and showed it to his manager on Monday morning. Within two weeks, all 40 vehicles were using FleetTrack. The company cancelled its $800/month fleet management subscription.

Why we selected it: FleetTrack represents the next wave of vibe coding impact: non-developers building real B2B tools that replace expensive SaaS subscriptions. Raj's prompt demonstrates strong domain expertise combined with specific technical requirements -- the sweet spot where vibe coding delivers maximum value. The offline-sync requirement for drivers shows thoughtful product thinking that no AI would have suggested on its own.

Previous: February 2026 Spotlight: QuietPage

Category: Productivity tool Builder: Sana Mirza, 31, UX designer at a remote-first company Tools: Cursor, Next.js, Supabase, Vercel Build time: 11 hours over three evenings

The Story: Sana was frustrated by every writing app she tried. Google Docs felt corporate. Notion was too feature-heavy. iA Writer was beautiful but did not sync across devices. She wanted a writing tool that was quiet, distraction-free, synced to the cloud, and had exactly one feature beyond basic text editing: a daily word count streak tracker.

Sana opened Cursor on a Tuesday evening with this prompt:

Build a minimal writing app. I mean truly minimal.

One page. No sidebar. No toolbar. No menus visible by default.
Just a white page with a blinking cursor. The user types.

Auto-save to Supabase every 30 seconds and on every pause longer
than 2 seconds. Show a subtle "saved" indicator that fades in and
out -- bottom right corner, small gray text, disappears after 1 second.

One feature: daily word count streak. If the user writes at least
200 words today, the streak continues. Show the streak as a small
flame icon with a number in the top right corner. That is the only
UI element visible while writing.

Keyboard shortcuts (show on hover over a small "?" icon, bottom left):
- Cmd+B: bold
- Cmd+I: italic
- Cmd+Shift+H: toggle heading
- Cmd+/: toggle dark mode

No sign-up wall. Auth via magic link only. No password to remember.

If the writing app does not feel calm, it has failed.

The result was a writing app that four of Sana's coworkers started using within a week. She posted it on Hacker News with the title "I built the quietest writing app on the internet." It hit the front page. Within a month, QuietPage had 2,800 registered users and Sana was considering adding a $5/month premium tier for features like version history and export to PDF.

Why we selected it: QuietPage demonstrates that vibe coding is not just for building complex systems. Sometimes the hardest product decision is what to leave out. Sana's prompt is a masterclass in constraint-driven design, and the result is a product people genuinely prefer over established alternatives -- not because it does more, but because it does less, better.

Have a project that should be featured in next month's spotlight? Submit it using the template above.

Explore Further

• Get the complete prompt library in Chapter 17: The Complete Prompt Library -- 200+ production-ready prompts for every stage of AI-native development.
• Compare tools in Chapter 18: Tool Comparison Matrix -- Side-by-side evaluation of every major vibe coding tool.
• Secure your project with Chapter 19: The Security Playbook -- The pre-launch checklist every vibe-coded project needs.
• Try hands-on at vibe-coding.academy -- Interactive tutorials and guided projects.
• Join the discussion at endofcoding.com -- Community forum, Discord, and weekly office hours.

This chapter is updated monthly with new featured projects and refreshed community stats. Last updated: March 2026.

★ What Level Are You?

Answer 6 questions to discover your vibe coding level.

★ Glossary

Vibe Coding

AI-assisted development where the developer describes intent in natural language and evaluates output through execution, not code review.

Accept All

The practice of accepting all AI-generated code changes without reviewing diffs.

Coding Agent

An autonomous AI system that can plan, implement, test, and deploy code changes independently.

Composer

A mode in AI IDEs (like Cursor) that generates multi-file code from natural language descriptions.

Error-Driven Development

Debugging by copy-pasting error messages to the AI rather than reading and understanding the code yourself.

MCP (Model Context Protocol)

Anthropic's open protocol allowing AI assistants to connect to external tools and data sources.

Prompt Engineering

The skill of crafting effective natural language instructions to produce desired AI outputs.

Vibe Coding Hangover

The phenomenon of teams struggling to maintain, extend, or debug AI-generated codebases. Documented by Fast Company in Sept 2025.

Zombie App

An application that is functional but unmaintainable because nobody understands the AI-generated code.

Complexity Ceiling

The point at which a vibe-coded application can no longer be extended because the underlying code is too tangled.

Hybrid Workforce

An organization where AI agents work alongside human engineers, as pioneered by Goldman Sachs with Devin.

The 80/20 Rule

Vibe code the 80% (UI, boilerplate, standard patterns). Engineer the 20% (auth, security, business logic).

Agent Teams

A feature in Claude Code (introduced with Opus 4.6) allowing multiple AI agents to work in parallel on different aspects of a project, coordinating autonomously.

Agent Mode

A capability in coding tools (GitHub Copilot, Cursor, etc.) where the AI autonomously identifies subtasks, makes multi-file edits, runs tests, and fixes errors without step-by-step human guidance.

Devin Wiki / Devin Search

Cognition's documentation generation and code search tools built into the Devin platform, enabling AI-generated documentation and natural language querying of codebases.

Multimodal Coding

An emerging trend combining voice, visual, and text-based inputs for AI code generation — including screenshot-to-code and voice-to-code workflows.

★ Resources

Tools to Try

• Cursor — cursor.com — AI-native IDE ($1B+ ARR, $29.3B valuation)

• Claude Code — Anthropic's terminal coding agent with agent teams (Opus 4.6)

• GitHub Copilot — github.com/features/copilot — Agent mode in VS Code (4.7M users)

• Bolt.new — bolt.new — Browser-based app builder

• v0 — v0.dev — AI UI generation by Vercel

• Replit — replit.com — Browser IDE with AI agent

• Lovable — lovable.dev — App creation for non-developers

• Google Jules — jules.google — Async coding agent (Gemini 3 Pro)

• Gemini CLI — github.com/google-gemini/gemini-cli — Open-source terminal agent

• OpenAI Codex CLI — github.com/openai/codex — Open-source terminal agent

• Devin — devin.ai — Autonomous AI software engineer ($155M+ ARR)

• Windsurf — windsurf.com — AI IDE with persistent memory (now part of Cognition)

  Further Reading

  • Karpathy's original tweet (February 2, 2025)

• "Vibe Coding in Practice" — arXiv research paper (2025)

• "Vibe Coding Kills Open Source" — arXiv research paper (January 2026)

• Tenzai security assessment (December 2025)

• Cognition's Devin 2025 Performance Review

• Fast Company: "The Vibe Coding Hangover" (September 2025)

• IBM: "What is Vibe Coding?"

• Google Cloud: "Vibe Coding Explained"

• Vibe Coding — Wikipedia (comprehensive history and analysis)

  Example Projects

  Open the HTML files included with this ebook to see working applications built through vibe coding:

  • Task Manager (examples/task-manager-example.html) — localStorage, responsive design, animations

• Snake Game (examples/snake-game-example.html) — Canvas rendering, game loop, score tracking

• Prompt Examples (examples/vibe-coding-prompts.md) — Ready-to-use prompts by category

  "The vibes are real. The exponentials are real. The security vulnerabilities are real too. Code wisely."

  Last updated: February 25, 2026

  Part of the EndOfCoding Content Network

  📰 EndOfCoding.com

  Articles & thought leadership

  🎓 Vibe Coding Academy

  Interactive courses & lessons

  🎥 @endofcoding

  YouTube tutorials & demos

  📖 You are here

  Premium ebook & prompt library

What's New

Every update to this ebook is tracked here. Subscribers get monthly updates with new content, revised chapters, and fresh prompts.

March 2026

March 7, 2026

• Chapter 5 (Tools Landscape): Cursor updated to v2.6 (Automations, JetBrains support, MCP Apps). OpenAI Codex CLI updated for GPT-5.4 (native computer use, 1M token context). Claude Code updated with voice mode, $2.5B+ ARR, Pentagon supply-chain risk note. Added Kilo Code (open-source, 1.5M+ users). GitHub Copilot updated to 26M+ users with GPT-5 mini/GPT-4.1 included. Windsurf updated with Gemini 3.1 Pro and LogRocket #1 ranking.
• Chapter 9 (Numbers): Claude Code ARR updated to $2.5B+. Copilot users updated to 26M+. Added Emergent AI ($50M ARR in 7 months), Cognition ($500M raise, $10B valuation, $82M+ ARR). Added developer sentiment section (84% use AI, only 3% high trust, 60% favorable view down from 70%+, 15% professional vibe coding adoption). Collins Dictionary Word of the Year updated for 2026.
• Chapter 19 (Security Playbook): Added AI Tool Security Advisories section covering Claude Code CVEs (CVE-2025-59536 RCE, CVE-2026-21852 API key exfiltration) with actionable guidance on AI tool attack surfaces.
• Chapter 21 (Intel Brief): Added GPT-5.4 launch (computer use, 1M tokens, financial tools). Added Pentagon/Anthropic conflict. Added Claude Code voice mode and CVE patches. Added Kilo Code launch. Added Qwen 3.5 (open weights, 74.1% LiveCodeBench). Updated Cursor to 2.6. Updated Cognition $500M raise. Added developer sentiment and Emergent AI stats. Expanded "What to Watch" with EU AI Act, Kilo Code growth, Pentagon resolution.

March 6, 2026

• Chapter 21: Complete rewrite of Monthly Intelligence Brief for March 2026 — open source crisis, Gemini 3 in Jules, Cursor 2.5 subagents, Copilot multi-model access, Pega enterprise vibe coding, Opus 4.6 agent teams, Devin 2.2
• Chapter 22: New March 2026 Spotlight: FleetTrack — B2B fleet management built by an operations analyst using Claude Code
• Chapter 5: Updated tool references for Cline, Jules, and March 2026 landscape
• Chapter 9: Updated GitHub Copilot stats (26M+ users), Devin metrics (67% PR merge rate, $10.2B valuation), Claude Code revenue ($2.5B+)
• Landing page: Updated social proof stats, added Vibe Coding Academy cross-promotion section with UTM tracking
• All chapters: Updated badges to March 6, 2026

March 1, 2026

• Build System: Introduced automated build pipeline for chapter management and updates
• Changelog: Added this changelog section — subscribers can now see exactly what changed and when
• Per-Chapter Badges: Each chapter now shows its last-updated date
• All Chapters: Initial release of all 22 chapters with 200+ prompts

February 2026

February 25, 2026

• Initial release: All 22 chapters published
• Chapter 1: The Moment Everything Changed — complete timeline from Karpathy's tweet to Opus 4.6
• Chapter 5: Full tools landscape covering Cursor, Claude Code, Devin, Jules, Gemini CLI, Codex CLI
• Chapter 10: Security analysis including Tenzai study and IDEsaster disclosure
• Chapter 17: 200+ production-ready prompts across 10 categories
• Chapter 18: Comprehensive tool comparison matrix
• Chapter 19: The 30-minute security checklist for vibe-coded applications
• Chapter 22: Community showcase with submission guidelines