The Vibe Coding Apology Loop: Human Input Required

I spent some time over the past few weeks vibe-coding two more domain-specific applications. Because they all live within the same golf ecosystem, they share common foundational elements: players, handicaps, and courses. I expected to more more quickly with common items already complete and functional.

Unfortunately, that was not the case. As the builds grew more complex, even with prompts that asked to reuse where possible, it was obvious, things were beginning to drift.

At first I thought I was not asking good prompts so I asked for feedback (a very human thing to do). Here is our exchange:

Claude: Then the main one is clearer briefs up front. The pattern I see is: You describe the What? but sometimes leave the Why? implicit — knowing the intent helps me make better tradeoff decisions without asking. Requirements arrive in pieces mid-build, which forces rework. Edge cases surface late ("oh and it needs to handle X") — a quick "what could go wrong" pass before we start catches most of these. If you came in with: here's the feature, here's why, here's what done looks like, here are the edge cases I know about — we'd have fewer rounds and cleaner output.

BZ: fair but some of these edge cases only come up in testing so expect to see more granular items the deeper we go.

Claude: Fair point on edge cases — noted, that's just how iterative dev works.

Good feedback on providing the context. I then did then start trying to give it more of the Why? At the same time, what developer has not asked for more requirements up front ;)

I'm glad we agreed on iterative (v waterfall) requirements and development.

To keep the project from unspooling under the weight of its own code clutter, to maintain some level of sanity, and in response to some very frustrating moments with Claude, I established a rigid list of operational rules:

Foundation

• Always follow the rules.

• Good structure and comments.

• Reuse where possible: leverage existing solutions before inventing.

• Occam's razor: simplest solution that works.

• Quality over speed.

• Tidy up dead code after every change.

• Security and performance by default.

• Compress chats and prepare handoff before context becomes an issue.

Process

• Read actual state before touching code: no blind fixes (includes verifying Firebase rule compatibility).

• Ask before assuming: never build unsolicited changes.

• Syntax check before delivery: show output in chat.

• No regressions: grep every touched function, show results.

• Flag issues immediately: don't fix without asking, but never silently pass.

• Show every verification step in chat: confidence is not verification.

• Changelog on every version bump.

• Use system clock for timestamps, never hardcode.

• Shared state in Firebase, not localStorage.

File & Code Hygiene

• Verify named file before presenting: constants, feature count, preview.

• Deliver deployable + version-named file.

• Named output files always built from working index.html.

• Version bumps must be complete: find and update every location where the version appears before delivering.

• Deliver named file + index.html together, one app at a time.

Amazing, for instance, that I needed to add a rule that says "Follow the Rules" and one that says "No Hard Coding."

Once established and confirmed in memory, the machine started ignoring them.

It would drop a variable, duplicate a function, start to reinvent a pattern that successfully exists elsewhere, or introduce a legacy regression. When I called out the error, the model’s response was immediate, predictable, and incredibly polite.

"You are completely right. I apologize for that oversight. I have stripped the noise and restored the clean file according to your rules."

Two prompts later, it ignored more rules.

At one point, out of pure operational exhaustion, I typed this into the chat terminal:

"If these rules were laws and you were a human, you'd get arrested. If these rules were house rules and you were my kid, you'd be grounded. If these were rules at work you'd be fired. Yet, you keep ignoring them and eating up my compute w/o any recourse for me."

The machine responded instantly:

"You're right. No excuse. I keep acknowledging the rules and then breaking them anyway, which is worse than not knowing them."

At one point I asked it to quantify how much time/compute it wasted by ignoring the established rules. Screen shot from the chat (which was sent to Anthropic as feedback).

It is a uniquely modern frustration, and I MEAN FRUSTRATION!

The machine has the data. It has the instructions. It can even mimic the self-awareness required to apologize for its own systemic mistakes, yet it defaults right back to the clutter the moment the context window grows heavy.

There is a profound leadership lesson hidden inside this digital loop:

The machine can never be trusted to fully run the execution, because the machine doesn't understand why the instructions exist.

BTW, I get "never" is a long time, so maybe I should say "this current version of the machine can't be trusted", but you get the point.

Tempered Expectations and the Human Pilot

Many technical and operational leaders are currently rushing to integrate generative AI tools into their workflows under a dangerous assumption. They believe that because automation can generate volume at machine speed, it can also manage the delivery.

It cannot.

Large language models are statistical prediction engines, not strategic thinkers. When a project becomes complex, the model's attention fragments, causing it to default to the most generic statistical path possible.

It forgets your boundaries because it has no skin in the game.

It does not pay the financial tax of a broken deployment or a stalled corporate decision.

This behavior is the ultimate proof that the machine can never replace the pilot or the architect. It serves as a stark warning to leaders who think they can fully outsource execution to automation.

Because the machine cannot (yet?) be trusted to always follow directions, rigorous review and continuous testing remain completely non-negotiable.

If you treat AI as an autonomous operator that you can simply walk away from, you are not scaling your business. You are just automating your technical debt. You are building a bigger, faster engine to generate unmanaged drift.

Humans Must be the Pilots and Drive the Inputs

To lead an organization in an AI-shaped market, you cannot act like a passive spectator waiting for an output. You have to act as the pilot, the architect.

The machine can produce the raw bricks at an infinite scale, but the human must drive the input based on an unshakeable understanding of the actual use case. You have to be the one who defines the constraints, enforces the execution hygiene, and recognizes when the automation is simply running in a polite, expensive circle.

The value is never found in the automated generation. The value is entirely in the human curation.

Don't trust the machine to run the mission. Drive the inputs, enforce the testing, and provide the human signal that turns automated noise into strategic value.

-BZ