How Insane Is AI Coding for Game Dev? One Month, One Card Game Clone, 100K Lines of Code

Project Overview: One Person Using AI to Clone a Complete Card Game

A developer named White Wolf spent just over a month using AI Coding tools to clone all 114 Hunter-class cards from the popular card game Grand Bazaar. During this period, he made over 500 code commits totaling approximately 100,000 lines of code—all written with AI assistance.

The project used the Godot engine, despite the developer having zero prior Godot experience—he simply read the official Quick Start guide and jumped straight in. The final result includes complete battle logic, a shop system, item effects, UI presentation, and a full single-player game loop.

About the Godot Engine: Godot is an open-source, cross-platform game engine officially released by Juan Linietsky and Ariel Manzur in 2014. Unlike Unity or Unreal Engine, Godot uses a Node Tree architecture and its own scripting language, GDScript. The entire editor is extremely lightweight (under 100MB), with no runtime royalties. Because of this "lightweight" nature, the engine has very few built-in abstraction layers—developers need to build game systems nearly from scratch. In the AI-assisted programming era, this actually becomes an advantage: AI-generated code doesn't need to negotiate with complex built-in frameworks and can be directly executed.

Project Kickoff: A Documentation-First AI Development Strategy

The Importance of Design Documents

Before writing a single line of code, the developer spent several days establishing detailed design documents covering core mechanics, in-game and meta-game loops, and more. He emphasized: For AI, knowing exactly what you're building and what you want from the very beginning is critically important.

These design documents went through multiple rounds of review with AI, refining the details thoroughly. The developer remarked, "If the design docs at my day job were this good, I'd be laughing in my sleep." Every time he launched Codex, he simply had the AI read the documentation and it could start working immediately—saving enormous communication overhead.

MVP Screen Flow Documentation

For a pure UI game like Grand Bazaar, the developer pre-defined 10 different screens and their transition relationships, each with detailed information descriptions. This allowed AI to quickly generate a complete skeleton with closed-loop navigation, after which the developer only needed to fill in logic on top of that skeleton.

Managing Document Freshness

The developer specifically called out an easily overlooked issue: document freshness. Outdated documents can actually cause AI to make incorrect judgments. Temporary documents should be deleted once used—don't leave them around to pollute the AI's information base.

This problem is known in software engineering as "Documentation Drift"—code evolves but documentation remains stuck describing the old version. In traditional development, outdated docs only mislead human developers. In AI-assisted development, LLMs weigh document content and current code state equally in their context reasoning, amplifying the "pollution effect" of outdated documentation by several orders of magnitude.

Key Decisions in AI Game Development

Day One: Building the MVP Skeleton

On the very first day, a small MVP flow was implemented. While lacking details, it already allowed navigation between all screens. Based on the documentation, AI set up basic data definitions and a simple framework. The developer exclaimed: "What I built in one day would have taken a week or more to hand-code."

Why Godot?

Because Godot is "bare-bones" enough. In the pre-AI era, being bare-bones was a disadvantage; in the AI era, it's an advantage—AI can freely manipulate everything, and iteration speed is extremely fast. Unlike engines like UE with their massive built-in frameworks, everything in Godot needs to be built by hand, which actually gives AI more room to operate.

Unreal Engine has numerous highly encapsulated subsystems (such as GameplayAbilitySystem, BlueprintGraph, etc.). When AI modifies these systems, it needs to understand deep inheritance hierarchies and implicit conventions, making it extremely prone to producing hard-to-trace side effects. Godot's "blank slate" nature means every line of AI-generated code is fully visible and controllable—aligning perfectly with the core AI-assisted development requirements of "verifiable and rollbackable."

Avoiding Becoming a "Press Enter Robot"

The developer raised an important point: if AI has a 90% probability of making the correct decision, blindly following AI's decisions 10 times in a row yields a final accuracy of 0.9^10 ≈ 35%. You need to maintain your own judgment rather than unconditionally trusting every AI decision.

This phenomenon is called "Error Propagation" in probability theory. What's even more concerning is that LLM errors are often not randomly distributed—when AI makes a wrong architectural assumption, all subsequent decisions based on that assumption will systematically deviate from the correct direction, with actual error rates far exceeding what independent probability models would predict. This requires developers to actively intervene at critical architectural decision points rather than fully delegating judgment to AI.

Productivity Explosion: Agent Pipeline Based on Honest Engineering

From "Chat-style" to "Pipeline-style"

The early approach to implementing cards was telling AI what to do via chat, then manually testing and verifying. While faster than traditional programming, efficiency was still limited.

The turning point came from an article about Honest Engineering. Based on this specification, the developer built a card production Agent, and productivity completely exploded—over 80 cards were implemented in two days, running 6 windows in parallel.

About Honest Engineering: Honest Engineering is a software engineering specification designed for LLM collaboration. Its core philosophy is "letting AI know what it doesn't know." Traditional Prompt Engineering tends to push AI to directly provide answers, while Honest Engineering emphasizes inserting explicit clarification, auditing, and planning phases before execution—forcing AI to expose uncertainty rather than filling gaps with hallucinations. This specification borrows from "requirements freezing" and "test-driven development" concepts in software engineering, adapting them to LLM's probabilistic output characteristics, thereby constraining AI's randomness within controllable process nodes.

The Four-Phase Agent Workflow

Phase 1: Semantic Clarification

• Input raw card information (scraped from database websites)
• AI interprets card descriptions using a terminology glossary
• AI proactively asks questions about anything unclear
• Human confirms and freezes the understanding

Phase 2: Infrastructure Audit

• Review existing capabilities in the current framework
• Determine whether infrastructure additions are needed
• If additions are needed, human reviews the proposed approach for reasonableness

Phase 3: Plan Generation and Execution

• Generate an implementation plan based on information from the first two phases
• Execute code writing directly in the main session

Phase 4: Automated Verification

• Read the spec file from the semantic clarification phase
• Generate test cases and execute them
• Loop through fixes based on test results
• Continue until all tests pass

Core Design Principles

1. Don't assume the LLM is stable: Design stable production processes that use workflow to constrain AI's instability
2. Structured context: Use documents to pass information; all phases share a Plan document
3. Agent specialization: Small Agents are more stable than large ones—one Agent does one thing
4. Persistent memory: Each card's spec file and test cases are the first entry point for debugging
5. Separate thinking from execution: The first two phases collect information; the third phase focuses purely on execution—don't interrupt mid-stream

The "Agent specialization" principle corresponds to the AI version of the "Single Responsibility Principle" in engineering. An LLM's context window is a finite resource. When one Agent simultaneously handles requirement understanding, solution design, code generation, and test verification, the reasoning objectives of different roles interfere with each other, degrading output quality. Splitting responsibilities across multiple specialized Agents essentially trades architectural design for focus and accuracy at each reasoning step.

Major Pitfalls: Real Lessons from AI Programming

Visual Editors Are a False Need in the AI Era

The developer spent half a day building a visual editor for the card Inspector panel, which later proved to be completely wasted effort. A single card definition panel is extremely long—manually filling it in requires intimate familiarity with the card data model and is extremely error-prone. In the AI era, all such data definition work should be handed to AI, which is orders of magnitude faster than manual entry.

This lesson reveals a deeper paradigm shift: traditional tool design centers on "reducing human operational cost"—visual editors, drag-and-drop interfaces, and form fills are all products of this goal. But in AI-assisted development, the entity performing data entry shifts from humans to LLMs, and LLMs process structured text (JSON, YAML, code) far more efficiently than GUI interactions. This means many "human-friendly" tools actually become efficiency bottlenecks in the AI era.

Performance Disasters from High-Frequency Triggers

The combination of the Weightlifting + Treant deck produced a "bootstrapping