Vibe coding.

Shipping software without writing much code.

You're not a full-time engineer. You don't want to be. You have a problem that a 200-line Python script would solve, and you don't want to spend three days learning Python to write it.

Vibe coding is the practice of staying in the designer seat while Claude does the typing. You describe what you want. Claude writes the code. You read it, test it, push back when it's wrong. You ship real software without ever becoming the person who wants to write for-loops by hand.

This module is 90 minutes of the practice. By the end:

• A working vibe coding loop you'll use weekly.
• One shipped utility you'll actually use tomorrow.
• The patterns for when to trust Claude and when to read every line.

Thinker.

Vibe coding works because writing code and reading code are different skills. You don't need to write Python to read it and tell whether it's doing what you asked.

The vibe loop

1. Describe the task in plain language. Be specific about inputs and outputs.
2. Claude writes the code.
3. You read it. If it looks right, run it.
4. If the output is wrong, show Claude the output and ask for a fix.
5. Commit when the output matches expectations.

What "designer seat" means

You own three things: the problem definition, the acceptance criteria, the commit. Claude owns the code between those gates.

When NOT to vibe code

• Security-critical code (auth, crypto, payments).
• Code that touches production data without a dry-run.
• Code you can't read at all and can't test.

Everything else is fair game.

Talker.

The quality of the code is downstream of the quality of the spec. Three prompts cover 90% of vibe coding.

The task prompt

Write a [language] script that:
- Reads [input]
- Does [transformation]
- Writes [output]

Constraints:
- No external dependencies beyond [list].
- Must handle [edge case].
- Must fail loudly on [error case].

Return only the code, no explanation. I will read it before
running.

The fix prompt

The script ran but produced this output: [paste]
Expected: [describe]

Show me the diff that fixes it. Don't rewrite the whole
script. Only the lines that change.

The review prompt

Before I commit, review this script as a skeptic. Name the
three things most likely to break it. Don't fix them yet,
just name them.

The review prompt catches bugs before they cost you a weekend.

Rememberer.

The repo is your memory. Commit early, commit often, commit with messages that explain the why.

One folder per vibe project

~/vibe-coded/
  invoice-parser/
    parse.py
    README.md         (what it does, who asked)
    test-input.pdf
    test-output.csv
  slack-digest/
    digest.py
    README.md

Every project has a README with two sentences. What does it do, and who was complaining when you built it. Six months later, the second sentence tells you why you cared.

Commit messages are specs

Write commit messages in the present tense, as if they were feature descriptions. "parse.py: handles multi-page PDFs and groups by invoice number." Future-you can git log and read the full history of intent.

Doer.

Twelve minutes to ship a real utility you'll use tomorrow.

mkdir -p ~/vibe-coded/my-tool
cd ~/vibe-coded/my-tool
git init
# save script, write README
git add .
git commit -m "my-tool: [one-line spec]"

Rookie.

Failure 1. Running code you can't read

You paste, you run, it seems to work. A week later it corrupts a file because you never read it. Claude hallucinated an API call.

Fix: read every line before running. If you can't follow a section, ask Claude to explain it. Vibe coding is vibes on top of literacy, not instead of it.

Failure 2. No tests, no trust

You ship the script. It runs on your machine. It fails on your colleague's because of a path assumption.

Fix: one test input and one expected output, committed with the script. Claude can write the test too. Five more minutes, infinite confidence.

Failure 3. Using vibe coding for the wrong problem

You try to vibe-code a distributed system. Or a payment integration. Or something that needs domain expertise you don't have.

Fix: vibe coding is for utilities and glue. For anything production-critical, pair with a real engineer or learn the stack first. Know the boundary.

Manager.

Vibe coding on a team works if the rules are explicit. It breaks if they're not.

Three team rules

• Vibe-coded scripts live in a utilities/ folder. They're not library code. No one else builds on top of them without review.
• Every vibe-coded script needs a test. Minimal, but present.
• Production code is not vibe-coded without review. Non-negotiable. Engineers review. Then it can ship.

Who should vibe code

PMs, operators, founders, designers, analysts. Anyone who has a problem a script would solve. Engineers already write code; vibe coding doesn't add much for them.

The vibe coder's home

Some teams have a vibe-coded/ repo where operators ship their scripts. Weekly, an engineer scans the repo. Promotes the useful ones to proper infrastructure. Lets the rest live as one-offs.

Chief.

Vibe-coded tools inside a company are a governance surface.

Risk 1. Data handling

Vibe-coded scripts touch customer data, payroll, HR files. Make sure the operator knows what they can and can't put through an LLM. A one-page AI policy (Module 024) covers this.

Risk 2. Shadow IT

Vibe coding democratizes scripting. Which means shadow IT grows. Not necessarily bad, it's better than people doing the same work manually. But it needs visibility. The vibe-coded/ repo gives leadership a view of what operators are solving on their own.

Risk 3. Compounding reliance

Someone vibe codes a revenue-critical script in three hours. Six months later, the script runs every night. No one owns it. When it breaks, no one knows why. Classic org debt, accelerated.

Fix: any vibe-coded script that runs automatically in production needs a named owner and a real engineer review. Promoting it out of the utilities/ sandbox.

Founder.

For a founder who isn't an engineer, vibe coding is the single highest-leverage skill in AI.

The weekly utility

Every week, ship one vibe-coded utility. Over a year, you have 50 tools that automate the things that used to eat your Fridays. The compound cost of rebuilding these by hand (hiring an engineer, opening a ticket, waiting a week) is enormous. Vibe coding collapses it.

The three files

• ~/vibe-coded/, your folder of scripts.
• A template README.md you reuse.
• A text file of task prompts you've written. Copy, paste, modify.