- The Concept
Snack Game (Neon Snake) is a responsive, browser-based Snake game built for quick, polished arcade-style play. I chose a Snake game for this one-day sprint because it is a strong baseline for testing a multi-AI pipeline—specifically, how well one AI can plan a full product spec and hand it off to another AI to turn that plan into working game code. Unlike a simple calculator, Snake requires a real-time game loop, canvas rendering, input handling across desktop and mobile, persistent state, and a complete UI layer—making it a harder and more realistic test of AI handoffs.
- The Stack
The Stack: HTML5, Vanilla CSS, and JavaScript with the Canvas API. No frameworks, no libraries, and no database.
The AI Assist: Cursor handled the initial product planning and generated a strict requirements document (snack-game.md) covering gameplay, UI, mobile controls, sound, dark mode, and folder structure. OpenAI Codex was then used exclusively for the coding phase, taking Cursor’s markdown document and translating it into functional source code across index.html, assets/css/styles.css, and assets/js/game.js.
- The 1 Day Sprint
Morning (Hours 1–3): We kicked off by brainstorming browser games that need strict state management and real-time updates. We settled on Snake. We spent the next two hours prompting Cursor to define the full feature set—glassmorphism UI, difficulty levels, pause/resume, game-over modal, high score with localStorage, animated food, sound effects, dark mode, and mobile touch controls—and generated a strict markdown handoff document for the developer.
Afternoon (Hours 4–6): The coding phase. We fed the handoff doc to Codex. Codex generated the project scaffold quickly, but the first pass had rough edges: movement felt choppy because the game loop tied rendering directly to grid ticks, mobile swipe controls were unreliable, and the Web Audio API needed a user gesture before sound would play. We spent these hours debugging the game loop, direction queue logic, and collision detection with Codex—especially the edge case where eating food should not trigger a self-collision on the same frame.
The Finish Line (Hours 7–8): With time running out, we focused on polish over new features. We added interpolated rendering for smooth snake movement, refined the glassmorphism layout and dark-mode theme, ran final QA on keyboard, swipe, and on-screen controls, and pushed the repository to GitHub.
- The Roadblocks
Roadblocks: The biggest roadblock was again the "lost in translation" effect between the two AIs—but in a different way than a calculator project. Cursor planned a polished, production-quality game with many UX details, while Codex’s first pass prioritized getting basic movement working and treated visual polish and mobile input as secondary. Smooth movement required a fixed-timestep loop with interpolation, which was not in the initial handoff and had to be added during debugging. Audio also failed silently until we wired sound initialization to the first user click. Because of the strict time limit, we had to cut scope on extras like leaderboards or power-ups and focus on making the core loop, controls, and UI feel solid.
- Key Takeaways
What was the part that worked the best? The structural planning phase. Cursor produced a clear requirements doc in minutes—covering responsive layout, accessibility labels, difficulty tiers, and file separation—that would normally take a human developer much longer to write before coding starts.
What was the part that worked the worst? Multi-AI handoffs for real-time game behavior. Codex understood the Snake rules quickly, but it missed subtle implementation details from the plan—smooth animation, reliable touch input, and audio lifecycle—until we iterated with targeted prompts. UI structure came together faster than game-feel tuning.
My final thought: If I had one more day, I would add a proper settings panel, keyboard remapping, and a replay or ghost-snake feature. If I could redo this project, I would keep Cursor for planning but add one more QA pass inside the same session before calling the sprint done—either with the same model or a single advanced model for both planning and coding—so requirements like smooth movement and mobile controls do not get dropped between steps.