Day 2 - VIBE CODING A GAME IN 7 DAYS

A team building a tower-defense/Roguelike game in a week credits “vibe coding” with turning a blank project into a playable prototype in roughly a day—complete with balloon-like enemies following paths, tower placement, combat mechanics, card/deck hands, and some animation. The momentum comes from letting an AI-driven workflow handle large chunks of implementation quickly, while human collaborators steer with constraints (including explicit “no balloons,” which still resulted in balloon-like behavior until it was corrected). By the next day’s target, the stated goal is to make the game fully playable by 24 hours, then push it toward something stable by noon.

The most concrete productivity claim centers on Cursor’s tab-based editing. Pressing Tab doesn’t just autocomplete; it “ghosts” likely code changes and enables rapid refactors—such as replacing a function argument or propagating a modification across multiple similar lines—without manually rewriting blocks. That tab workflow becomes the team’s preferred lever, especially for iterative cleanup and structural changes, even for people who are skeptical of fully autonomous “agent mode.” One participant describes a tension: the speed of agent-driven generation is addictive, but the urge to understand the system remains strong, leading to a cycle of “vibe” work followed by returning to inspect and fix what was produced.

Collaboration friction also emerges as a real constraint. Starting a brand-new project with multiple people working at once creates “style conflicts” in architecture decisions—where rendering logic lives, how functions attach to data classes, and whether behavior should be properties, separate functions, or message-passing between components. The team compares the situation to multiple people hammering the same piece of wood: small surface area means constant collisions. Their workaround is to converge on shared rules for state and updates—keeping most data centralized as state, passing it consistently, and reducing complex message-passing.

On the gameplay side, progress is measured in concrete features: towers can be placed, cards are drawn, enemies spawn and move along routes, and the draw/combat pipeline needs tuning. A “Bloons TD reimplementation” reference appears as a motivating comparison point, and a specific bug/overshoot is addressed when enemy drawing logic becomes too aggressive—prompting deletion and regeneration of the problematic balloon-related behavior. The team also leans on documentation and existing engine/library capabilities, citing a “read the docs” moment when screen resizing and layout math are handled by built-in functions.

By the end of the session, the group is still iterating—tightening cursor-follow behavior, fixing rendering/playability issues, and preparing to load and render a level. The vibe-coding agreement becomes a running bit, but the practical takeaway is serious: fast AI-assisted iteration works best when paired with clear editing shortcuts (Tab), explicit constraints, and agreed-upon architectural rules so the codebase doesn’t fracture under multiple simultaneous changes.