How do you ship a 3D Unity mobile game with AI coding agents?

I am the CTO of GOGOGO LLC, and most of the code in GoTasty was written by AI coding agents (Claude Code) working in our repository, with me steering, reviewing and merging. The game is a low-poly 3D idle arcade in Unity 6: you start with one simit oven in Istanbul, carry stacks of food to the counter, hire apprentices and open new stalls. As of 8 November 2026 it has 167 playable locations in 33 countries. Here is the setup that makes that workable, including the parts that broke.

Why is CI the compiler?

There is no interactive Unity Editor session in our day-to-day loop. An agent cannot click around a scene view, and I did not want a workflow where the real state of the game lives in one person's open editor. So every change is a commit, and GitHub Actions builds it. Every push that touches Assets/, Packages/ or ProjectSettings/ produces an Android build, and an iOS build is one manual dispatch away.

That rule forces honesty. If the build is red, the change did not happen. A transient linker crash gets a re-run; anything else gets a fix commit. It also means nobody needs Unity installed to get a playable APK, which matters when one founder runs engineering and the other runs product.

The builds started on GitHub-hosted Linux runners with GameCI, moved to a larger 8-core runner when the growing city count made the store bundle run out of memory, and since 4 November 2026 run by default on a self-hosted Mac mini M4. A warm workspace there turned a 52-minute cold Android build into about 8 minutes. I wrote up that runner separately on ezagor.com.

How do you keep an AI agent from breaking a Unity scene?

Unity scenes and prefabs are large YAML files that merge badly and are close to impossible to review. We avoid hand-edited scenes completely: the game scene is generated by an editor script (PrototypeSceneBuilder) on every build. When an agent wants to move a counter or add a station, it changes the C# that builds the scene, and that change shows up in a normal diff.

Three more boundaries do most of the work:

• One place for numbers. Every tunable value (prices, timings, upgrade curves) lives in one EconomyConfig asset, and gameplay reads numbers only through GameManager. An agent tuning pacing touches one file, not twenty.
• One place for SDKs. Analytics, ads, consent and crash reporting are called only from Services/. Event names follow the design document and never change after launch, so a refactor cannot quietly break a funnel.
• One class per file, and the file name is the class name. Boring, but it keeps agent edits small and easy to review.

How do you build 167 locations without hand-building each one?

The first cities were hand-built in C#: stalls, station animations and props written per city. That does not scale, and every hand-built city also made the base app bigger. In late October we moved to a city kit. A city is now a JSON file with its products, five stalls, shop shells, colours, backdrop and strings in English, Turkish and Spanish. Shared archetypes (spit, grill, fryer, oven, pour, pot and others) build the stalls, and one interpreter animates them from a timeline in the data.

Agents are good at this kind of work when the format is strict. A validator checks the schema, the three languages, the product block and the income balance before a city reaches a build. 102 of the 167 locations are kit cities; the earlier hand-built ones stay as they were. Kit stalls are baked at build time and, in store builds, downloaded from our CDN the first time a player travels there, so the app does not grow with every city.

Who plays the build if the testers don't?

Early on we saw that testers install builds and rarely play them. So after every release candidate or gameplay change, agents run QA on the Android emulator. One agent plays the release build like a new player: it marks the device as a tester first, follows the tutorial and never taps a real ad. Another runs a development build with a built-in bot that plays like an attentive player and logs its pace every 15 seconds.

The bot is how we tune pacing without guessing. Pacing runs are deterministic (a fixed 1/30 s step and a seeded random), so two runs of the same build give the same numbers and a balance change shows up as a real difference. A tour script drives the camera through a list of cities and writes contact sheets of screenshots, which is how a person reviews ten new streets in a few minutes. On the emulator the agents are tightly scoped: always address one device with adb -s, never run a broad kill command, use two instances on fixed ports.

What does the human still do?

Agents write most of the code, the docs and the QA notes, and they have standing permission to commit and push on working branches. They ask first before anything irreversible, anything that spends money and anything that touches credentials, and some console steps are reserved for us outright. I decide what gets built, review merges into the integration branch and judge whether a street looks right. My brother Okan owns the product side: store listings, testers and what we ship next.

The other human job is keeping the shared memory honest. The repository has one long CLAUDE.md file that every agent session reads first: the technical rules, the release history, the account setup and what broke last time. When an agent learns something the hard way, it writes it there. That file is the difference between a session that starts from zero and one that starts from yesterday.

Where does GoTasty stand now?

GoTasty is in testing on Android and iOS: closed testing on Google Play and TestFlight on iOS. The cities, dishes and trailer are on the GoTasty page, and the design side is in the GoTasty dev log. For how I run agents beyond game development, read how to run multi-agent AI systems in production.