AI Coding Patterns 1: Vibe Coding

I killed a plant last year. I watered it, gave it sunlight, talked to it once or twice. It died anyway. I had no idea why.

That afternoon I opened an AI agent and typed: "Make me a landing page for a service called PlantAutopsy that tells people why their plants died." Ten minutes later I had a working page with a photo upload area, three feature descriptions, and a waitlist signup. The code was awful. I didn't read it. I didn't care.

That's vibe coding.

What Vibe Coding Is (and Isn't)

Andrej Karpathy coined the term in early 2025:

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.

He described accepting every diff without reading it, copy-pasting error messages with no context, and letting the codebase grow past his comprehension.

People use "vibe coding" to describe anything involving an AI agent and code. That muddles the conversation. When I vibe-code, I care about the result, not the code. I'm not reviewing diffs or writing tests. I just talk and see what happens.

The rest of this series teaches something different: using AI deliberately to produce work you understand and can maintain. I'll call that agentic coding.

Both are useful. The mistake is treating them as interchangeable.

The Rules of Vibe Coding

1. Speed over perfection. I'm moving fast. If I'm fussing over indentation, I've lost the thread.
2. If it works, it ships. The bar is "does it run?" not "is it good?"
3. Failure must cost minutes, not hours. If I've been stuck for more than ten minutes, I start over with a different prompt.
4. Refactoring comes later, if ever. I save my quality instincts for code that earns them.

When Vibe Coding Is the Right Tool

I use vibe coding for two things: workflow automation and feature exploration. In both cases, the output is disposable.

Workflow Automation

Example 1

I used to maintain a personal productivity library. Clean, refactored code organized for reuse. Now I have dozens of tiny uv scripts with a Justfile, each doing one thing:

Loading...

1. Generate Twitter draft from a URL
2. Process a YouTube video into a blog post
3. Read a GitHub issue in a clean format

Each script is self-contained with its own dependencies. Creating a new one takes less time than finding and configuring an existing tool.

Example 2

For my blog, and many other projects I need to host images somewhere. Often I put the images in the github repository of the project, or manually upload them to S3. Having them scattered meant there were duplicates, and when deployed with the app deployment speed suffered.

So I vibe coded a Discord bot. Described what I wanted, let the agent generate it, tested it, shipped it. If it breaks, I'll vibe-code a replacement faster than I'd debug the original.

It's a simple, personal tool that keeps me more organized and saves me a few clicks.

Feature Exploration

The pattern:

1. Vibe-code a prototype you can use
2. Use that to understand what works and doesn't
3. Generate a requirements doc from what you learned using the code as context
4. Build the real version with clear intent

Letting Code Graduate

Not everything stays throwaway. My Discord bot started as pure vibe coding. If it had needed to handle other people's data, I'd have refactored it. If it had become a real product, I'd have thrown away the code and rebuilt from a spec.

You don't have to decide upfront. Start loose. Let the code earn your attention.

Why Vibe Coding Doesn't Scale

Complexity

Vibe coding works when you can hold the entire system in your head. A personal script that formats your notes? Vibe-code it. A payment processing system with multiple services, shared state, and edge cases you haven't thought of? You'll lose track of what the code is doing long before it's finished.

Messy code can be cleaned up. The deeper problem is the gap in understanding. You end up with a system you can't explain, can't debug, and can't extend. Without that understanding each additional feature becomes harder to reason about.

This concept is called cognitive debt, and it's the subject of the next chapter.

Risk

It's also a question of consequences. What's the harm if something is broken? If a thumbnail for my personal blog doesn't upload, I'll fix it eventually. If customer data leaks because an agent made a security decision I never reviewed, that's a different category of failure.

The greater the potential harm, the more you need to understand what it's actually doing. Vibe coding is not the right approach for that.

Exercise: Prototype Your Project

Pick something you care about, small enough to prototype in one session but complex enough to need a spec and tests eventually.

If you don't have an idea, pick one of these:

• PlantAutopsy. Follow along with my examples directly.
• A personal finance tracker. Categorize expenses, generate reports.
• A recipe manager. Parse recipes from URLs, scale ingredients.
• A reading list app. Track books, capture notes, generate summaries.

Now vibe-code a prototype. Open your AI agent and describe what you want. No planning, no spec, no architecture. Just describe the thing semi-lazily and see what comes back.

Give yourself ten minutes. Run it and see if it does roughly what you described.

Save whatever you end up with.