← All posts
AISystemsThinkingPragmaticProgrammingVibeCoding

How to Vibe Code Like a Pro

It's not just about learning fundamentals.

I keep seeing the same advice for vibe coders. “Learn the fundamentals first.”

But I’ve never heard anybody say what that means, exactly. To me, it just sounds like “struggle like I did so I don’t feel bad that you have it so easy.”

That being said, you do need to understand programming to vibe code. AI can only get you so far. It writes code perfectly, but is lousy at executive decisions and architecture.

Where AI Fails

I just learned about OTP a few weeks ago and am building my first tools with it. I came up with an architecture and asked Fable to build it out an app for me based on it. Yes, that Fable, the new hotness at the time of this writing.

And Fable wrote the code. And the code was wrong. It was based on my design understanding as a developer with a background in OOP. Fable didn’t make that connection that my architecture was wrong for the system I was building. And it didn’t even try to stop me.

That’s because AI lacks understanding. It lacks comprehension. It lacks judgement. Those traits remain exclusively human. And even Fable can’t replace them.

The trick is that AI can do the bricklaying for you. But you still need to be an architect. The “fundamentals” are software design, architecture, and patterns. I mean, of course, you really do need to understand objects, functions, loops, variables, and flow control. But after all of that, architecture.

How to Git Gud

But you also have to just know how to be a good programmer. You have to know good code from bad code. You might think that understanding good programming practices are something that take years of hands-on learning. But fortunately, there’s a book for even that. It’s called The Pragmatic Programmer by Andrew Hunt and David Thomas. And it should be required reading for anybody before they ever write their first “please create a hello world app for me” prompt.

The Pragmatic Programmer — Cheatsheet

Hunt & Thomas · 20th Anniversary Edition · Core principles at a glance

Here is an AI generated cheatsheet to help you get started if digital living has wrecked your ability to read a whole book, like it has for me.

Commit this to memory! These are the fundamentals.

Pragmatic Philosophy

Principle
✅ Tip Care about your craft. It’s not enough to just make it work.
📏 Rule Take responsibility. Don’t make excuses — offer options instead. Don’t say “it can’t be done”; explain what can be done.
⚠️ Avoid Broken windows. Fix bad designs and poor code immediately. Neglect breeds neglect.
✅ Tip Be a catalyst for change. Show people what’s possible; don’t just ask for permission.
📏 Rule Know your portfolio. Invest in knowledge regularly, diversify, and manage risk.
✅ Tip Communicate clearly. Know your audience, choose the moment, listen actively.

A Pragmatic Approach

Principle
📏 Rule DRY — Don’t Repeat Yourself. Every piece of knowledge must have a single, authoritative representation.
⚠️ Avoid Orthogonality violations. Keep components independent; changes in one shouldn’t ripple into others.
✅ Tip Tracer bullets. Build a thin end-to-end slice first to find out if you’re aiming at the right target.
📏 Rule Prototype to learn. Prototypes are disposable code to answer questions — not foundations for production.
✅ Tip Estimate everything. Develop a feel for orders of magnitude and communicate uncertainty honestly.

The Basic Tools

Principle
📏 Rule Use plain text. It will outlive every proprietary format and is universally readable by tools.
✅ Tip Master your shell and editor. Fluency with tools multiplies everything else you do.
📏 Rule Use version control for everything — not just code. Config, docs, notes. Always.
✅ Tip Fix the root cause, not the symptom. When debugging, ask “why?” repeatedly, not just “what?” Rubber duck it — explain the problem aloud.
⚠️ Avoid Coincidence-driven programming. Know why your code works, not just that it does.

Pragmatic Paranoia

Principle
📏 Rule Design by contract. State pre/postconditions and invariants explicitly; enforce them.
⚠️ Avoid Dead programs tell no lies. Crash early rather than silently propagating bad state.
📏 Rule Use assertions. Never assume — validate invariants throughout your code.
✅ Tip Finish what you start. The code that allocates a resource should be responsible for releasing it.
⚠️ Avoid Temporal coupling. Don’t assume operations happen in a specific order unless you explicitly enforce it.

Bend or Break

Principle
📏 Rule Decoupling. Tell, don’t ask — components shouldn’t reach into each other’s internals to make decisions.
✅ Tip Configure, don’t integrate. Put volatile values (URLs, credentials, thresholds) in config, not code.
📏 Rule Avoid global state. Shared mutable state is the root of most concurrency bugs.
✅ Tip Programming is writing. Use metaphors, model the domain in your vocabulary, name things precisely.

While You Are Coding

Principle
⚠️ Avoid Programming by coincidence. Every decision must be deliberate and understood.
📏 Rule Refactor early, refactor often. Don’t let cruft accumulate; the longer you wait, the more it costs.
✅ Tip Test your thinking. Write tests as a way to understand requirements, not just verify implementation.
📏 Rule Test early, test often, test automatically. Keep a reliable suite; broken tests are broken windows.
✅ Tip Don’t gather requirements — dig for them. Requirements are buried under assumptions and politics.

Before the Project

Principle
⚠️ Avoid Feature bloat. Solve the stated problem well; don’t gold-plate with features nobody asked for.
📏 Rule Abstractions live longer than implementations. Invest in interfaces and protocols, not specific tools.
✅ Tip Work with users to think like users. Get real feedback early; documents and meetings lie.

Pragmatic Projects

Principle
📏 Rule Automate everything. Manual procedures leave room for error and inconsistency. Automate the build, test, and deploy pipeline.
✅ Tip Sign your work. Take pride in what you produce. Craftsmanship is a professional identity.
⚠️ Avoid Knowledge silos. Make teams generative; bus factor > 1. Document, pair, and share context.

The Five Core Metaphors

  • Stone soup — be a gentle catalyst; show people what’s possible
  • Broken windows — neglect compounds; fix problems immediately
  • Boiling frog — watch for gradual scope and quality creep
  • Tracer bullets — aim before you fire; validate direction early
  • Rubber duck debugging — explain your problem aloud to find the answer

The One-Line Version

“Think about what you’re doing. Every day, every decision. A good-enough now is better than perfect never — but only if you keep improving it.”

Legend: ✅ Tip · 📏 Rule · ⚠️ Avoid

Let's Work Together

You probably have a problem
that doesn't have a job title.

The best work I've ever done didn't fit a category. Someone had a messy, undefined, doesn't-fit-the-org-chart problem — and needed someone willing to actually figure it out.

Let's talk.