What an AI-ready game backend ships like

Coding agents have changed how software gets built in almost every domain. Web apps, mobile apps, infrastructure code – teams are shipping features with agents that plan, implement, and review against real codebases. The productivity numbers are hard to argue with.

Game backends are the exception. The backend layer – LiveOps, player state, economies, server-side game logic – is where agents still break down. And the reason has very little to do with the models.

Why AI agents break on game backends

We wrote about why agents struggle with game development broadly a few weeks ago. The backend layer has its own version of that problem, and it comes down to three things.

The architecture is domain-specific and undocumented

A server-authoritative shared C# execution model where the PlayerModel runs identically on client and server – that's not a pattern Claude or GPT-4 picked up from their training data. Every backend vendor does it differently. The conventions that matter most live in the heads of the people who built the system. Why does the matchmaker treat new players differently after level 14? Maybe Pete knows. Pete left in 2024.

The source is locked down

Most game backends are closed-source, or gate access behind expensive tiers. An agent that can't read the implementation is stuck at the API surface – guessing at patterns instead of following them. It'll produce code that compiles and violates the architecture in ways that don't show up until production.

The stakes are live

Game backends manage real player economies, active event schedules, progression systems that took months to balance. One bad write and you're doing manual player compensation at 3am on a Saturday. (Ask anyone who's been through it.) Studios won't connect AI tools to any of that unless the access model is read-only by default and the boundaries are unambiguous.

None of these problems get solved by better prompts or bigger context windows.

What makes a game backend AI-ready

We defined five criteria for an AI-ready game backend last week. The short version:

The backend needs to give agents something real to work with. Source code they can read – not an API surface they have to guess at. Documentation structured for machines, not just humans browsing a website. Connections through open standards like MCP so any model can plug in. Read-only access by default so studios actually trust the connection. And entry points for the whole team – developers, producers, LiveOps leads – not just the people who write code.

These are architectural decisions. You either made them early or you're rebuilding. Most game backend vendors made the opposite choices years ago: closed source, proprietary integrations, documentation designed for a docs site rather than an agent's context window.

Early results from AI agents on Metaplay

When we launched Metaplay, we made a set of choices for humans: readable C# in your repo, typed configs that fail at compile time, server-authoritative architecture, sample projects that are full working games, documentation that covers the why, compile loops measured in seconds.

Those choices turned out to be exactly what agents need. We didn't plan it that way. But we've been running a private preview of the AI tooling with a handful of studios, and the results came in faster than we expected.

Appodeal: a LiveOps feature in one week, solo

Pavlo Cherevko at Appodeal builds LiveOps features across a portfolio of casual games. Strong C# background – he previously shipped the same kind of journey feature at another company, where it took two teams of five engineers six weeks each. At Appodeal, he built a game-agnostic LiveOps package on Metaplay: server logic, configs, client SDK, sample Unity demo. The package was designed to drop into any new game in the portfolio with minimal integration work.

He shipped it solo. In a week.

Pavlo's workflow leans heavily on the Docs MCP – "the most used by me" – paired with deep research to explore what's possible before writing code. He's also prototyping a chat interface in the admin dashboard where a PM can type "improve day 7 retention by introducing rewards earlier" and the agent inspects what's configurable and sets it up. The bottleneck at Appodeal has shifted from dev speed to the product team understanding what's now possible.

Penguin Armada: 35 security issues caught in one agent review sweep

Henrik Marcus is the sole server engineer at Penguin Armada, a Supercell portfolio studio building Raiders Rise for Steam. Three developers total. No in-house code reviewer. When something breaks in the actor model or a validation gap slips into the gacha flow, Henrik is the only person who can catch it – usually by reading the documentation and hoping for the best.

He ran /review for the first time an hour before a call with us. No setup, no tuning, just pointed it at the codebase. It came back with ~35 issues – five categorised as must-fix security, including an unsynchronised action violation, missing positive-amount checks on debug actions that would have allowed negative token amounts, and validation gaps across the store and reward flow. "A perfect checklist of things to address and prioritise" was how he described it.

For Henrik, the value landed differently than raw productivity:

The review also surfaced SDK features Henrik didn't know existed – like the [DevelopmentAction] attribute for safely shipping debug cheats. And when he tried to wire hard-currency purchases through the existing offer and segmentation flow – something he'd spent two weeks stuck on – the agent mapped out the approach in minutes. "I tried two weeks ago, couldn't see how. With the agent: this is easy, you can just do it like this."

Trailmix: SDK updates from days to hours

Neil Palframan is Technical Director at Trailmix – 20+ years of experience, three developers on the team, launching Everwood in June. His team had Claude Code, ChatGPT, and Codex available. They weren't using any of them. The generic tools were there but nobody had a reason to dive in. The Metaplay-specific tooling gave them one.

SDK upgrades were the first thing that clicked. Neil used to budget three to five days for each release – custom changes, deprecated features, test passes, regression checking. With the agent, the dev work dropped to about two hours. The rest of the day was validation, which he still does himself.

Then he started using it on dashboard customisation – exposing player state to customer support, adding admin controls for granting coins and gems. Work that used to mean searching docs, hunting through examples, failing, asking support, and looping until something stuck. With the agent: a couple of hours.

His designer used it differently – ran /ask to scope out what a friends list feature would take, without anyone writing code. That gave the design team a rough technical picture and a list of trade-offs without pulling a developer off their sprint for days of investigation.

Each studio found a different way in. The common thread: the agent did useful work because the backend gave it enough to work with.

Metaplay AI launches at PGC Barcelona

On Monday we're showing the full picture for the first time.

Four surfaces, each designed for a different part of the workflow:

Everything is on the Metaplay AI page. Live demo at PGC Barcelona this week – real game, no slides.

If you're at PGC, come find us at booth P2.