AI workflows and agent harnesses
Coding agents are only as good as what surrounds them. I build that surrounding: the instructions, skills, checks and guardrails that let an agent work on a large codebase and hand back changes a reviewer can trust.
- Where
- Gamebasics and Hydro
- Agents
- Claude Code, Qwen Code
- Models
- Claude, local Qwen on Ollama
- Tools
- Python, Bash, GitHub Actions
Why a harness
An agent dropped into a big repository guesses: at the conventions, at where things live, at whether its change builds. A harness replaces those guesses with things it can read and run. The result is smaller diffs, fewer review rounds, and agents that can do real engine and gameplay work rather than only boilerplate.
The pieces, as built for Hydro
Project instructions
A short CLAUDE.md that tells the agent how to find things cheaply (a one-line-per-file code map first, then only the doc section it needs), the rules most often broken, the test scenes where new systems must show up, and how to check, build, package and read CI from a cloud session.
An architecture skill
The hydro-engine-architecture skill: subsystem lifecycle and naming, resource creation, ECS and systems, renderer rules and game-script layout, with a checklist to run before finishing. The same text is shared between Claude and Qwen.
Checks the agent runs itself
- A conventions linter in Python for the engine's house rules (namespaces, no
!operator, braces, member naming, no cross-area includes in game scripts) - A project validator that checks scenes, prefabs and data files against the code
- A single
check.sh: g++ syntax check, glslang for shaders, the linter and the validator - Headless tests for the data definitions and their serializer
- GitHub Actions that build Debug and Release on Windows for every push, with a readable error summary the agent can fetch
Guardrails
- No commits or pushes without an explicit yes; multi-step work goes to a scratch branch for CI
- Edits go to the user's working copy, guarded by modification time, never only to a cloud clone
- Docs are the source of truth, mirrored to the wiki by script, and updated as part of the change
Local models
Not every task needs a frontier model. For Qwen Code running on a local Ollama model I wrote a slimmer harness sized for small context windows: a short conventions file loaded only for C++ files, and a hydro-quick-edit skill that defines exactly what counts as a small change and hands anything bigger to the full skill or to Claude.
The split is deliberate: small, contained edits run locally and for free; architecture work goes to the stronger model with the full skill.
At the studio
At Gamebasics I bring the same approach to the team's Unity codebases: an AI harness that gives agents the context, conventions and checks they need to work in shared frameworks and live games. That code is private, so I can describe the work but not link to it.
How I work with agents
- Write instructions as things to look up and run, not long essays the agent reads once
- Make every rule checkable by a script, and let CI enforce it, the same way our Jenkins and TeamCity pipelines guard every game at the studio
- Keep the agent's work small enough to review in one sitting
- Prove features in a real scene or game, not in a demo made for the change
Building a game, an engine, or the tools around them?
I'm based in Tokyo and open to conversations about Unity, C++ and engine roles, C# and .NET software roles, and teams that want to put AI agents to work on real codebases.