Weekly Review W52

published: December 31, 2025 estimate: 5 min read view-cnt: 11 views

Time flies like a rocket every time I try to post some weekly review.

After two weeks of struggling, I finally vibe-coded a playable VIMkeys game.

The result was mediocre, but playable.

I reworked the project 4 times thanks to the agentic tool.

The goal was not to make a feature-rich game; instead, I was trying to figure out the most effective workflow.

Here’s what I learned from these 4 iterations

First Round

The Approach I Used:

Agentic AI Tool: Claude Code
Implement the game with a specific tech-stack (i.e. ASP.NET Blazor Web Assembly)
Implement features in separate stages
Dictating most of the visual design
Refactor the code manually or via prompting LLM with DDD or SOLID

The result was a slow development cycle (it took me a week to accomplish very little)

Repo: https://github.com/johntao/vimkeys-game

Game: https://blue-smoke-09d2e5200.3.azurestaticapps.net/

Second Round

Based on the previous experience, I changed from DDD to SDD.
You can refer to a complete introduction of why and how I made the change in the previous article.

The Approach I Used:

prev: Implement the game with a specific tech-stack (i.e. ASP.NET Blazor Web Assembly)
- cur: Implement the game without using any tech-stack (i.e. plain HTML/CSS/JS)
Implement features in separate stages
- cur: Generate spec files from design docs (spec files includes pseudo code)
- cur: Let LLM generate code implementation based on spec files and design docs
prev: Dictating most of the visual design
- cur: Let the model decide the visual design
prev: Refactor the code manually or via prompting LLM with DDD or SOLID
- cur: Stop refactoring. Make it work as the first principle

The development cycle improved, but was still slow (also took me a week to reach the bottleneck)

Repo: https://github.com/johntao/design-docs/tree/feat/v1-stage3

The token consumption was so high that I hit the daily limit easily, so I decided to start from scratch again

Third Round

Based on the previous experience, I stopped generating spec documents and instead prompted the LLM to implement code from design docs directly

I also split design documents into multiple files to make it more manageable.

The caveat is that interdisciplinary features get duplicated across different files. (duplication in exchange for better scaling)

I also fine-tuned the abstraction of different game modes.

Features are now listed (as game mode agnostic) in the top of the file, then, game mode specific implementations are listed in the bottom of the file.
The reason is that in the previous version I wrote “xxx features are excluded from yyy mode” which is an obvious violation of the Liskov Substitution Principle

The Approach I Used:

prev: Implement features in separate stages
- cur: Implement features in one shot
- cur: Prompt LLM for multiple code commits without asking for manual validation in-between

The development cycle improved, but was still slow (took me three days to reach the bottleneck)

Repo: https://github.com/johntao/design-docs/tree/feat/design-v2

The token consumption was still high—splitting the game into 4 different game modes was too expensive—so I restarted from scratch again

Extra note:

the prefix number on the markdown headings doesn’t seem to be useful
it is time-consuming to maintain the correctness, so I made a script to automate the numbers
however, it is useful only when users or readers start referring to them
since that rarely happens, I would probably abandon this method in the future

Fourth Round (The Final)

Based on the previous experience, I picked one specific interesting game mode (i.e. snake mode).

I polished the gameplay design, got rid of other modes, and removed dropped features and design notes (this information doesn’t help with implementing features, and it consumes tokens)

This round, without all the noise, I finally managed to implement 90% of the features. And then, new problems emerged.

The game is not fun to play at all. There’s something weird about the core game loop.

It is obvious that some of the features didn’t fit well together.

Symptoms included:

weird game loop (i.e. failed to deliver fast-paced gameplay allowing players to smash their keyboards)
unresolvable bugs (edge cases creep in fast when too many features are put together)
the game also sucks in the simplest case

Once I realized the problem, I started testing the gameplay from the simplest case

Then, I dropped the biggest feature and introduced a new feature to complete the game loop (i.e. coins to prolong the timer)

The gameplay looks decent now

The Approach I Used:

working on the core game loop from the simplest case
remove features that conflict with other features

The development cycle improved (took me four days to complete a shippable POC—not all features from the design docs, but enough to ship)

Repo: https://github.com/johntao/design-docs/tree/master

Extra note:

it is obvious that configurable gameplay was not a good idea
the feature is only useful when the entire gameplay is mature

Verdict

There is still much work left to do in the future. The obvious one is to publish it.

And tons of features in my notes and my head:

3 more game modes (filler, picker, score booster)
multiple grids/ views render
pattern-match gameplay
tetris gameplay
puzzle mode

The most valuable lesson learned is to get rid of the noise.

Notable noises:

DDD, SOLID, DRY-anything about code quality or refactoring
tech stack, visual design
separation of spec and design docs
numeric prefix in docs
multiple game modes
demo levels
configurable gameplay

These are the noises distracting me from completing the game, and I think these problems are quite simple to solve once identified.

However, fine-tuning the game loop is still difficult for me. It is indeed craftsmanship (not to mention I haven’t put any efforts into audio and visual design yet!)

Another takeaway is that once the design document is good enough (probably 3 out of 5), it is worth trying to one-shot the implementation via LLM tools.

The goal is to have the actual gameplay ASAP, then, the designer can have a chance to know what’s good and what not.

Hope you learned a thing or two from this article. Wishing you all a happy new year! 🎇🎇