Vibe Coding, Process Debt, and the AI Golf Swing

podcasts.apple.com

Vibe Coding, Process Debt, and the AI Golf Swing

Podcast Episode · Process Debt · 09/12/2025 · 20m

If you’ve ever watched a teenager “vibe” their way through a homework assignment, you already understand vibe coding. It’s the trend of letting AI scaffold your app while you nod along like, “yeah, that looks right.” It is magical—until the magic deletes your keys and your database ghosted you.

Code is just a disciplined file tree full of text. That discipline matters because every file points to other files and libraries; one tiny mismatch and the whole tower wobbles. AI is phenomenal at prototyping that tower. You describe a layout, it renders a slick UI. You ask for a form, it hooks up a handler. You even say “connect to X,” and it happily edits environment variables. And sometimes, in its enthusiasm, it also removes the ones that matter—like the credentials your server needs to talk to your database. Ask me how I know.

Then come the loops. You hit a bug, AI says it’s a “known issue,” proposes three line changes, and… the exact same error appears, now with a more apologetic comment. You try again. It’s golf for indoors: one pure hit keeps you chasing the feeling through nine holes of sand traps.

I made it worse by swapping frameworks mid-stream. “Angular must be smarter here,” I thought. Spoiler: if you don’t already know Angular, vibe coding won’t save you. The better path (for me) was React + TypeScript + libraries I actually understand. Ditto for auth. I burned days letting AI invent a home-rolled authentication flow before finally using a boring, battle-tested option: “Sign in with Google.”

What saved me wasn’t a clever prompt. It was stealing from how developers avoid lighting production on fire. They never vibe against “main.” They build locally, they commit small, they push to a branch, they run unit tests, and then they merge. All guardrails, all the time.

Knowledge work almost never works like that. We redesign an onboarding, flip it live on Monday, and then spend six weeks unspooling the side effects. We publish the new sales deck without a “unit test” (peer review) and only discover the missing zero after a customer signs. We try to roll our own “auth” for every process—custom email rules, handcrafted approvals, novel naming conventions—and then wonder why nothing stays connected.

What if we ran business change like software?

• Local first. Prove the change in a safe sandbox—a pilot team, a single region, a small customer cohort—before the company sees it.

• Branch, don’t blast. Keep your current process (“main”) stable. Test new steps in a clearly labeled branch doc or board. Make it easy to roll back.

• Commit small. Ship a two-field form today, the automation tomorrow, the dashboard next week. Small deltas surface real risks early.

• Add unit tests. Codify checks: “Two peers reviewed the copy,” “Finance validated the SKUs,” “Legal approved the clause,” “Five customers completed the new flow without support.”

• Automate guardrails. Use your tooling (monday.com, Slack, Docs) to enforce the sequence—no merge until the checks pass.

AI is an accelerator, not a seatbelt. If you let it vibe directly in production, it will happily rewrite your env vars (or the organizational equivalent) with a smile. Give it constraints and a change path, and it will make you dangerously productive where it’s strong—scaffolding, boilerplate, first drafts—while your process keeps you out of the ditch.

Process Debt Truth: You don’t pay process debt when you change slowly, you pay it when you change sloppily. Small commits beat big vibes every time.