Vibe Coding for Non-Engineers (3) — Long-Term Principles

Part 1 covered what vibe coding is. Part 2 walked through the first hour. This post is for the fifth project, the tenth, the you-of-a-year-from-now.

Two messages in this one:

1. There is a limit to "I don't read code." It's farther than you'd think — but it exists.
2. Not everything the AI produces is correct. Verification is the actual skill.

Reading is the bottleneck

The most important sentence in Karpathy's original framing was probably this one:

"Vibe coding is fine for throwaway projects. For serious things, you need to be able to read the code."

When the AI writes 100 lines in a minute, someone has to read those 100 lines. At first that someone is the AI. Eventually it should be you.

If you never read the code, three things start to happen:

1. Subtle bugs slip past you

The AI often produces code that looks like it works but doesn't. Every Todo saving with the same ID; data appearing in the UI but never actually persisting; a counter that resets on Tuesdays for no reason. Looks fine on screen. Discovered a week later.

2. Maintenance becomes impossible

Three months later you say "change the button color," and the AI rewrites a hundred files. You have no way of knowing which changes were correct.

3. Security incidents (the scary one)

The most common AI-generated bugs include hard-coded API keys, no input validation, leaked secrets pushed to GitHub. We'll cover these.

Three-step verification

You don't have to read all the code. You do have to do these three steps for every feature.

Step 1 — Does it work?

"Use the feature the way it was meant to be used."

Obvious. People skip it. When Claude says "implemented," go to the browser and click through. One in five times, it doesn't actually work.

Step 2 — What about edge cases?

"Try it with non-normal input."

• Empty input
• Very long input (10,000 characters)
• Special characters, emoji, mixed languages
• Multiple rapid clicks
• After a refresh

If any breaks — tell Claude exactly: "this input breaks it."

Step 3 — Security review

This step you ask Claude explicitly:

"Audit this code for security issues. Specifically: hard-coded secrets, missing input validation, SQL/XSS injection, authentication bypass. Fix anything you find."

That one prompt prevents most disasters.

Five security traps non-engineers fall into

Trap 1 — Hard-coding API keys

// Never write this
const OPENAI_KEY = "sk-proj-abc123...";

The moment that lands on GitHub, a bot scrapes it within 30 seconds. Your monthly bill becomes a five-figure problem. Real story, multiple times a year.

Right way: environment variables (a .env file). Tell Claude explicitly: "store API keys in environment variables, never inline."

Trap 2 — Pushing .env to GitHub

Confirm .gitignore includes .env. Ask Claude: "Check this project's .gitignore — does it cover all the secret files I shouldn't commit?"

Trap 3 — Skipping input validation

If a user types <script>alert("hack")</script> into a search box and the page actually runs it — that's a cross-site scripting (XSS) bug. Tell Claude:

"Add proper validation and sanitization wherever user input is accepted."

Trap 4 — No auth on sensitive data

"My personal expense tracker, anyone with the URL can view it" is shockingly common. Add authentication — a password, OAuth, anything — before launch.

Trap 5 — Telling Claude "security doesn't matter, this is just for me"

Don't. Anything on the internet is, by definition, public.

When to call a real engineer

Two or more of these and you need a human engineer:

1. More than 100 users — performance, databases, infrastructure begin to matter
2. Money flows through it — payments, refunds, taxes; mistakes have legal consequences
3. Sensitive data — health, finance, personal records
4. Downtime equals lost revenue — customers must always have access
5. More than 5,000 lines of code — beyond what any AI can hold in context
6. Three or more people collaborating — merge conflicts, code review, ownership

At this point, your role as a non-engineer shifts: from CTO to PM. Hire engineers or outsource, but stay the person who knows precisely what's being built.

Good news — a vibe-coded MVP is a hiring asset. "I built this" is the strongest founder claim there is.

Learn Git (it takes 50 minutes)

Git is the single thing non-engineers postpone the longest. Fifty minutes of learning saves a lifetime of pain.

The five commands you need:

git init                    # start tracking
git add .                   # stage changes
git commit -m "message"     # snapshot
git push                    # send to GitHub
git checkout HEAD~1         # go back one version

That's it. Ask Claude: "Teach me these five Git commands step by step." Fifty minutes, done.

With Git: anything you break, you can revert. The AI taking the wrong turn becomes recoverable.

The compounding power of small tools

The biggest payoff for a non-engineer is not one big app. It is many small tools stacked over time.

A hypothetical year of one hour per week:

• A weekly running-data dashboard (3 hours)
• An Apple Health → PDF report tool (5 hours)
• A travel expense tracker with auto-FX (the TripBooks pattern, 30 hours)
• A script to organize GPX files for cities you've visited (1 hour)
• A personal blog (50 hours — the way this site was built)

Each one is small. The pile is large. That's the actual promise of vibe coding.

You, one year from now

If you follow this three-part series and do an hour of vibe coding a week for a year:

• About 50 small tools
• 5–10 you use daily
• 1–2 that someone else might want to use
• And — a precise sense of what's possible and what isn't

You won't become an engineer. You'll become a maker. Maybe that matters more.

The "I'm not a developer, so…" person you used to be is gone.

What's the next project?