I'm thinking a 2d, minimalistic, roguelike, hex-grid-based tower defense game. code name: CENTRAL DEFENSE. I haven’t thought through the full design yet, just one core idea and a few basics mechanics.

for the stack, I tried few lightweight engines like Excalibur, hex-engine, and a handwritten one using miniflux+pixi. I settled on @kaplayjs for simplicity. I don't need a powerful engine with a fancy editor, I want to define everything via code which fits the vibing approach.

for the vibing part, I mostly use @GitHubCopilot since I've got the enterprise license (yes, even on my personal github account, thank you @Microsoft ). I use the local vscode/copilot combo plus the async copilot agent, which creates its own PRs from the issues I assigned.

in preparation, I dumped the docs/guides for the core libraries (kaplay for game engine, honeycomb for hex grid, etc.) into my codebase; maintain a simple http://tasks.md file plus instructions;

general workflow: - pick 1 major feature to work on locally, alongside the copilot - pick several other tasks, create issues and assign those to the copilot agent - rotate between PRs while waiting so yes, async vibing is a thing and context-switching is the new silver bullet.

and I know there are fancy workflows with task system, but I find those overwhelming. or maybe I just haven't found a good one (suggestions welcome).

model-wise, I mostly use sonnet 4, sometimes gpt-5. I don't have a full set of benchmark. for the async agent, there's no way to specify the model, I'd like to know that. I believe there's one initial step to determine which model to use.

the good about the async copilot agent: it often works, it can code and take screenshots.

now the bad about the async copilot agent #1: it's slow, ~15mins for one iteration. plus it burns github action minutes. 2000/3000 (on free/pro plan) isn't enough for a serious project. I rarely hit copilot requests limits, but I easily used up all 3000 action minutes.

the bad about the async copilot agent #2: when taking the screenshot, it struggles to follow instructions (e.g. first click this button to enter this stage), being a game with no DOM elements certainly doesn't help.

now the dev journal legend 👨🏻‍💻 - I did most of the work (vibing, refactoring, fixing, polishing) 🤖 - the agent did most of the work with some intervention

day 0-1 - bootstrapped the project day 2 - 👨🏻‍💻: a prototype with a grid, enemies spawning, a turret that rotates and shoots - 🤖: a second menu "stage" with basic ui buttons

day 3 🤖 grid background animation effect 🤖 a virtual joystick to control the rotation (this one impressed me) 👨🏻‍💻 general refactoring

day 4 🤖👨🏻‍💻 basic enemies spawning 🤖 a ray to show shooting direction 👨🏻‍💻 general refactors

day 5-6 👨🏻‍💻 better barrier slots rendering 🤖 turret shooting recoil effect 🤖 engine rotating sound effect 👨🏻‍💻 general improvements

day 7 🤖👨🏻‍💻 UI: hex as button 🤖👨🏻‍💻 UI: health bar with icon

day 8 🤖👨🏻‍💻 a debug scene to help me marking shape/area of graphic (thanks @KenneyNL for assets) 👨🏻‍💻 general fixes