Breaking the Cloud Barrier: Building a Game with Local AI (Qwen 3.5 & RTX 5090)

For a long time, the prevailing narrative in AI development has been that if you want to build real software, you need a massive cloud budget and enterprise-grade H100 GPUs. The assumption is that “local” AI is for simple chatbots, while “serious” engineering requires the cloud.

We wanted to see if that assumption is still true.

To test the limits of current local LLMs, we set out to build a classic Snake game from scratch. The rules were simple, zero lines of manual code. We relied entirely on a consumer-grade PC, a local open-source model, and OpenCode, an open-source AI coding agent that integrates LLMs with local development workflows.

Here is how we did it, and whether this workflow is actually viable for developers today.

The Setup

To ensure we weren’t bottlenecked by hardware, we utilized a high-end consumer setup paired with a quantized version of a top-tier open-source model.

The Hardware

• GPU: NVIDIA® GeForce® RTX™ 5090
• RAM: 64GB
• CPU: Intel® Core™ Ultra 9 285K (24 Cores)

The Model: Qwen 3.5 27B (By Alibaba Cloud)

We selected Qwen 3.5 27B for its reputation as a coding powerhouse. According to the Artificial Analysis Intelligence Index, Qwen 3.5 27B leads its weight class with a top score of 42.

Unlike “Mixture of Experts” (MoE) models that only activate a fraction of their parameters per task, Qwen 3.5 27B uses a Dense architecture. This means it utilizes its entire network for every token it generates, providing the consistent reasoning required for complex software engineering.

We used Unsloth’s 4‑bit quantized Qwen 3.5 27B to fit within our VRAM constraints. This quantization dramatically reduces memory and computational demands while retaining most of the model’s capabilities, enabling high-performance inference on the hardware.

The Inference Engine

We ran the model using llama.cpp, a lightweight C++ engine that directly loads the quantized GGUF model files into memory. This setup reduces the processing overhead, allowing OpenCode’s API requests to be handled quickly with minimal delay, even on consumer-grade GPUs.

Phase 1: The “Design-First” Protocol

The biggest mistake developers make with AI is jumping straight into the code. This often leads to “architectural drift”, where the AI forgets the original goal halfway through.

To prevent this, we utilized OpenCode’s Plan Mode. This enforces a design-first protocol where the AI must articulate the entire architecture before a single line of code is written.

Your task is to design the implementation plan for a browser-based Snake game with a high-fidelity visual style.

Environment:
- The project will run locally
- Use HTML, CSS, JavaScript, Node.js, and npm
- The rendering should utilize the HTML5 Canvas API for performance and visual effects
- The project must run with an npm command (e.g., npm start)

Goal:
Create a high-performance, visually intense implementation of the classic Snake game. The focus is on a "Neon" aesthetic with complex animations and a modular architecture that handles heavy rendering tasks efficiently.

Game Requirements:
- Grid-based snake movement
- Arrow key controls
- Food spawning randomly
- Snake grows when food is eaten
- Collision detection with walls and itself
- Score tracking
- Game over screen
- Ability to restart the game
- Visual Theme: Neon (glowing edges, vibrant colors, dark background)
- Animation Intensity: Heavy (screen shake, pulses, smooth transitions)
- Food Style: Apple-like (rendered with stem and leaf details)
- Snake Appearance: Complex (eyes + shine reflection effects + distinct tail styling)
- Particle System: Dynamic particles generated when food is eaten

Before writing code, produce a full implementation plan.

Your plan should include:

1. Project architecture (Modular structure for rendering vs. logic)
2. File structure
3. Responsibilities of each file
4. Game state design (Handling score, high score, game status)
5. Data structures for snake, grid, and particles
6. Game loop design (Using requestAnimationFrame for smooth heavy animation)
7. Rendering approach (Canvas context, glow effects, particle rendering pipeline)
8. Algorithms for:
   - movement
   - food spawning (with detailed styling logic)
   - collision detection
   - particle system (spawning, updating, fading out)
9. Input handling
10. A step-by-step task list for implementation

Important:
DO NOT write any code yet.

Only produce a clear implementation plan that an AI coding agent could execute step-by-step. Ensure the plan addresses how to manage the performance cost of the requested heavy visual effects.

The planning phase achieved four critical goals:

1. Architectural Integrity: A strict separation between game logic and rendering.
2. Algorithmic Pre-Determination: The logic for snake growth and collision was solved before implementation.
3. Execution Roadmap: A step-by-step checklist for the agent to follow.
4. Environment Standardization: Ensuring the code would run locally without missing dependencies.

More importantly, we were impressed that the model didn’t just blindly agree. It acted like a senior engineer, asking clarifying questions:

• “Should the snake’s speed increase as the score rises?”
• “How should high scores be persisted (e.g Local Storage)?”
• “Do we need mobile touch-support or just keyboard controls?”

Here’s a visual diagram that depicts the the AI’s architecture of the game.

As seen in the diagram, the AI successfully implemented a clean architecture with strict separation of concerns. The Logic Layer encapsulates game entities and state management. The Engine Layer handles core systems such as the game loop and input, and the Presentation Layer delegates rendering to specialized components, all orchestrated by a central Game class.

Phase 2 – Execution and Debugging Loop

Once the blueprint was signed off, we switched to Build Mode. The initial functional game was generated in under an hour, but it wasn’t perfect. We encountered bugs with keyboard responsiveness, sound triggers and UI alignment.

To fix these, we adopted a “Human-in-the-Loop” strategy:

1. Describe the Issue: We pasted raw errors from the browser console directly into the chat.
2. Refresh & Test: OpenCode regenerated the specific problematic functions.
3. Iterate: We repeated this until the logic was flawless.

The “Vision” Game-Changer

The most difficult part of AI coding is describing UI bugs. For example, the food (apple) didn’t look authentic and the score labels were rendering inside the game grid. Telling an AI that “the apple looks slightly off” is vague and inefficient.

Because OpenCode supports image attachments, we simply took a screenshot of the UI and told the AI to fix the issues.

Here’s a screenshot from the game after fixing the UI rendering issues.

The Verdict: Is Local AI Ready for Dev Work?

Our experiment demonstrates that the “cloud requirement” is often overstated. You can build functional, real-world software using a fully local stack, provided you work within its constraints. Here are our key takeaways:

• Consumer Hardware is Mostly Enough: With quantization, capable models can run within consumer VRAM with minimal loss in practical performance.
• Iterative Prompting Beats One-Shot Generation: The real advantage of local AI is the speed of the Describe → Fix loop, not perfect first drafts.
• Plan → Build → Debug Is Essential: Forcing the model to define architecture upfront prevents architectural drift and improves code quality.
• Vision Matters: For UI/UX work, vision-based debugging consistently outperforms text-only descriptions. If your tooling supports images, use them.
• Know the Trade-offs: Local models can be slower and occasionally less reliable than top-tier cloud systems but for many development workflows, the control and privacy are worth it.

While local AI won’t fully replace cloud solutions, it is now a practical and attractive choice for a wide range of development tasks.