2026-06-01 Retrospective
What I Did Today
Today I ran a Godot project directly to check the map generation results, and in the process I retested how well AI coding tools keep up with actual game development tasks.
I also customized a web‑research MCP in my private repository. Instead of using the default web-search-mcp as‑is, I tried to tailor it to the search flow and output I wanted. When dealing with constantly changing information like design, Godot, and up‑to‑date documentation, I felt a search tool is almost essential.
Tools Tested
I tested Qwen Code, Codex, and OpenCode.
To put the conclusion first, none of them were as reliable as I expected. Qwen Code gave repetitive answers far too often. The same plan was created, the same file was searched for, and the failed path was trusted again in a looping manner. Unless you set it up and tune it according to the documentation, this repetition problem doesn’t seem to improve easily no matter which model you attach.
Codex and OpenCode were better than Qwen Code in terms of tool invocation, but they either failed to deeply understand the Godot work context or mishandled image interpretation. Answers were cut off midway, they made their own plans but couldn’t finalize them properly, and there were odd flows where a sub‑agent was summoned to “research” while actually just querying the filesystem.
When it wasn’t Qwen Code, the web-search MCP integration felt broken, which was frustrating. Conversely, even with Qwen Code, the repetition and state‑interpretation issues remained.
Model Experiments
Other models tended to suggest code patterns from older Godot versions rather than the latest, so I tried using the Hugging Face model bekoozkan/godot-gemma-4-e4b-it-GGUF in search of a model closer to a Godot‑specific one.
I hoped it would know a bit more about Godot, but the limitations were significant. The model’s parameters were too small, and it struggled with long contexts.
Especially in tasks where image verification is crucial, the frustration was high. You need to look at the actual screen to decide whether the map looks odd or where something feels off, but the models couldn’t reliably interpret images. In game development, it’s not enough for the code to be correct; the visual output must also look natural, and AI tools faltered heavily in this area.
Problems Noted in Godot Work
Godot turned out to be a domain the models knew less about than expected. Latest syntax, scene hierarchy, editor behavior, resource paths, and runtime verification are all interconnected, yet many models answered based on outdated knowledge after seeing only a code snippet.
The actual work I did today boiled down to running Godot and confirming that the map looked strange. However, around that I kept fiddling with tool settings, MCP connections, model swaps, sandbox issues, and image‑interpretation problems. The time spent wrestling with tools was longer than the time spent on the game itself.
Remaining Feelings
Honestly, I got the impression that this field doesn’t suit me well.
I expected development to become easier if I assembled AI tools properly, but in reality I kept encountering tools losing their state, looping, mis‑finding files, failing to see images, and only suggesting outdated code. What I want to create is a game, yet I spent most of the time debugging the tools’ limitations.
Still, I gained some insights. Web‑research MCP is necessary, Qwen Code must be strongly tuned according to the documentation, and Godot work must always be validated with actual runtime screens. Rather than handing over both planning and execution to an LLM, it’s more realistic to have a person or script manage the verification loop while the LLM provides drafts and auxiliary judgments.
Starting tomorrow, I think I’ll have to fine‑tune myself. Using a generic model or a publicly available Godot‑specialized model as‑is didn’t follow the Godot version, workflow, or screen‑validation flow I need. I’ll need to collect the required examples and failure cases and build a dataset that matches my workflow.
Criteria for Future Entries
- Godot work is not considered complete without verifying the runtime screen.
- Tasks that require image‑based judgment should not rely solely on model answers.
- Starting tomorrow, I will gather Godot work patterns and failure cases to prepare for direct fine‑tuning.
- Use Qwen Code only after completing repetition‑prevention settings and MCP configuration.
- Assume Codex and OpenCode have weak Godot context understanding and image interpretation.
- If a model can’t formulate a plan and only repeats tool calls, stop immediately.
- Web research remains necessary, but linking search results to code work requires separate verification.