I Had an AI Independently Develop a Game: Zero Dependencies, 188 Tests All Green, Schedule Compressed to a Quarter

Competition statement: This article participates in Juejin's “1024 · New Rice Bowl Plan” Track 2 · Work Submission; the submitted work is “Entropy Rangers” (topic: #1024 AI Era Programmers' New Rice Bowl#).

Online experience: https://entropy-rangers.yangchina.cn (open and play; pure static, no backend)

Open source repository: https://atomgit.com/dickeryang/entropy-rangers (Apache-2.0)

Summary: I used an AI coding agent to independently develop a zero-runtime-dependency Canvas tower defense game, “Entropy Rangers,” with 188 tests all green; one full playthrough is a regression test case. This article explains the real need it solves, the current state of open source and online operation, and the monetization expectations of the open source + WeChat public account + tipping combination.

Keywords: AI programming, vibe coding, Canvas, TypeScript, mini game, open source, monetization, 1024

Tech stack version: Huawei Cloud CodeArts Code Agent (2026-09 version) | TypeScript strict (zero npm dependencies at runtime) | Canvas 2D | self-built ECS | Vitest deterministic replay regression | measured time 2026-09 ~ 2026-10

Foreword: My Plan B Is to Build Works, Not Change Careers

On October 21, Juejin launched the “New Rice Bowl Plan.” I have thought seriously about where programmers' new rice bowl lies in the AI era. During the day I write code at the company. My answer is not betting on “switching industries,” but on a more concrete action: use AI to build a complete engineering work, open source it, put it online, and hang it under my personal brand.

Over the past month I really did this: I let the CodeArts coding agent from Huawei Cloud independently develop a pure-browser strategy mini-game, “Entropy Rangers.” All the code was generated by AI; I was responsible for defining the architecture, setting acceptance criteria, and tuning balance. Development plus parameter tuning took about 21.5 hours. Based on experience, handwriting it would have taken about 10 days, compressing the schedule to about one quarter. The finished product has zero runtime dependencies, is about 29KB after gzip, and has 188 tests all green. It is open sourced on AtomGit and deployed online.

This article is a complete retrospective of this “building a rice bowl” process: what the work is, what real need it solves, how it is operating now, and what monetization expectations it can bring. All numbers are measured values, and the repository state is reported honestly. It just went online, and it still has only 1 star. I do not intend to fabricate a pretty operations story.

1. The Work Itself: Deployment Changes the Flow Field, One Match Is One Test Case

“Entropy Rangers” is a tower-defense real-time strategy game: deploy daemon processes on a grid-shaped data center to resist the erosion of the entropy tide (erroneous data streams) against core services. The core strategy can be stated in one sentence: deployment changes the flow field, and the flow field decides the battle. Every firewall you place rewrites the enemies' pathfinding flow field in real time, and the route changes are directly visible on screen.

Feature list:

Module	Function
Gameplay	4 types of daemon processes × 4 types of entropy tides × 8 levels (including a tutorial level); deployment rewrites the BFS flow field
Win expectation	Real-time evaluation of the chance to hold, based on “defensive effective output × path coverage vs remaining threat”
Replay system	Command stream + seed fully replays any match; on failure, jump to a battlefield snapshot at the moment of breach
Local save	localStorage stores level progress and best integrity; the only storage, no network requests

Selecting a daemon enters deployment mode; hovering highlights valid cells and previews the range ring; the moment a firewall is deployed, the entropy tide's walking route is entirely rewritten:

Holding gives a settlement; failing also has an explanation. On failure, the “defense line breach timeline” appears automatically, marking the first hit, integrity falling below 50%, and the final state. Click to jump back to that moment and review defense placement:

2. The Real Need It Solves: Not “Another Demo,” but Three Concrete Things

Track 2 asks for a clear statement of the real need the work solves. This game's need has three layers, each more practical than the last.

First layer: it is first a game that can be fully played through. 8 levels have a difficulty curve, saves, and failure review. It is not a generative demo where logic is smeared into the render loop and refreshing starts over. Games are the category with the largest engineering gap: most one-shot AI-generated game code is full of magic numbers and untestable, so I deliberately chose it as a touchstone.

Second layer: it verifies a specific question: where is the upper limit of what an AI coding agent can deliver as a “complete engineering project”? What I gave it was not “write me a game,” but acceptable engineering constraints: the pure logic layer is forbidden from touching the DOM, four determinism disciplines, staged coverage thresholds, and 10 CI gates. The final deliverable passed all acceptance criteria. That fact is more informative than whether the game is fun: what AI lacks is never the ability to write code, but the discipline of being accepted; and discipline can be defined by humans.

Third layer: it produced a reusable methodology: “replay as test.” Because the simulation is deterministic, a whole match (command stream + seed) is one regression test case. Three standard matches (win/lose/close win) are pre-recorded into CI; any change that breaks determinism or balance immediately turns red. “The game can run completely” changes from a verbal promise to a machine assertion. This approach can be moved to any deterministic simulation scenario: strategy validation, physics simulation, financial backtesting.

3. Three Engineering Decisions Behind “Work Quality”

This section does not lay out the full architecture (that would be another long article); it only covers three decisions that directly support the “completeness” evaluation, each with trade-offs.

3.1 Decision 1: ECS + Complete Separation of Logic and Rendering

The intuitive approach is one class per tower/enemy holding references to each other, but tower-defense entity relationships are networked, and a class web becomes an untestable mud ball. I used ECS: entities are IDs, behavior lives in Systems, data lives in Components, and I set a hard discipline: the sim layer must not import the render layer or any DOM API. This directly bought one capability: the same simulation can run headlessly, which is why replay testing works.

3.2 Decision 2: Fixed-Step Simulation + Four Disciplines of Determinism

[Why I did not use the intuitive “advance one step per rAF frame” approach] On a 144Hz screen the game runs 2.4x faster, and after switching back from the background it teleports. On the other hand, variable-step based on dt accumulates floating-point error that makes replays never match. Therefore the simulation runs at a constant 1/60s step, while rendering is variable and interpolated:

// src/engine/loop.ts (excerpt) — pure logic part, unit-testable
export const FIXED_DT_MS = 1000 / 60;

/**
 * Simulation has a constant 1/60s step; rendering interpolates state per frame using alpha;
 * returning from the background catches up at most 10 steps, and anything beyond is dropped as fast-forward (explicit architecture decision).
 * [Determinism discipline] The sim layer is forbidden from reading the clock. performance.now is only allowed in one place: the rAF shell.
 */
export function planTick(accumulatorMs: number, maxCatchupSteps = 10): LoopTick {
  const raw = Math.floor(accumulatorMs / FIXED_DT_MS);
  const simSteps = Math.min(raw, maxCatchupSteps);
  const catchingUp = raw > maxCatchupSteps;
  const consumed = catchingUp ? 0 : raw * FIXED_DT_MS; // fast-forward clears backlog
  return {
    simSteps,
    catchingUp,
    interpolationAlpha: (accumulatorMs - consumed) / FIXED_DT_MS,
  };
}

Determinism does not rely on self-discipline; it relies on four disciplines plus machine enforcement: randomness always goes through an injected Rng (a custom ESLint rule forbids Math.random in the sim layer), system execution order is fixed, the simulation layer is forbidden from reading the clock, and resources and damage are settled entirely in integers.

3.3 Decision 3: Replay as Test — Turning “Playable” into an Assertion

Manually play a match, export a replay JSON (command stream + seed + numeric table hash), replay headlessly, and compare bit-for-bit against the baseline. In the repository, this mechanism takes the form of one test command:

$ npx vitest run src/replay

✓ replay regression (anti-degradation) (3)
  ✓ standard-win: outcome=victory, stateHash=581952af
  ✓ standard-lose: outcome=defeat, stateHash=3f42ed1c
  ✓ standard-close: outcome=victory, stateHash=604d2feb
✓ replay determinism (3)
  ✓ playing the same ReplayData twice produces the same stateHash
  ✓ injecting out-of-order commands (reversed ticks) produces the same result as sequential playback
✓ balanceHash validation (3)
  ✓ balanceHash mismatch → throws BalanceMismatchError

Tests  18 passed (18)

This output is three things at once: a regression test (turns red when broken), a machine proof that the game runs completely, and a bug reproduction protocol (a player only needs to attach the command stream for exact reproduction).

4. Current Operation: Just Launched, but the Base Is Engineered

Honest report first: the repository was created on 2026-09-17, and the final iteration was completed and released on 2026-10-11. It is now an early work just past one month old. The public AtomGit repo currently has 1 star, 0 forks, 0 issues. The numbers are small, but every one is real.

Both open source and online touchpoints work:

• Play online: https://entropy-rangers.yangchina.cn — pure static deployment, no backend, no database, no telemetry, open and play;
• Read the code: https://atomgit.com/dickeryang/entropy-rangers — Apache-2.0, 22 commits fully traceable, and the repo homepage directly links the experience URL.

Although user data is still in its early days, the engineering quality data is full, and that is where my confidence in “work completeness” comes from:

Metric	Measured value
Tests	188 cases all green (engine 27 / sim 99 / replay 18)
Coverage	sim 87.12% / replay 82.51% / engine 79.53% (core logic layer scope)
Deterministic regression	3 standard replay baselines, final-state hash compared bit-for-bit
Performance baseline	3000-step headless match simulation 20.46ms
Artifact size	about 29KB after gzip, static files
Runtime dependencies	0 npm packages (enforced by CI gate)
Quality gates	npm run ci has 10 gates; local and CI are exactly the same

Among the 10 gates in npm run ci, I value two most: one guards the “zero-dependency invariant” (anyone who adds a package to dependencies turns red, protecting the “zero dependency” selling point), and one guards determinism (any Math.random or clock read in the sim layer is blocked). Operating an open source work is the same as operating a service: it relies not on enthusiasm, but on making “becoming broken” expose itself automatically.

5. Monetization Experience and Expectations: Honest Disclosure

Track 2 also asks for monetization experience or expected results. In this section I will tell the truth.

Current direct income: 0 yuan. Entropy Rangers has no ads, no in-app purchases, and no paid version planned. The README says, “If it adds a little fun to one of your afternoons, you are welcome to buy me a coffee.” Since launch, tipping income has been zero. I fully accept this result, because from the start, this work's monetization path was never “sell the game.”

My monetization model is a three-layer funnel. The work is the entry point, not the commodity:

1. Work layer (build trust): an open source work with complete engineering gates and online verification is physical evidence that “in the AI era, I still have engineering ability.” It is more credible than any line on a resume;
2. Content layer (traffic conversion): produce a series of technical articles around the work (this article is one of them). Articles bring reads and followers, settled into my WeChat public account “行者架构谈” (Xingzhe Architecture Talk); participating in the event is itself a traffic event;
3. Opportunity layer (indirect monetization): the combination of work and content points to “new rice bowl” opportunities such as AI-collaborative development consulting, freelance work, and enterprise training. The tipping QR code is there more as a gesture: my output deserves a cup of coffee, but what I really want to build is trust.

WeChat tipping: buy the author a coffee

I will also state the boundary of expected results clearly: tipping and traffic are long-term investments in a personal brand, and no revenue curve is visible in the short term. What can truly scale in this funnel is the methodology of “using AI to complete a full engineering project” itself, which is being validated through the article series. If this article is lucky enough to enter the event's judging, Juejin's 50,000 ore participation prize would be the first “platform monetization” for this work, and I will update this article.

6. Pitfalls: AI Wrote 90% Correctly; the Remaining 10% Relies on Humans

A full record of real problems during development, each with the fix process.

1. One Line of Floating-Point Multiplication Made Replay Turn Red for the First Time

Symptom: when replay regression was first integrated, the final stateHash of the same standard match differed between two replays. Determinism was truly broken. Root cause: the economy system's sell-back was written as credits * 0.7; floating-point multiplication took different rounding paths in two runs, and the integer settlement discipline was broken by one line of code. Fix: change it to (credits * 7) / 10 integer arithmetic (multiply first, then divide), and add an ESLint rule forbidding floating-point operations on money-like variables in the sim layer. Replay turned green. Reflection: this pitfall proves the sensitivity of replay testing. A single floating-point line was caught by the hash. Determinism is not designed; it is measured.

2. AI Will “Casually” Break Constraints You Are Not Watching

Symptom: an AI-generated splitter enemy used Math.random for death splitting, and another system used Date.now() for timing statistics. Both ran, and no version difference was visible to the naked eye, but the replay immediately drifted. Root cause: AI will not proactively maintain global constraints you do not repeatedly emphasize. “Just one random number” is completely reasonable from its local perspective. Fix: solidify a repair rule: tests may not pass by deleting determinism assertions. The only fix direction is to route randomness through the injected Rng and time through injected sources; after the fix, replay regression must be fully green. Then write the bans into custom ESLint rules, backed by CI. Reflection: AI's output quality equals “how acceptable you made the constraints.” That sentence was repeatedly validated over this month.

3. Coming Back from the Background “Fast-Forwards the Videotape”

Symptom: after switching away from the tab for a few minutes and switching back, enemy positions instantly jumped to the “future.” Root cause: requestAnimationFrame stops when the page is invisible; when it resumes, thousands of milliseconds of delta have accumulated. The catch-up cap design in planTick was correct, but the rAF shell did not connect it. A defense in the pure logic layer is worthless if the thin shell layer does not use it. Fix: catch-up limit of 10 steps + fast-forward drops the backlog; clear the accumulator once on resume. Acceptance now requires walking through across layers. Reflection: all unit tests green does not mean correct functionality. The boundary between “testable pure functions” and “untestable thin shells” is a bug-prone zone.

7. Efficiency Data: 21.5 Hours to Finish What Was Estimated at 10 Days

Measured time based on development logs (single-person single-project sample, for reference only):

Development stage	Estimated pure hand-writing	Actual AI-assisted	Source of efficiency
ECS kernel + dual loops + unit tests	about 2 days	about 3 hours	cleanly structured pure logic is AI's strongest area
Grid flow field + minimal playable loop	about 2.5 days	about 4.5 hours	algorithms + exhaustive edge cases, high one-pass review rate
Replay system + all units	about 2 days	about 4 hours	data-driven design makes implementation a translation
Canvas rendering + deployment interaction	about 2 days	about 5 hours	AI writes structure, feel tuning depends on humans
Level tuning + review + wrap-up	about 1.5 days	about 5 hours	replay tools make tuning verifiable
Total	about 10 days	about 21.5 hours	schedule is about one quarter of the traditional approach

Two honest notes: the pure hand-writing estimate is based on experience and has subjective error; numeric balance time was not saved. The “replay verification, manual fine-tuning” loop ran three rounds to reach the desired feel. This part is unique to game genres and is time AI cannot replace.

8. Summary: The Answer to the New Rice Bowl Is “Works”

Back to the event's question: where is the programmer's new rice bowl in the AI era? My answer is: AI takes over typing; it cannot take over defining the problem, setting acceptance standards, and owning the result. In this practice, my role changed from “the person who writes code” to “the person who sets discipline”: define architecture, write acceptance criteria, tune balance; AI did 90% of the implementation. A quarter of the schedule, 188 tests all green, zero-dependency open source release, that is the measured result of this division of labor.

Links again, welcome to try it and read the code:

• Online experience: https://entropy-rangers.yangchina.cn (open and play)
• Open source repository: https://atomgit.com/dickeryang/entropy-rangers (Apache-2.0, includes replay baselines and 10 CI gates)

Discussion

Are you also using AI to make complete engineering works? Three questions I want to hear from Juejin readers:

1. What is the most “complete” work you have made with AI, and where did you get stuck?
2. For monetizing AI works, do you think selling the work, selling content, or selling capability is more reliable?
3. If you let AI independently develop a game, how would you define the acceptance criteria for “playable”?

Leave a comment; I will reply to every one seriously.

If you found it useful, like and bookmark it. Next article preview: “Replay as Test: Move Deterministic Simulation Engineering Methods into Your Business System.” Follow if interested.