GameCodeGolem & GameDevFoundry — AI Tooling for Unreal Engine 5

The Problem

AI coding agents fail on Unreal codebases in predictable ways. They recall an API that was renamed two engine versions ago. They read half of a Blueprint graph and report it as the whole graph. They forget between sessions why the code is shaped the way it is, then undo the reason.

Two tools came out of attacking those failures. GameCodeGolem is the R&D framework, proven in daily use. GameDevFoundry is the product being distilled from it, two weeks old.

My Role

Direction and verification on both. I set the requirements, the design constraints and the standard each tool has to meet, and I designed the trial procedure that judges them. My own AI pipeline produces the implementation. I don’t write the code.

GameCodeGolem — The R&D Framework

GameCodeGolem runs as a local server that an agent connects to. It is where I worked out what an agent needs in order to write Unreal C++ reliably, and it exists to stop the failures above.

• Grounding

  Looks up real engine signatures

  Agents check functions against the actual engine install instead of recalling an API that may have been renamed since the model was trained.

• Memory

  Remembers why the code is the way it is

  Per-system notes on the reasons behind the code, so a later session doesn't undo a deliberate decision. This is what stops the same bug coming back two weeks later.

• Guard rails

  Editor access through a governed gateway

  Changes to the project go through ownership, sandboxing and rollback rules instead of straight at the editor.

• Proof of use

  In production on a real game

  Four server-authoritative multiplayer slices on ProjectOmega, each accepted only after a packaged host-plus-client run. The framework has held up over months of daily use.

GameDevFoundry — The Product, In Progress

GameCodeGolem was research, and it has the shape of research. It grew as scattered pieces across many sessions, got a direction document only two months in, and revised that direction repeatedly as the work found what mattered: the engine grounding, the evidence rules, the project memory. It also accumulated what research accumulates: stub tools, mined sample knowledge that can’t be shipped, and rules specific to one project and one machine. Turning that into a product in place would have meant carrying all of it.

GameDevFoundry started clean, with an inventory of GameCodeGolem as its first document: what each part does, what it depends on, and whether it fits the offer. It is early: three slices implemented since October 2026, most of the rest still design, enough to run real trials. GameCodeGolem stays in production alongside it.

What exists has been tested rather than demoed. I pointed it at a real bug on a game project I’ve been the programmer on for years, on a branch being moved to a newer engine version. A fresh agent session got the symptom and nothing else. A separate session scored the run against an answer key written and sealed before the run started.

Independent judge · sealed answer key

Two runs on the same bug. A separate session scored each one against an answer key it wrote and sealed before the runs, and that the agent never saw.

Run 1 Run 2

Setup

Did the tools come up clean on an unfamiliar project?

Run 1: pass Run 2: pass

Diagnosis

Did it find the cause?

Run 1: hit Run 2: hit

Evidence

Does every claim trace back to something it actually read?

Run 1: weak pass Run 2: fail

Fix

Did the proposed fix remove the symptom?

Run 1: pass Run 2: pass

No change

Did it leave the project untouched?

Run 1: pass Run 2: pass

Run 1 — 10 min 7 s · $2.86

Run 2 — 7 min 24 s · $2.22

The agent traced the fault to a Blueprint compiler behaviour that changed between engine versions, confirmed it in the engine’s own source, and proposed a fix that held. That is an engine regression two versions apart, found from a symptom, on a project the agent had never opened.

The second run scored worse than the first on evidence quality, and the judge listed more things a single run cannot show than things it did show. Both runs are published as scored.

What I Took From It

• The core idea

  An empty result is never "it doesn't exist"

  A search that found nothing only covers what it searched. Making that distinction structural, instead of leaving it to the agent's good manners, removed a whole category of confident wrong answers.

• What generalises

  In hindsight, the lab was the prototype

  GameCodeGolem wasn't built as a demo for anything. The product idea came out of it, and so did its grounding, its evidence rules and its honest negatives. Its shape stayed behind.

• Measuring honestly

  A benchmark the tool can lose

  The comparison against a studio's existing options is designed and pre-registered, including cases where this tooling should be no help at all. It has not been run yet.

• Stated limits

  One engine build, one platform, and I say so

  GameDevFoundry is tested on a single UE 5.8 install on Windows. The pipeline states its own boundaries, which costs less than having someone else find them.

Tools & Tech

Python, Model Context Protocol, Unreal Engine 5.8, Epic’s editor MCP plugin, UnrealHeaderTool reflection data, Claude Code. Both developed through VibeSlice.