A cluster of recent devlogs from Japanese indie developers offers a useful snapshot of what game development looks like when AI writes most of the code, and where the human still has to step in. Three of the posts come from a solo developer building a 3D game for Steam (who also runs a calculator toolkit called ShibaHub and a grant-search site called 補助金ナビ) and read like a debugging diary. Two more come from separate Godot projects: one benchmarking AI coding agents on implementation tasks, and another documenting concrete systems for evaluating AI-generated pixel art and polishing combat feel.
Bug #1: The setting that saved correctly but did nothing
The first war story involves a jump animation whose playback start position simply refused to change. No errors, no warnings, and the new value was confirmed saved — yet the screen didn’t move a pixel. The root cause turned out to be a classic Godot gotcha: certain animation properties only take effect once a separate, unrelated toggle is switched on first. If that prerequisite flag stays off, the engine silently ignores your change instead of complaining. This is exactly the kind of implicit ordering dependency that trips up AI coding assistants, since the two settings aren’t obviously linked in the API surface — an AI (or a human skimming docs) has no strong signal that setting B is a precondition for setting A to matter.
Bug #2: A test that lied about timing
The second post describes a test that claimed a network callback “never arrived within 10 seconds,” even though the actual game logic worked fine at runtime. The culprit was how a lambda captured a variable — a subtle closure-capture mismatch where the callback ended up watching a stale or wrong reference rather than the one actually being updated. This bug class is common in async testing across languages (C#, GDScript, JavaScript alike): a loop or callback variable gets captured by reference, and by the time the lambda fires, the value it sees isn’t the one the test author intended. The fix is usually a local copy of the variable at capture time, but finding it means distrusting the test’s error message and tracing what the closure actually holds.
Bug #3: Logs said “connected,” the feature said otherwise
The third case happened while migrating networking code onto Steam’s SDK. Initialization logged success, and every diagnostic line looked healthy — yet a downstream feature simply didn’t function, costing about three hours of investigation. The lesson here is one every backend-integration developer eventually learns: a “success” log only proves that the code path that logs success executed, not that every dependent subsystem wired up correctly. When migrating a service layer (in this case swapping a homegrown networking stack for Steamworks), stale references or partially-migrated call sites can coexist with clean logs from the parts that did get updated.
Taken together, these three stories point to the same meta-lesson: AI-assisted development doesn’t eliminate debugging, it changes its shape. The bugs aren’t typos or obviously wrong logic — they’re invisible dependencies, capture semantics, and trust in logging output that all pass a first-glance review. When you (or your AI pair) didn’t write every line by hand, you’re more likely to defer to “it saved,” “the test result,” or “the log line,” and less likely to have the mental model needed to question them.
Benchmarking AI as an implementation contractor
A separate Zenn post takes this a step further by systematically benchmarking an AI coding model called Ox Alpha as a “sub-contractor” for implementing mini-games, with a fixed high-tier parent agent (Claude Opus) supervising and a child agent doing the actual coding at different effort levels. This kind of benchmark matters for the tooling ecosystem taking shape around AI-driven game dev: as more studios and solo devs treat LLMs as implementation labor rather than autocomplete, understanding how “effort” settings trade off cost, speed, and code correctness becomes a practical procurement question, not just a curiosity.
Comparing AI art in context, not in isolation
On the art side, a devlog for the project Nocturne Vania tackles a problem anyone using AI-generated sprites will recognize: a pixel character that looks great in the generation UI can disappear into the background once it’s actually running in-engine, because silhouette, scale, and animation speed all read differently at real camera zoom next to real enemies. Their solution is refreshingly simple — keep multiple candidate skins as separate definitions and let a debug hotkey (F8) cycle between them live in Godot, so comparisons happen in actual gameplay context rather than a static image grid.
Making hits feel like hits
Finally, a companion post from the same project breaks down their approach to combat feel: hit-stop, screen shake, knockback, slash effects, and per-combo forward movement are all tuned together rather than relying on one big flashy effect. Critically, all of these tunable numbers live in one central constants file, which is less about game feel theory and more about workflow — centralizing values makes rapid iteration and A/B tuning by feel dramatically easier, whether the code around them was written by a human or an AI collaborator.
The throughline across all five posts is that AI can now write a large share of a game’s implementation, but the surrounding craft — validating engine assumptions, designing test infrastructure that doesn’t lie, evaluating assets in real context, and centralizing tunables for fast iteration — is still squarely the developer’s job.