Although I'm not a vibe-coder, I'm a developer. It actually gives couple of interesting facts to bear in mind as I will attend a hackathon in April. Good to know, thanks for the article !

It is so true

The hallucination-under-pressure pattern is consistent — models get more confident-sounding exactly when context degrades, which is the worst time to trust them. The planning phase working well but execution breaking down is exactly the gap most vibe-coding workflows haven't solved yet.

This is such a real take! It’s easy to think AI tools make building a game simple, but the 'pressure test' of a hackathon always reveals the gap between prompting and actually debugging. What was the most unexpected bug the AI introduced for you?

This is a genuinely useful post because it documents exactly the gap between "AI generates code" and "AI generates correct code under pressure."

The hackathon setting makes it even more telling. When you're vibe coding for a demo, the stakes are low — if it breaks, you regenerate. But the habits you build there carry into real projects where the cost of a subtle bug is way higher.

What I keep coming back to: the bottleneck was never generation speed. It was always verification. You can get AI to write a game loop in 30 seconds, but figuring out whether that game loop actually handles edge cases correctly takes the same amount of human attention it always did. Maybe more, because the code looks plausible enough that you trust it.

The METR research on AI-assisted coding showed developers perceived they were 24% faster while actually being 19% slower. The gap comes from exactly what you described — the time spent debugging and re-prompting eats the generation speed advantage.

Not saying vibe coding is useless. But knowing when to switch from "generate fast" to "verify carefully" is the real skill. Sounds like the hackathon taught you that under pressure, which is the best way to learn it.

Loved this write-up, especially the “reset between rounds” part. In my experience vibe coding works great until the first ambiguous state bug shows up, then you end up spending more time debugging prompts than debugging code. The planning-first point is spot on - I usually force myself to write down the data model and 2-3 user flows before touching the AI tool, and it saves a ton of backtracking. Also +1 on frequent commits, version history is basically your safety net with AI-generated code.

We’ve been collecting a few patterns for rescuing vibe-coded apps (what tends to break, how we stabilize fast) at heydev.us/blog if it’s useful.

Loved the “reality check” angle here. In my experience, vibe coding works fine for the first 60-70%, but the last mile is always about making implicit assumptions explicit - data model invariants, error boundaries, retries/timeouts, and observability. One thing that helps is to freeze the happy-path code and then write a short list of “production contracts” (inputs, authz, rate limits, idempotency) and only refactor to satisfy those.

We end up rescuing a lot of vibe-coded apps once they hit real users, wrote up a few patterns that keep the speed without the chaos: heydev.us/blog

Great writeup. Your lesson #1 really resonated — "plan before you vibe code."

I hit the same wall but earlier in the process. Before I even start prompting, I kept finding out the thing I wanted to build already existed. Claude would happily help me code a food delivery tool for 6 hours, then I'd search GitHub and find 12 mature competitors.

The hallucination problem you describe during execution is real, but there's an even earlier hallucination most people miss: when you ask "is this idea original?" and the AI says "yes, go build it!" without actually searching anything.

I ended up building an MCP tool that does that search automatically — scans GitHub, HN, npm, PyPI before you write a single line. Would've saved me a lot of the "reset and start over" cycles you described between rounds.

Curious — for your Glitch Hunt game, did you check if similar web-based duck hunt remakes existed before building? Not criticizing at all, just wondering if knowing the landscape upfront would've changed your approach or scope.

AI agents management is a tough job than you think it would be. To maintain AI context drifting is difficult. You might want to check this article that I wrote

dev.to/wilddog64/i-gave-gemini-one...

Hi @konark_13, I'm building a code editor, Stellify, that's all about preventing AI (and human developers, remember them?) from going off track in the way you've described. The main things it does so far:

• Uses a set stack, PHP (Laravel on the server), my own JS framework (with adaptors for Vue, React, Svelte) on the client. When AI starts a task, the first call it makes is to a get_project tool that gives it info about the stack, the libraries that are available (plus versions) and key references (see the next bullet).

• Stores code as granular JSON in a database with persistent references and other metadata. This allows AI to be surgical when it comes to making updates and keep the context window to a minimum. When you're ready to export/ deploy the JSON is re-assembled back to source files.

• In terms of prompts, I have an intermediate layer that analyses your prompt for keywords and attaches only relevant instructions. The API also provides, code analysis and testing endpoints that AI can use (via MCP) to keep it on track.

The next (hopefully last) piece of the puzzle, is assisting with planning prompts to optimise for clarity, not fully sure how best to do this given the vast array requirements that are possible. In theory I like the idea of capturing prompts and running a "prefetch" to AI that breaks apart your prompt and makes it optimal before passing he refactored prompt to AI. I'm currently building lots of projects to get a feel for what's right here as it's hard to reason about (at least for me).

I'd be interested to hear your thoughts!

This AI hype is a skill degraiding phase for ppl invested in it. Programmers who don't engage with it will have an advantage over time. Don't print, use the brush.

Spot on - vibe coding is great for momentum, but it quietly removes the “design review” checkpoint.

One thing that’s helped teams I’ve worked with is to add a short hardening pass after the first demo: threat model the data flows, add a few contract tests around the riskiest endpoints, and put basic observability in place (structured logs + one dashboard).

Curious - do you have a checklist you run through before you let a vibe-coded tool touch production data?

I'm still trying to wrap my head around the idea of building a game with AI tools. Konark, your experience with hallucinations and deployment issues is a great reminder that these tools are still so new and finicky. I love that you're documenting what you've learned, especially the importance of verification and human judgment, it's a crucial balance to strike when working with AI.

Thank you for mentioning peer feedback. This is one thing I wish I had more of when I'm building.

ITHINKSO

This is sow true!