• The Creative Director agent in Claude Code Game Studios requires falsifiable pillars with concrete design tests, a meaningfully higher standard than most studio GDDs ever reach

• Anti-pillars, what the game explicitly is not, are specified as a hard requirement. The industry has always known this tool exists and consistently fails to use it

• When pillars are vague enough to mean anything, they resolve nothing. The loudest voice in the room wins instead

• An AI agent enforcing these standards on every session is uncomfortable evidence of how low the bar has been set

The industry knows what a good design pillar looks like. It just rarely writes one.

Subscribe now

I have been reading the Claude Code Game Studios repo in detail over the past week. I wrote about its structural architecture and where it falls short in an earlier piece, and about the production thinking encoded in its collaboration protocol in a follow-up. This piece is about something else: the Creative Director agent, which is the strongest single agent in the roster, and what it reveals about a failure the industry has been tolerating for a long time.

What the agent actually demands

The Creative Director agent runs on Opus, Anthropic’s most capable model tier. That alone signals that the repo’s authors considered it the highest-stakes role in the system. Its Vision Articulation Framework asks five specific questions before any design work proceeds: the core fantasy, a unique hook tested with what the agent calls the “and also” test, the target MDA aesthetics ranked by priority, the emotional arc across a session, and anti-pillars. What the game explicitly is not.

The pillar methodology goes further. Pillars must be falsifiable. They must create tension with each other. They must apply to all departments, not just game design. Each must have a concrete design test: a real decision the pillar would resolve.

That last requirement is the one most studios skip. A pillar that cannot resolve a decision is not a pillar. It is a slogan. “Visceral, Cinematic, Deep”: three words on a deck that tell an engineer nothing about whether to cut or keep a feature. The agent will not accept it.

The scope cut framework is equally specific. Features are sorted from “cut first” (those that serve no pillar) through to “protect absolutely” (those that are the pillar). This mirrors how real triage works in production when you are over scope and the milestone is three weeks away. I have seen more poorly specified versions of this thinking in official game design documentation from studios with hundreds of people than I have in this single markdown file.

The anti-pillar is where it gets serious

Most design frameworks tell you what a game is. Anti-pillars specify what it is not. The difference is not semantic. Scope creep rarely enters through features that were explicitly proposed and approved. It enters through features that were never explicitly ruled out, that slipped in because nobody had written down that this game does not do that.

A pillar that cannot resolve a decision is not a pillar. It is a slogan.

Anti-pillars close that door. If the agent requires you to specify what the game is not before it will proceed, you are forced to have the conversation that studios routinely defer until it is expensive. You cannot gesture at “immersive” as a pillar and then quietly add a fast-travel system in month eight if “no friction removal” is written as an anti-pillar at the start of pre-production.

The fact that the design literature on pillars consistently acknowledges this problem and consistently treats anti-pillars as optional is the tell. Designers know the tool exists. It does not get used because specifying what a game is not requires the room to commit, and commitment is uncomfortable when the creative director and the business lead have different ideas about what the game is.

What vague pillars actually cost

I have been in greenlight and milestone reviews where the design pillars on the deck were so broad they could have described any game in the genre. I pushed back. The friction it created was not with the designers, who generally knew the pillars were thin. It was with business leadership, who had a tendency to oversimplify play mechanics and underestimate the complexity underneath them. Specific pillars constrain. Constraint is uncomfortable when you are not sure what you are building yet, and easier to avoid when the people with authority over the project prefer optionality.

The cost of that avoidance shows up later. Two features in conflict. A pillar too broad to resolve which one survives. The feature that shipped was the one backed by the loudest voice in the room, not the one better aligned with what the game was supposed to be. I have seen this pattern more than once across more than one project. The pillar was not absent. It was just vague enough to mean nothing when the decision actually needed to be made.

When pillars are vague enough to mean anything, they resolve nothing. The loudest voice in the room wins instead.

Falsifiable pillars with design tests exist precisely to prevent that. If a pillar can resolve a specific decision, the decision does not depend on who shouts loudest. It depends on what the team agreed the game was. The agent makes this non-negotiable at the point where it is cheapest to enforce: before any design work has been committed to.

The uncomfortable question

The standards the Creative Director agent enforces are not new. Falsifiable pillars, design tests, anti-pillars, the requirement that pillars apply across all departments and not just to game design: these appear in GDC talks, in design textbooks, in the working practice of every experienced creative director who has shipped a game with a coherent identity. The knowledge has been there for decades.

The CCGS Creative Director agent refuses to accept anything less because it has no politics. It has no relationship with the creative director to protect. It does not nod along at a greenlight meeting because the executive producer is in the room and the last time someone pushed back on the vision document things got uncomfortable for a week. It will not approve a vague pillar because the alternative is a difficult conversation.

It will simply ask the question again.

That is not a capability gap the industry has been unable to close. It is a behaviour gap. The agent holds the standard non-negotiably because it was written to do so. The room often fails to hold the same standard because holding it has costs that fall on individuals rather than on documents.

Leave a comment

If you have worked in production long enough to have been in that room, this comparison is not flattering. It is not meant to be.

• Claude Code Game Studios hit 19,380 GitHub stars in three months with no shipped game, and its most-engaged thread is a question about why the AI won’t build anything without human direction

• The users who fail treat it like autopilot; the users who succeed treat it like a studio that needs a managing director

• In February 2026, Harvard Business Review published a new role to describe what producers have been doing for thirty years

• Producer cognition is a specific set of moves, not instinct, and you can watch them fail in real time across three languages on a GitHub issue page

In February 2026, an open-source framework launched on GitHub with a clear pitch: turn a single Claude Code session into a full game development studio. By May, Claude Code Game Studios had 19,380 stars, 2,828 forks, and no shipped games. Its most active issue is a question: why does the AI generate elaborate design documents and sprint plans while producing almost no playable code?

Subscribe now

The answer sitting in that thread, in English, Chinese, and Russian, is the same one game studios spent decades learning. The studio doesn’t run itself. You do.

CCGS is a 49-agent framework built around a studio hierarchy: Tier 1 Directors, Tier 2 Department Leads, Tier 3 Specialists. It ships with 73 slash command skills, 12 automation hooks, and 41 document templates. The workflow runs from concept through game pillars, game design documents, architecture decision records, epics, user stories, and sprint planning before the agents touch code. That sequence exists for good reasons. It also means that for users expecting to describe a game and receive one, the first week is friction and consumed tokens producing nothing playable.

The expectation gap

csn6666, posting in Issue #46: “I feel like there are too many documents and communications between agents and humans but nothing’s really built after burning 30% of my weekly quota.”

LeonPang, writing in Chinese in Issue #29: “I thought I’d pitch an idea and the AI would run with it. Instead it turned into me doing the designing and the AI reviewing me.”

These are honest accounts of a genuine mismatch. The framework produces exactly what it’s designed to produce: structured pre-production artefacts, gated by a human decision-maker at each stage. The gap is between the README’s implied promise and what the work demands from the person sitting with it.

The documents are the first deliverable of a studio with an absent director. The quota was spent correctly. The director wasn’t there to use them.

The Chinese-language threads mirror the English ones almost exactly. So do the Russian threads. When the same complaint surfaces in three languages on the same framework, the problem is structural. The friction is baked into the design assumptions. Those assumptions include a human who knows what to do with pre-production artefacts.

The README doesn’t mention that.

What the users who succeed are doing

A user named elysi is 19 days into their current run. They have 188 GDScript files, 1,081 tests running via Godot Unit Testing at each code iteration, and a semi-playable pre-MVP baseline in Godot. They hit 100% of their weekly token limit by day 6 every week. They also trimmed CCGS to 49% of its original size after one restart, wrote 15 custom bash helper scripts to manage context consumption, and capped their deferred items register at 50, running a mid-sprint polish pass at 40 open items.

Their summary of what makes CCGS work: “The key to CCGS is the ‘studio’ doesn’t build the game. You’re the managing director. You need to steer it.”

That sounds obvious until you look at what steering requires. Producers do three specific things before they do anything else.

The first is reading the room. elysi’s restart decision didn’t come from the framework flagging a problem. It came from noticing that agents were arguing, tech-debt was accumulating faster than it was resolving, and the system was drifting. Reading the room means recognising the state of a system before acting on it. The users who struggle are prompting into a degrading environment and expecting different results.

The second is active listening. There’s a difference between reading agent output for confirmation and reading it for signal. Agents drift. They develop inconsistencies. Issue #63 documents this precisely: the /dev-story skill re-reads full architecture decision records even when stories already contain embedded summaries designed to prevent exactly that duplication. An agent won’t flag this. You have to notice it. Active listening is the practice of reading outputs for what they reveal about system health, not just for whether they completed the task.

The third is sentiment in the artefacts. Before elysi’s restart, they didn’t check headline metrics. They went into the state of the repo: the comments in deferred items, the tech-debt register, the patterns in what was escalating. That’s the Jira and Confluence read a producer does on day one of a troubled project. Before meetings. Before conversations. The information is in the margins.

“The key to CCGS is the ‘studio’ doesn’t build the game. You’re the managing director. You need to steer it.” — elysi, GitHub Issue #46

Technical skill accounts for little of the difference between elysi and the frustrated users in the same thread. smithjoshua125-rgb describes themselves as a complete novice and emerged from less than one week with a working prototype: a movement system, rollback netplay with client-side physics, and predictive replay working reliably at 100ms of simulated latency. They estimated the same work would have taken four to six months to learn and build manually. The difference: they treated CCGS as a framework to direct, not an autonomous builder to instruct. They went in knowing they were the director.

The CCGS community is discovering producer behaviours from first principles, without any production-methodology vocabulary. They aren’t talking about flow metrics or WIP limits. They’re working it out in GitHub threads because the work demanded it.

woobenny08, in the same Chinese-language thread as LeonPang: “Without the cognitive mindset of a ‘producer,’ AI simply cannot help you make a competent game.”

That observation was posted on a game framework’s GitHub issues page, in Chinese. It is also the most precise summary I’ve read of the research literature on AI agent management from the last six months.

HBR named the role in February

On February 12, 2026, Harvard Business Review published “To Thrive in the AI Era, Companies Need Agent Managers,” by Suraj Srinivasan and Vivienne Wei. The article introduces a new organisational role for overseeing AI agents: someone responsible for orchestrating how agents learn, collaborate, perform, and work safely alongside humans. They frame it as the role product managers played during the software revolution.

The strongest candidates, they argue, are people from operations and project management backgrounds. People who already understand the business process being automated deeply enough to evaluate whether an agent is executing it correctly.

They did not use the word “producer.” But the cognitive profile they describe is one game producers would recognise from their second week in the role.

The Salesforce agent manager they profile describes his daily routine as “Data, data, data. I start and end my day in dashboards, scorecards, and agent observability monitoring.” That is what a LiveOps producer’s Monday morning looks like, transposed to an enterprise AI context.

Srinivasan and Wei identify six competencies for the agent manager role. Three of them map directly onto what I described above. Understanding how agents function and how to diagnose failures. Knowing the domain process deeply enough to evaluate outputs. Defining when agents act alone and when they escalate to a human. These are reading the room, active listening, and sentiment in the artefacts. HBR named them for an audience that hadn’t encountered them before.

The broader data is consistent. Deloitte’s 2026 State of AI in the Enterprise report identifies the AI skills gap as the biggest barrier to integration and finds that only one in five companies has mature governance of autonomous AI agents. RAND Corporation’s 2025 analysis found 80.3% of AI projects fail to deliver intended business value. The Connext Global 2026 AI Oversight Report found only 17% of US adults consider workplace AI reliable without human oversight. A Workday analysis from January found roughly 40% of apparent AI productivity gains were being lost to rework and low-quality output. Every one of these reports describes the absence of producer work, in different vocabulary.

The game industry ran its own version of this study in 2025 through the “gameslop” wave: AI-assembled titles with no human curation that flooded storefronts and damaged player trust. The GDC 2026 State of the Game Industry report shows 52% of game professionals now view generative AI negatively, up from 30% the year before. The technical capability arrived faster than the understanding of how to direct it. That’s a different way of measuring the same skills gap Deloitte is tracking, and the same underlying problem.

The structural point

CCGS is generating honest production data in public, across three languages, about what agentic development actually costs and what it actually requires. The 19,000 stars reflect real interest from developers who want to build games with AI agents. Some of them are succeeding.

But the thing the community keeps discovering, at every experience level and in every language, is the same gap. The framework tells you what the agents can do. It tells you very little about what you need to bring to it.

What you need to bring is the ability to read a system that is drifting, to hear what the agents are actually producing rather than what you asked them to produce, and to go into the artefacts for the signal that doesn’t make it into the summary reports. That combination of skills has a name. It has had one for thirty years. The CCGS community didn’t coin it. They just ran into it without warning.

HBR called this “agent management” in February. The CCGS community discovered it in May. Game studios have been hiring for it since before GitHub existed.

All three are describing the same gap.

Leave a comment

“Without the cognitive mindset of a ‘producer,’ AI simply cannot help you make a competent game.” — woobenny08, GitHub Issue #29

This is part of the Production 101 series.

Features never get cut when they should. They get cut when there’s no other choice, usually three days before a milestone, in a meeting nobody wanted to call. The designers are furious, the engineers are exhausted, and the thing you’re cutting is the thing the team spent six weeks building.

Subscribe now

That’s disaster recovery. Scope management starts months earlier, in a conversation that nobody wanted to have when it was still optional.

The difference comes down to when you started. I’ve been on both sides of it, and I can tell you without hesitation: the disaster recovery version is worse in every possible way. It costs more time, more goodwill, and more schedule than the early conversation would have. The only reason it happens is that nobody wanted to be the person who said, early on, that this feature might not make it.

That person is the producer. That’s the job.

What scope management actually is

Scope management is the continuous discipline of keeping the work matched to what’s achievable. A single kickoff meeting where you agree on what’s in the game is a starting point, useful but insufficient. A panicked descope conversation three weeks before ship is an admission that the discipline wasn’t running. Scope management is the habit of checking, every week, whether what’s in the backlog still fits in the time available, and adjusting before the gap becomes a crisis.

The word “continuous” is doing real work there. Scope isn’t static. The team’s velocity changes. Dependencies shift. A feature that looked like two weeks of work turns out to be four. The things that were reasonable assumptions in pre-production get tested against reality in production, and some of them don’t survive the test.

The producer’s job is to keep the plan honest as that happens. Holding onto the original plan because everyone signed off on it at the start is how projects arrive at alpha in denial. A plan that has drifted from reality becomes a fiction that costs you the ability to see the actual problem.

“A plan that has drifted from reality becomes a fiction that costs you the ability to see the actual problem.”

This is why scope management pairs directly with scheduling. Post #13 — How to Build a Milestone Schedule covers how to build a schedule that’s honest about capacity. Scope management is what keeps it honest as the project moves forward.

Why you need a change request process

Every uncontrolled change to scope is a hidden tax on the schedule and the team. The individual changes each seem small. “Can we just add a quick colour option to the character creator?” Fine. “Can we squeeze in one more map?” Sure, sounds manageable. “While we’re doing the UI pass, can we also rethink the inventory system?” That one feels slightly bigger but the art director really wants it.

Add these up over twelve weeks and you have a project that’s carrying six months of hidden work with no corresponding extension to the timeline. That’s how milestones slip: thirty reasonable decisions made independently, each below the threshold of alarm.

The change request process exists to make that accumulation visible. Before any addition to scope gets agreed, it goes through a fast, lightweight assessment: what does this actually cost in time and resource, who does the work, and what, if anything, comes out to make room for it? You answer those three questions and then you make the decision with full information.

The studios where I’ve seen scope creep worst were the ones where the change request process was either absent or so heavy that people routed around it. If adding a feature to scope requires filling out a five-page form and waiting two weeks for approval, people will just start the work and log it against a vague backlog item. The process has to be fast enough that using it is easier than bypassing it. A fifteen-minute conversation and a single-line entry in the change log is enough. The goal is a light gate, not a bureaucratic barrier.

How to triage features under pressure

There will come a point on almost every project where the honest answer to “will we ship everything on the list?” is no. The question then is which things go.

The quality/time/resource triangle is familiar territory, possibly too familiar. You can have any two of the three. Better quality in less time costs more resource. More features in the same time means lower quality or more resource. The triangle describes a real constraint. No amount of motivation or heroics moves it. The useful question when scope is too large is which of these three levers you actually have, given your real constraints.

But knowing the triangle doesn’t tell you which features to cut. For that you need a way to sort the backlog by actual necessity, not by loudness or seniority of the person who wants the feature.

MoSCoW is a framework I’ve used consistently for this. The letters stand for: Must have, Should have, Could have, Won’t have. The names are self-explanatory, which is part of why it works. You go through the feature list and every item gets placed in one of the four categories. Must haves are things the game cannot ship without; they define the product. Should haves are things that matter but won’t prevent the game from shipping if they’re absent. Could haves are desirable but genuinely optional. Won’t haves are explicitly out of scope for this release.

The value of MoSCoW is the conversation it forces. If three different stakeholders have different views about whether a feature is a Must or a Should, that disagreement needs to be surfaced and resolved before the crisis, not during it. The framework provides the vocabulary. The producer’s job in triage is to facilitate that conversation, drive it to a decision, and own the process rather than the answer. Scope cut decisions draw on three perspectives simultaneously: the PM brings product priority, the CD brings quality bar, and the producer brings feasibility; no single role owns the outcome, and how studios handle the final call varies.

“The producer’s job in triage is to facilitate the conversation and own the process. The answer belongs to the team.”

The MoSCoW sort should happen early in production and then be revisited at each major milestone. By the time you’re in alpha, the Won’t Have list should be long. A long Won’t Have list means the project has arrived at an honest picture of what it actually is. That’s a healthy sign.

Cutting without destroying morale

Cutting a feature and dismissing the work that went into it are different things, and the difference matters.

When a feature gets cut, someone on the team built it, or spent weeks designing it, or argued for it in meetings. That work was real. The person who did it knows it was real. If you communicate the cut in a way that implies the work was wasted, or that it didn’t matter, you damage something that takes a long time to repair.

How to do it correctly: acknowledge that the work was good. Explain the constraint clearly, without softening it to the point of ambiguity. “We have eight weeks and fifty items on the Must Have list. This feature is a Could Have. It’s coming out.” That’s the whole message. No hedging, no false hope that it might come back, no suggestion that the decision is provisional when it isn’t.

The team can handle bad news. They’ve been in games long enough to know how this works. Bad news dressed up as something else is what breaks them. “We’re going to park this for now” when you mean “this is cut” is a form of dishonesty that people see through immediately and resent for months. Say the real thing.

In my experience, the teams that hold together through cuts are the ones where the producer told them the truth early and consistently. The teams that fracture are the ones where the cut felt sudden and unjustified, usually because the scope conversation had been avoided for weeks. The cut is survivable. The absence of honest conversation before it is what does the damage.

There’s also a practical dimension. If people don’t understand the real reason a feature was cut, they’ll invent one. The invented reasons are usually worse than the real one. They involve someone deciding their work doesn’t matter, or that there’s a political agenda, or that the project is secretly in worse shape than anyone is saying. Information vacuums fill with anxiety. Fill them with facts instead.

How to say no to a stakeholder

Saying no to a publisher request or a studio leadership directive on scope is a skill that takes time to develop, and getting it wrong is costly. The instinct, particularly early in a career, is either to say yes to everything or to say no in a way that sounds like reluctance rather than production reality. Both responses create problems.

The version that works is this: present the constraint as a production reality. “Here is what we can deliver in the available time, given current capacity and the features already committed.” That sentence invites a conversation about priorities. “That’s not possible” is an opinion and invites pushback about whether you’re trying hard enough. Those two responses land very differently in the room.

This only works if you have the data. Current velocity. Remaining capacity. A dependency map showing what blocks what. The outstanding Must Have list. With those things, the conversation is about facts that both parties are looking at together. Without them, it’s about whether people trust your judgment, which is a harder argument to win under pressure.

“Present the constraint as a production reality. ‘Here is what we can deliver in the available time’ invites a conversation. ‘That’s not possible’ invites a fight.”

When a stakeholder pushes back on a no, the question to ask is whether the push is about priority or about capacity. “We want this feature” is a priority argument; the answer is to show what comes out if it goes in. “We need this feature” suggests it should have been in the Must Have list; the answer is to go back to MoSCoW and reassess. In either case, you’re working from the plan, not from a negotiating position.

How scope creep actually happens

It’s rarely one big thing. The post-mortem of a slipped schedule almost always reveals the same pattern: thirty small things that each seemed reasonable at the time. A small UI improvement here, a quick feature there, an extra platform nobody formally agreed to. Each individual decision was made by a reasonable person responding to reasonable pressure.

Scope creep is an emergent property of reasonable people making reasonable decisions independently. Nobody sets out to sink a schedule. It happens because each individual change is too small to trigger alarm, and the accumulation only becomes visible when the schedule is already gone.

This is the argument for the change request process, and for keeping the MoSCoW list visible to the whole team. When individual decisions are made in isolation, the cost is invisible. When they go through a central point and land on a list that everyone can see, patterns emerge faster.

I’ve sat in post-mortems where the team was genuinely surprised by how much scope had drifted. They could name individual decisions that had seemed fine at the time. What they hadn’t seen was the aggregate. Running the MoSCoW list as a standing agenda item in production meetings is the simplest thing I know of for keeping that aggregate visible. It takes ten minutes. It pays for itself every time scope starts to drift.

The other thing scope creep teaches you is that “just a quick thing” is almost never just a quick thing. A small feature that touches the core game loop will generate testing requirements, tutorial copy, UI work, and at least one design iteration. The cost multiplies out from the initial estimate in ways that are predictable if you look at the dependency map, and invisible if you don’t. The change request process, done properly, makes you look at the dependency map every time.

If you’re working on the schedule that scope management feeds into, Post #13 — How to Build a Milestone Schedule covers the mechanics of keeping a milestone plan honest as conditions change. The two disciplines sit next to each other and work better together.

Leave a comment

For a broader look at how production governance fits together, Production 101 #8 on legal documents gives useful context on the contractual side of what goes in and comes out of a project.

This is part of the Production 101 series.

A schedule is a theory. The moment the project starts, reality runs an experiment to test it. The producers who understand this build schedules that break gracefully, in predictable places, with enough room to recover. The producers who treat the schedule as a fixed plan spend the back half of every project explaining why the theory was wrong.

Subscribe now

What a milestone schedule is actually for

Most people, when they think about a milestone schedule, think about prediction. The schedule will tell us when things will be done. That framing leads to disappointment almost immediately, because the schedule is not a prediction device. It’s a communication device.

The schedule talks to different audiences simultaneously, and each of them wants something different from it. The development team wants to know what they’re building to and when. They need enough structure to make decisions week to week without waiting for permission on every call. Leadership wants confidence in delivery. They need to see a credible path from where the project is now to a shipped product, with enough milestones along the way that they can track progress without reading every iteration update. Publishers and external stakeholders want to know when money moves, when they can plan marketing, when platform certification becomes a real conversation.

The same document has to serve all of them, which is part of why schedules are difficult to build well. You’re not writing one story. You’re writing a document that reads differently depending on who’s looking at it, and if you lose track of that, you end up with a schedule that tells the team too much and leadership too little, or vice versa.

A schedule that serves the team but not the stakeholders will get ignored by the people who fund the project. A schedule that serves the stakeholders but not the team will be invisible in the room where the work actually happens. You need both.

Working backwards from the ship date

The right starting point for any milestone schedule is the end. Find the hard external gates first: platform certification submission, marketing lock, gold master, press review build, the dates written into the contract. Those dates are not moveable, or they’re moveable only at significant cost. Everything else in the schedule fills in backwards from there.

This is how you find the critical path. The critical path is the chain of dependencies that determines the earliest possible ship date. It’s not the whole project. Most of the work on any project runs in parallel and only a subset of it directly controls when you can ship. Finding that chain is the first job, because until you know it, you don’t know where schedule pressure actually lands.

A common mistake is building the schedule by filling forward from the start date, estimating how long things will take, and seeing where you end up. The problem with this approach is that you find out late when there’s a problem, and by then the external gates haven’t moved but the available time has shrunk. Working backwards surfaces those conflicts early, while you still have options.

I’ve started projects both ways. The forward-fill approach always felt more natural at the start because you’re building the picture of the project rather than reasoning back from a date that feels arbitrary. But every time I built a schedule that way, I spent the first month in gentle denial about a conflict I’d have seen immediately if I’d worked backwards. The backwards approach forces honesty about whether the external constraints are even compatible with the work involved. That’s uncomfortable at the start and useful three months later.

Estimating without deceiving yourself

Teams have two competing instincts when it comes to estimation, and both create dysfunction.

The first instinct is inflation as protection. Teams pad their estimates because they’ve been burned before: they gave a realistic estimate, it was cut, and they missed the deadline. The padding is a rational response to a bad system. But a schedule built on padded estimates gives leadership a false picture of where time is actually going, and when everything looks like it’s on track right up until it isn’t, nobody is positioned to respond.

The second instinct is compression as optimism. Studios, and sometimes producers, compress estimates because they want the schedule to be possible. The work has to fit in the time available, so the estimates adjust until it does. A schedule built this way is one that nobody on the team actually believes, and when nobody believes the schedule, it stops having any effect on behaviour.

The fundamental error is conflating estimation with commitment. When an estimate becomes a commitment before any work has started, both honesty and accuracy disappear. An estimate is a forecast. A commitment is something else, and it belongs later in the process.

What historical velocity data gives you is a check on both failure modes. If your team has averaged 18 stories per iteration for the last six months and your new schedule assumes 30, something needs to change before you start. The data doesn’t tell you what the right estimate is. It tells you what the team has actually done, which is a much better starting point than asking people to say how long things will take under pressure.

The distinction to preserve is between estimation and commitment. An estimate says “this is our best current picture of the time this work will take.” A commitment says “we will deliver this thing by this date.” Teams make commitments. Schedules contain estimates. Treating them as interchangeable is where the dysfunction starts.

Where to put contingency

Every experienced producer has been told to include contingency in their schedule. Most of them have watched that contingency disappear. The question is where to put it.

Spreading contingency evenly across the schedule, a few days of buffer at the end of every iteration or milestone, sounds reasonable. It never works. The buffer disappears into Parkinson’s Law: work expands to fill the time available. A team with a week of buffer at the end of an iteration will unconsciously calibrate to use it. By the time the external milestone arrives, the buffer has been spent on tasks that felt urgent in the moment.

Student’s Syndrome adds a second problem. When people know that buffer time exists, they tend to start work later. The buffer becomes the safety net, and the safety net gets used not for genuine overruns but for the delay in starting. End result: the buffer is gone, but the tasks finished roughly when they would have anyway.

The alternative that holds up better in practice is a single protected contingency block late in the project. Not distributed throughout; concentrated at the end, explicitly labelled, and defended against anything that isn’t a genuine schedule threat. Teams can see it. They know it exists and they know why it exists. The social contract is that it doesn’t get raided for scope creep or features that should have been cut earlier.

The single-buffer approach works best when the producer is explicit about it. Not a hidden reserve, but a declared piece of the schedule: “We have three weeks of contingency before certification. We’re not spending it unless something in the critical path goes wrong.” Making it visible makes it harder to erode. Teams don’t spend budget they can see, nearly as readily as they spend time they can’t.

The other thing the single buffer does is concentrate schedule pressure. If every iteration has a cushion, nobody feels the urgency of the critical path. If the only buffer sits at the end, the cost of slipping any critical-path item is immediately visible. That’s uncomfortable, but it’s accurate, and accurate discomfort is more useful than comfortable imprecision.

Probabilistic forecasting

There is a better answer to “when will we ship?” than a single date. That answer is a probability range, and it comes from the team’s actual throughput history rather than from estimates made at the start of the project.

Monte Carlo simulation treats your historical throughput data, how many tasks the team has completed per iteration or per week over the last several months, as the input and produces a distribution of likely completion dates. Instead of saying “we will ship on March 15,” you can say “based on current throughput, there’s a 75% probability we ship before March 22.” That second statement is more honest and, in practice, more useful for planning. A publisher who knows there’s a 25% chance of slipping past a date can make contingency plans. A publisher who was told “March 15” and finds out in February that it’s now April has nothing to work with.

I covered the mechanics of this approach in detail, including the specific tools and how to read the outputs, in From Meteorology to Project Management: The Power of Predictive Modelling, Part 2. If probabilistic forecasting is new territory, that post is the right place to start. What I’ll add here is that the confidence level you quote matters, and it should vary by audience. When you’re talking to the team about iteration planning, 50% confidence is a useful working target. When you’re quoting a date to a publisher or committing to a certification window, you want to be at 85% or higher. That difference is calibrating risk to consequence.

Presenting the schedule to different audiences

The version of the schedule you show to a publisher is not the version on the project board. The distinction is about signal-to-noise.

Technical teams need granularity. Which features are in which iteration. Which dependencies are in flight and where the handoffs happen. What’s been cut, what’s been added, and what’s still under discussion. The project board is their instrument panel and it needs to be accurate to be useful. A summary-level view strips out the information they need to do their jobs.

Executives need the headline range and the key dates. They are reading the schedule to understand whether the project is on track and whether the external commitments are safe. They do not need to see every task; they need to see the milestones, the current health indicator, and whether anything has changed since last time. The more detail you put in front of an executive, the less they see the signal. They start asking questions about the tasks rather than the delivery risk, and the conversation moves away from where it needs to be.

Publishers and platform stakeholders have a third set of requirements. They’re looking at certification windows, marketing beats, and whether the date in the contract still has a reasonable probability of holding. What they need is a clear statement of the key dates, the confidence level behind them, and a brief account of any risks that could move those dates. A publisher who receives a three-page Gantt chart learns less from it than a publisher who receives a single page with four dates, three risk items, and a current confidence rating.

The mistake producers make is building one schedule and sending it to everyone. The project board is not a stakeholder communication. It’s an internal instrument. Build the communication layer on top of it rather than pointing people at the board and hoping they’ll find what they need.

The practical approach is to maintain one source of truth at the task level, which the team uses, and to build audience-specific views on top of it for every other conversation. That separation takes about twenty minutes to set up and saves hours of misaligned expectations.

Reading the warning signs

By the time a milestone review tells you the schedule is in trouble, you’ve already missed your window to respond. The signals come earlier, and they’re readable if you know what to look for.

Velocity dropping is the most visible indicator. If the team has been averaging 20 stories per iteration and the last two iterations came in at 12 and 11, that’s not a bad week. That’s a pattern, and it’s pointing at something. The cause might be technical: something in the codebase has become harder to work with and estimates are growing. It might be people: someone key is distracted, stuck, or burning out. It might be process: a dependency with another team has created a bottleneck that’s not showing up in the task list. Whatever the cause, three iterations of dropping velocity is a schedule problem in progress, and you want to know about it before the milestone review does.

Tasks reopening is a close second. When work that was marked done comes back as incomplete, it means either the definition of done is unclear or quality issues are emerging that weren’t caught on the first pass. Either way, the time estimate for that work was wrong, and everything downstream of it needs adjusting.

Late estimates lengthening is harder to spot but important. When the team starts giving longer estimates for work in the current iteration than they did for equivalent work two months ago, it means they’re experiencing something that’s making the work harder. That could be scope creep absorbed into existing tasks, technical debt accumulating, or simply the fact that later-game integration work is almost always harder than early-project greenfield work. The estimates are trying to tell you something.

The leading indicator I’ve learned to watch most carefully is QA finding significantly more defects than expected in the last third of an iteration. That pattern, early progress followed by a late spike in issues, tends to mean that tasks are being marked complete before they’re genuinely integrated. The work is done in isolation but it hasn’t been tested against the rest of the build. When I see that pattern two or three iterations in a row, I start the investigation before the milestone review, not during it.

None of these signals require sophisticated tooling to spot. They require looking at the same numbers week over week and noticing when something changes. The status report discipline I covered in Production 101 #9 is part of what makes this possible: when you’re tracking the same metrics every week, the deviations are visible. When you’re writing status reports reactively, reconstructing the week from memory, the early signals tend to get smoothed over.

Leave a comment

The question is not what to do when a milestone review confirms the schedule has slipped. The question is what to do when the leading indicators appear, when there’s still enough of the schedule left to respond. That’s a harder problem to solve, but it’s the one that actually matters.

• Agile is a set of values and principles from 2001. Scrum and Kanban are frameworks built on top of them, not synonyms for them.

• Most studios run a Scrum-shaped process that breaks in predictable places: creative work, cross-discipline cycles, and anything with unpredictable incoming demand.

• The GDD anti-pattern is the most common failure mode in game development: treating a fixed design document as requirements while claiming to run Agile.

• What you need on day one is practical: how to run a sprint, a backlog, a standup, a retro. The framework debates can wait.

This is part of the Production 101 series.

Most studios say they do Scrum. Few actually do, and that’s probably fine. Scrum was designed for software development teams that could specify requirements in advance, work in stable two-week cycles, and ship something at the end of every sprint. Game development is none of those things. What matters is understanding why studios adapt Agile the way they do, so you’re making deliberate choices rather than inheriting someone else’s cargo cult.

Subscribe now

What Agile actually is

The Agile Manifesto was published in 2001 by seventeen software developers who were frustrated with heavyweight process. Waterfall development, with its years-long specification phases and big-bang releases, was failing teams at scale. The manifesto was a response to that failure, not a new methodology. It laid out four values and twelve principles. It named no tools, no ceremonies, no specific process of any kind.

The four values are worth knowing plainly:

Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan.

Each value has a qualifier: the right side still matters, the left side matters more. That qualifier gets ignored constantly. Teams that treat “working software over comprehensive documentation” as a licence to write nothing have misread the document.

The twelve principles build on those values. A few are particularly relevant to game development: delivering working software frequently, welcoming changing requirements even late in development, and maintaining a sustainable pace. All three are harder than they sound. Sustainable pace in particular is something the games industry has historically treated as optional.

The manifesto was a critique, not a methodology. The Agile industry that grew up around it spent twenty years building methodologies and selling them back as if they were what the manifesto had asked for.

I wrote about this in more depth in The Agile Manifesto Said Nothing About Scrum. The short version: understanding why the manifesto was written helps you know which adaptations are legitimate and which ones are just drift.

The GDD anti-pattern

The most common Agile anti-pattern in game development is the Game Design Document used as a requirements specification.

The GDD has genuine uses. It’s a communication tool, a design memory, a way to align a team on what they’re building. But studios frequently write a comprehensive GDD in pre-production, treat it as fixed scope, and then attempt to run Agile sprints against it. That is, structurally, waterfall. You’ve done the big upfront requirements work. The sprints are just execution phases with more meetings.

The conflict with Agile’s fourth value is direct: responding to change over following a plan. A fixed GDD is a plan. Running sprints against it while calling it Agile is a costume, not a method.

The tell is how the team reacts when playtesting reveals the design doesn’t work. If the response is “the GDD says we’re building this, so we keep building it and see what happens,” the team is leaning towards waterfall thinking. If the response is “the design needs to change, let’s update the backlog,” they’re working in a way that’s closer to Agile in practice, regardless of what the GDD says. The document’s existence is less important than whether the team treats it as responsive to new information.

This doesn’t mean scrapping the GDD. It means understanding what it’s for. A living design document that gets updated as the team learns is compatible with Agile. A frozen specification document is not, regardless of what you call the execution process.

Scrum: what it actually is

Scrum is a framework built on Agile principles. It’s what most studios mean when they say “we do Agile.” If you’re starting a production role, you’ll encounter it.

The core structure is the sprint: a fixed-length work cycle, typically two weeks. Each sprint has a goal, which is a statement of what the team intends to deliver by the end. The sprint backlog is the set of tasks the team commits to for that cycle. At the end, the team delivers something reviewable, reviews it, reflects on the process, and plans the next sprint.

The ceremonies Scrum specifies are five. Sprint planning: the team selects items from the product backlog, breaks them into tasks, and commits to a sprint goal. The daily standup: a short synchronisation meeting, fifteen minutes, where each person covers what they did yesterday, what they’re doing today, and what’s blocking them. Sprint review: the team demonstrates what was completed to stakeholders and collects feedback. Sprint retrospective: the team examines its own process, identifies what worked and what didn’t, and commits to at least one improvement. Backlog refinement: an ongoing activity where the product backlog is reviewed, estimated, and ordered so that the top items are always ready to sprint.

The daily standup is a synchronisation tool for the team. The moment it becomes a reporting mechanism, you’ve changed what it’s for.

The two key roles are the Product Owner, who owns the backlog and represents business priorities, and the Scrum Master, who facilitates the process and removes impediments. In game studios these roles often get blurred. I’ve covered the Product Owner role in Production 101 #7. The producer often fills some of the Scrum Master function, though studios handle this differently.

Velocity is Scrum’s primary planning metric. Story points are estimates assigned to backlog items. Velocity is the number of story points a team completes per sprint. Over time, velocity becomes a forecasting tool: if the team consistently delivers forty points per sprint, you can estimate roughly how many sprints a given backlog will take.

Where Scrum breaks in game development

Scrum’s assumptions about work break in several places in game development, and understanding where helps you adapt more deliberately.

The first problem is decomposition. Scrum works well on discrete, describable features: build the login screen, implement the inventory system, fix the physics interaction on item pickup. Those things have a definition of done that a team can agree on in advance. A weapon feel pass doesn’t. You know it when it feels right. Iterating toward a feeling isn’t the same process as building a specification, and forcing it into sprint stories produces either vague tickets that don’t mean anything or artificially precise ones that miss the point.

The second problem is cross-discipline cycles. Art, design, and engineering operate on different rhythms. A piece of concept art might take a day. A finished environment asset might take three weeks. A coded feature and the art that goes with it rarely align on the same sprint boundary. Scrum assumes relatively homogeneous team output. Game development rarely has it.

I’ve seen sprints where the art team finished their items by Wednesday and spent Thursday and Friday pulling unplanned work, while the engineering team was still mid-implementation on items they’d estimated as three-pointers. I’ve also seen the opposite: work that would have taken three days if anyone had started Monday, somehow consuming the full two weeks because the sprint boundary was the deadline and the deadline felt far away. Parkinson’s Law at sprint scale. Both patterns produce the same result: the sprint boundary becomes a fiction the team works around rather than a real commitment structure. At that point you’re tracking velocity but getting little planning value from it.

The third problem is the definition of done. In software, done often means shipped and running. In game development, done can mean: grey-boxed, art-complete, audio-complete, balance-complete, QA-signed-off, or any combination of those. A feature that’s code-complete but has placeholder art and no audio isn’t done in any player-facing sense. The “potentially shippable product” that Scrum promises at the end of each sprint is difficult to produce when disciplines are at different stages of completion on the same feature.

The estimation problem compounds all of this. Story points work reasonably well when teams estimate similar work repeatedly and can calibrate from history. Creative work resists this. The first level of a new game takes longer than the twentieth because the team is still discovering what the game is. Point estimation on creative unknowns introduces false precision into planning, and teams learn to game the estimates to avoid being held to numbers they couldn’t honestly give.

Kanban as an alternative

Kanban is a different mental model entirely. Where Scrum organises work into time-boxed sprints with committed goals, Kanban organises work as a continuous flow through a series of stages. There are no sprints, no velocity, and no sprint planning ceremonies. Items move through the board from backlog to done as capacity opens up.

The two Kanban principles that matter most are WIP limits and cycle time. WIP limits: each column on the board has a maximum number of items allowed. When a column is full, the team cannot pull more work; they focus on clearing what’s blocked. This surfaces blockages rather than hiding them behind new work. Cycle time: the measure of how long a given item takes to move from “started” to “done.” Over a large enough sample, cycle time becomes the forecasting tool that velocity is in Scrum, and it’s grounded in what actually happened rather than what was estimated.

Kanban fits certain kinds of game work better than Scrum. Live operations work is the clearest example: incoming demand is unpredictable, items range from critical bugs to minor content updates, and time-boxing the work into sprints creates artificial urgency and artificial boundaries. A live service team running Kanban can pull the highest-priority item whenever capacity opens, without waiting for the next sprint planning meeting.

Kanban makes the work’s actual state visible. WIP limits mean a blocked item can’t be buried under new items. The board stops being a progress display and starts being a diagnostic tool.

I covered the Kanban approach in more depth in Scrum Was Never the Right Tool for Game Development. The practical summary: Kanban is better for work with unpredictable demand, for support tracks running alongside development, and for any stream where continuous flow matters more than sprint commitments.

What most studios actually run

The purist version of either framework is rare in practice. Most studios run something hybrid. The development team runs a Scrum-like sprint structure, with planning, standups, review, and retro on a two-week cadence. The live ops or support team runs a Kanban-like flow board, pulling work as capacity opens without sprint commitments.

This works because the two types of work actually have different natures. Development work, even when it resists decomposition, benefits from the regular rhythm of sprint ceremonies: planning forces prioritisation, review creates a forcing function for demonstrable progress, and retros give the team a structured moment to examine how they’re working. Live and support work benefits from flow: it shouldn’t have to wait for a sprint boundary to address an urgent player issue.

I’ve run this kind of hybrid on multiple projects. The key is making the two tracks visible to each other without forcing them onto the same cadence. The development team’s sprint calendar becomes a loose synchronisation point for the live ops team, useful for coordination but not for work planning. The most important thing is that both teams know which system they’re operating in and why. Teams that don’t know why they’re using a framework can’t make sensible adaptations when the framework doesn’t fit.

The producer’s role here is to make the system work, not to defend its purity. I’ve seen producers spend real energy arguing about whether a team is doing “true Scrum” or “real Kanban.” That energy is better spent asking whether the team can plan effectively, whether work is moving without unnecessary friction, and whether the system surfaces problems early enough to address them. If it does, the label doesn’t matter.

What you actually need to know

If you’re starting a production role, here’s what you’ll encounter on day one and need to be able to operate.

You need to know how to run a sprint. That means facilitating sprint planning: helping the team identify what’s realistic for the sprint, checking that tasks are decomposed enough to be estimated, and making sure there’s an actual sprint goal rather than just a pile of tickets. It means keeping the sprint moving: attending standups, tracking blockers, escalating impediments that the team can’t resolve on their own. It means facilitating the sprint review so the team demonstrates what was built rather than just reporting on it, and running a retrospective that generates at least one real change.

You need to know how to manage a backlog. Backlog items should be ordered by priority, not by who asked loudest. Each item should be understood well enough that the team can estimate it. Refinement is ongoing: items at the top of the backlog should be ready to sprint, items further down can stay rough until they get closer. A backlog that hasn’t been refined in three weeks is a planning liability.

You need to know what a board is for. The board, whether it’s a physical wall or Jira or something else, is a model of the work’s current state. The value is in keeping it accurate. A board where items haven’t moved in two weeks is lying to you. Part of the producer’s job is making sure the board reflects reality rather than what the team wishes were true.

The ceremonies and tools are learnable. What takes longer is developing the instinct for when the system is working and when it’s become a performance that the team has learned to go through without getting anything from it.

The deeper framework debates can wait until you’ve run a few sprints and seen where the friction lives: whether Scrum’s sprint reviews should produce a potentially shippable increment, whether velocity should be shared outside the team, whether Kanban or Scrum fits better for a given workstream. Theory is useful, but it’s grounded by experience.

If you want to go further: the Scrum Guide is free, thirteen pages, and worth reading before you run your first sprint. Mike Cohn’s work on user stories and estimation is the standard reference for story points and backlog refinement. For Kanban, the Kanban Guide is the equivalent starting point. For the values underpinning all of it, the original Agile Manifesto is available at agilemanifesto.org and takes about five minutes to read.

None of that reading replaces doing it. The ceremonies make more sense once you’ve run them badly a few times and had to figure out why.

Leave a comment

The next post in the Production 101 series covers milestone scheduling: how to build a production schedule that’s honest about uncertainty rather than one that looks confident in a spreadsheet but falls apart at the first milestone.

• A live service roadmap is always in progress: near-term precision is possible, far-term precision is fiction.

• The live ops roadmap has fixed calendar dates that create hard obligations absent from all other roadmap types.

• Player-facing roadmaps should contain only things you would be comfortable having quoted back to you.

• Slipping and reprioritising are different things; communicating them as though they are the same creates a blame culture around bad news.

Production 101 is a series for people entering or early in game production. This post continues from #10 — Producers’ Impact on Product Roadmaps. | Next: #12 — Agile for Game Producers | Series index

Subscribe now

A boxed game has a roadmap that covers one arc: development, certification, launch. Then it’s done. The roadmap gets filed, the team either pivots to DLC or moves to the next project, and nobody has to revise Q3 at the same time as they’re shipping Q2.

Live service removes that clean ending. You are planning what comes next while operating what’s already live, and both of those things are happening at the same time. The roadmap is always in progress. The near end is being revised because the team is working on it; the far end is being revised because the business has changed since you last looked at it. There is no version of a live service roadmap that is finished. There are only versions that are current and versions that have fallen behind reality.

That rhythm takes some getting used to, particularly if you’ve spent your career in pre-release development. The deadline was the anchor. Everything on the roadmap pointed toward it, and when you shipped, the document had served its purpose. In live service, the absence of that anchor changes how you hold the far end of the roadmap. The further out a planned feature sits, the less you should trust the precision of its placement. The business will have changed by then in ways you can’t fully anticipate now.

The perpetual roadmap

In pre-release production, a ship date stabilises the roadmap over time. As you approach launch, the remaining work becomes concrete, the estimates tighten, and the roadmap starts to look like a real schedule. In live service, that stabilising force is absent. There is no converging point that forces the far end to sharpen.

What you have instead is a rolling window of precision. The next six to eight weeks are specific: features are scoped, the team is working on them, and the estimates are as reliable as they’re going to be. The following quarter is thematic: you know the shape of what’s coming but not the granular detail. Anything beyond that is directional. You know what kind of content the game needs and roughly when, but the specifics are genuinely undecided.

The live service producer learns to hold the near end tightly and the far end loosely. Tightly at the near end means specific commitments, real estimates, and clear accountability for delivery. Loosely at the far end means not treating a quarter-level label as equivalent to a finished scope. When someone on the team asks “are we building this?” and points to something eight months out on the roadmap, the honest answer is usually: probably, but we haven’t designed it yet. That honesty is better than false confidence.

The live service roadmap is an argument for a sequence of decisions, not a record of decisions already made. The near end is nearly decided. The far end is an intention.

The practical implication is that roadmap updates are a normal, recurring part of the job rather than an admission of failure. A roadmap that never changes is a roadmap nobody is maintaining. The question is how you update it in a way that keeps stakeholders oriented without making them feel like the team is making it up as it goes. That distinction between expected revision and unexpected slip matters, and I’ll come back to it in the section on updating the roadmap without losing credibility.

The live ops roadmap specifically

What distinguishes the live ops roadmap from all the others is that it often has genuinely fixed dates, and fixed dates change the production stakes considerably.

A seasonal event can’t slip because the season happens whether the team is ready or not. The Halloween event is in October. A feature slipping from Q2 to Q3 on the tactical roadmap is a planning problem. The team is frustrated, the PM adjusts the slide, and life goes on. The Halloween event not shipping in October is a live failure with immediate player-facing consequences. You either ship it broken, cancel it publicly, or ship a reduced version and explain why. There is no quiet option.

This creates a specific problem around confidence levels. Items on a live ops roadmap vary widely in certainty, but from the outside they all look identical on a slide. Some content has already been built and is in QA. Some is planned and development has started. Some is aspirational, included because someone on the team wanted to see if it might fit the window. The third category is a wish. When marketing treats it like the first category, you have a live problem.

The producer’s job on the live ops roadmap is to make those confidence levels explicit and keep them current. Confidence changes as development progresses, so this requires active maintenance throughout the cycle. Downstream teams like marketing and community need to know about those changes in time to adjust their plans. A community team that has been building social content around an event that turns out to be aspirational has wasted time and will feel misled when the information reaches them.

The producer is the person who catches this before it becomes a promise. That means being in the room when the live ops calendar is being drafted, not being consulted after it’s been locked.

I’ve worked on live service titles where the live ops roadmap was driven almost entirely by community and marketing, with production consulted after the calendar was finalised. The result was a content plan that looked coherent on a slide and fell apart the moment you set it against actual capacity. The fix was getting production into the planning process before the dates were committed, not after. Once the marketing team has built a campaign around a date, that date has an owner outside the development team, and unpicking it is a much harder conversation than preventing it.

Player-facing roadmaps

Players are a third audience that the internal roadmap was never designed to serve. The strategic roadmap is for executives. The tactical roadmap is for the development team. The live ops roadmap coordinates the people who operate the game. None of them, in their internal form, are appropriate to share with players, but studios publish player-facing roadmaps anyway, usually because the community is asking what’s coming.

The problem is that players read roadmaps differently from internal stakeholders. An executive reading a rough quarter-level commitment understands implicitly that this is directional planning. A player reading the same information reads a promise. Communities have long memories and track commitments carefully. A forum post from eight months ago, a Discord screenshot, a tweet quoting a roadmap slide: these resurface when something changes.

I’ve worked on games where we published quarterly content previews with what we thought was appropriate hedging: plans may change, this is subject to revision, nothing is confirmed. The hedging was invisible to most of the community. When something slipped, the response was consistent: “You promised this.” After enough of those conversations, the lesson was clear. The internal roadmap can be ambitious. The external one should contain only things you would be comfortable having quoted back to you in the worst possible context, six months from now, by someone who is already disappointed.

That means the player-facing roadmap should be shorter and more conservative than the internal version, and deliberately vaguer about timing. “Coming this season” is a safer commitment than “releasing in October.” A broad content theme is safer than a specific feature name if the design hasn’t been finalised. The goal is to give players a genuine signal about direction without locking in specifics that might change.

What belongs on a live service roadmap

The things that belong on a live service roadmap are the things that have been agreed, estimated, and at least partially scoped. Features, events, content cadence, the seasonal calendar, and the dependency structure between features that need to ship before other features can start.

The things that don’t belong are estimates presented as certainties, work that hasn’t been scoped, and features that are still at the concept stage but have been given a quarter assignment to make them look planned. A roadmap that treats conceptual work and nearly-finished work as equivalent is presenting a false picture, and someone will eventually make a decision based on it.

The test is simple: if this roadmap were leaked to a journalist tomorrow, what would embarrass you? Anything that would embarrass you probably shouldn’t appear as a confirmed commitment.

The honest version of a live service roadmap distinguishes confidence levels explicitly. Some teams label items: in development, planned, under consideration. Others use a colour scheme. The specific system matters less than having one. What matters is that when a downstream team looks at the roadmap, they can tell the difference between a commitment and an intention. When that distinction is absent, everyone makes conservative assumptions, marketing builds campaigns around aspirational items, and the first slip creates disproportionate damage to trust. Making confidence levels visible is an accurate representation of how live service development actually works.

Updating it without losing credibility

A changing roadmap is the expected condition of live service. The question is how you communicate changes without making stakeholders feel that the team doesn’t know what it’s doing.

The distinction worth drawing clearly is between slipping and reprioritising. These are different events, and they carry different weight.

Slipping means something took longer than expected. The work was planned, the estimate was wrong, and the item is moving to a later window. This happens. Teams should communicate it early, explain why it happened, and give a revised target. Slipping the same item twice is a different conversation, one about whether the estimate was realistic or whether something more structural is wrong.

Reprioritising means the business changed its mind. A commercial opportunity emerged. Player data came back showing something different from what was expected. A competitor moved in a direction that changed what the game needed to do. In these cases, the original item has been deprioritised in favour of something the business judged more important. That conversation is usually easier to have, because it reflects a decision rather than a failure to deliver.

Conflating the two is where teams get into trouble. When “the PM changed the priorities” gets communicated as “we’re slipping,” the team learns that slipping is always attributed to someone, so nobody admits to it early. The producer who knows the estimate is wrong stays quiet for an extra two weeks hoping the team can recover. The PM who changed the priorities doesn’t correct the characterisation because it deflects blame away from the product decision. The eventual conversation is twice as bad as it needed to be.

Slipping and reprioritising look similar on a slide. They feel completely different to the team. The producer’s job is to communicate which is which, and why.

The producer’s ongoing role

In live service, the roadmap conversation never stops. New data arrives, the business responds to it, priorities shift, and the roadmap has to reflect that. The producer’s role is to make sure those changes are translated into delivery reality accurately.

That means showing up to every roadmap revision with an honest account of what the team can build in the next window given what’s already live and what’s already in flight. It means tracking the difference between the capacity that existed when the previous roadmap was committed and the capacity available now. Any item resting on an estimate made before the design was finished needs a flag, particularly if that estimate is what’s holding up someone else’s plan.

The producer who defers in those conversations to avoid an uncomfortable exchange does the PM no favours. The PM needs accurate delivery input to make good product calls. A PM who has been told that everything is on track when it isn’t will make commitments based on that false picture, and the damage appears downstream when the team can’t deliver what was promised. The short-term comfort of not raising the problem costs more than the discomfort of raising it early.

The product manager’s role in this dynamic is worth understanding in its own right, because the producer-PM relationship is where most of the productive tension in live service roadmapping lives. The producer brings delivery reality. The PM brings product judgement. Neither is sufficient alone.

The work itself doesn’t change between years one and five of a live game: you’re still updating the same roadmap, having the same capacity conversations, catching the same optimistic estimates before they become public commitments. What changes is that you build a track record for accuracy, and that track record is the thing that earns you the credibility to be heard early rather than consulted late. The producer who has never told an executive things were fine when they weren’t is the one who gets believed when they say something is actually fine. That trust compounds over time. It’s the only part of live service that gets easier.

• AI adoption in games is at 36%. Durable results are at 5%. The gap is structural.

• A production now has deliverables, process, and a Production Context Stack

• The Production Context Stack is version-controlled, agent-readable, and maintained like any other critical project asset

• Here’s what it consists of and how to start building one

The GDC 2026 State of the Game Industry survey found that 36% of game industry professionals already use generative AI in their daily work. A separate Q3 2025 report on AI in gaming found that only 5% of pilot AI projects actually reach production and generate real benefits.

That gap, between widespread adoption and durable results, is not a model problem. The models are good enough. The gap is structural.

Subscribe now

I’ve watched this pattern up close. Producers who’ve adopted AI have generally done the same thing: they’ve added it to how they already work. They reach for Claude when they need a first draft, use Copilot when they need code, paste a spec into ChatGPT for a second opinion. This produces results. It is not infrastructure.

The difference between a tool and an agent is context. A tool does what you ask. An agent does what you mean, but only if it understands your project, your naming conventions, your definition of done, your team structure, your art pipeline review stages. And here’s the problem: every session starts from zero. The agent knows nothing. You brief it again. You explain the ticket hierarchy. You describe the LiveOps calendar. You clarify what “approved” means in your pipeline. Every time.

That briefing cost is invisible until you add it up. Every session you spend re-deriving state that should already exist is a session you didn’t spend building. The producers getting compound returns from AI aren’t better at prompting. They’ve built the layer that makes re-briefing unnecessary.

That layer has a name. Most people building it haven’t given it one yet, which is part of why it keeps getting built in fragments rather than as a system.

The three layers

Every game production has two layers that people can name without thinking. The first is deliverables: features, specs, assets, tickets, design documents: the actual output. The second is process: Kanban, ceremonies, reviews, handoffs, the system governing how deliverables get made and shipped.

The third layer is newer, and most studios don’t have it. Call it the Production Context Stack: the configuration and context you build around the model so an agent is productive in your specific production context.

The Production Context Stack is infrastructure. Version-controlled, agent-readable, maintained like any other critical project asset.

The distinction matters practically. Tools get bolted on. Infrastructure gets built in. A producer who opens Claude each morning and briefs it from scratch is using a tool. A producer whose agent loads the project constitution, inherits the domain rules, and picks up where yesterday’s session ended is working with infrastructure.

The gap between those two experiences compounds over time. The first producer gets faster answers to individual questions. The second gets a system that accumulates institutional knowledge, maintains consistent conventions, and applies domain expertise without being taught it again each session. The production itself becomes a training environment, not for the model, but for the configuration around it.

Most producers who’ve been building seriously with AI for more than six months have started forming the third layer without recognising it as a category. A prompts folder they version-control. A naming conventions doc they paste into every session. A shortlist of trusted instructions they’ve learned through trial and error and now treat as standing rules. These are proto-Production-Layer artefacts. They’re working. The gap is usually three things: the pieces aren’t connected, they’re not maintained on a deliberate schedule, and they’re not designed to be read by an agent rather than a human.

What the Production Context Stack consists of

The layer has seven components. They don’t need to be built simultaneously, but they have dependencies: the usefulness of each increases as the others exist.

1. Project Constitution

The durable, authoritative instruction file the agent reads at the start of every session. Ground rules, team structure, naming conventions, standard operating procedures, and the hard rules governing how the orchestrator behaves.

Three properties matter here. First, it’s version-controlled alongside your deliverables, not stored in a notes app or held in someone’s head. Second, it’s loaded fresh every session: updating it immediately changes agent behaviour across all future runs, no redeployment or restart required. Third, it defines the orchestrator constraint: the top-level agent routes and delegates, but never does substantive work directly. That single rule keeps the context window clean and the outputs auditable.

Think of it as the answer to one question: if an agent joined this production today with no briefing, what would it need to know to work correctly?

2. Domain Rules

Standing instructions for specific contexts: how you write specs, how the art pipeline review process works, what “done” means for a ticket at each stage, your LiveOps vocabulary, your localisation conventions. A domain rules file is a reference file any agent inherits automatically when working on a relevant task.

The practical difference between domain rules and a prompt is maintenance. A prompt lives in your head or in a notes doc. A domain rules file lives in version control, gets reviewed when the project changes, and accumulates institutional knowledge over time. When a new producer joins the team, domain rules files are their onboarding documentation. The work of writing them down pays dividends twice.

3. Specialist Definitions

Each domain gets its own agent file: identity, role, procedures, reference material, and rules. Creating the file creates the capability. Your roster extends by adding markdown files.

Model tiering matters here and saves real money at scale. Complex multi-file work warrants the most capable model. Standard design, engineering, and research tasks run on a mid-tier model. Administrative work (roster management, metadata updates, ticket triage) runs on a faster, cheaper model. A production generating hundreds of agent calls per day sees this difference in cost immediately.

The file is the hire. When you need a new specialist, you write their brief, and the capability exists.

When a task requires expertise the roster doesn’t cover, the system can research and create a new specialist file without requiring you to touch the core infrastructure. The roster is designed to grow with the production.

4. Coordination Layer

Multi-agent work needs a mechanism for passing work between specialists and back to you. The simplest version is a folder structure: deliverables queued for your review in one location, files moving between agents in another, completed items archived in a third.

A hook on session start checks for new files in the review queue and injects an alert into the agent’s context if anything is waiting. This creates an async notification system without polling, without a database, without a framework. Durable, inspectable, and version-controlled in git.

The coordination layer is where most producers who build multi-agent setups eventually spend their design attention, because it’s where the workflow bottlenecks surface most clearly. When the layer works, work flows. When it doesn’t, the agent does the right task in the wrong order and you don’t find out until too late.

5. Persistent Memory

Every agent starts a new session cold. Persistent memory is what gives it continuity without a database.

Each specialist has its own memory directory: preferences, prior decisions, project state, feedback corrections. A project-level index loads at session start, giving the orchestrator recall across conversations. Memory is typed (user preferences, project state, accumulated feedback, reference data) and stored as markdown files with metadata. When a session approaches the context window limit, the system compresses prior turns into a structured summary. The following session loads that summary and resumes.

A long workflow spanning multiple days progresses across sessions without the user re-briefing the system. That’s where the returns compound.

This is the component that most clearly separates working with an agent from working with a tool. A tool has no memory. An agent with persistent memory has accumulated context about your project, your preferences, and the decisions you’ve made. The longer you run it, the less you have to explain.

6. Tool Integrations

Your project management tool, wiki, and design tool are connected so agents can call them directly at the level of intent rather than infrastructure. An agent working in your PM tool operates on named actions (edit issue, create issue, search by query, transition status) rather than REST endpoints. No HTTP client code, no authentication handling, and no entire class of implementation error.

The scale consequence matters. Because each edit-issue call is independent, a specialist can fire dozens of API calls in a single pass. Reparenting fifty tickets, updating components, resetting fix versions: operations that would take a human project administrator close to an hour run in under two minutes. The pattern generalises to any task composed of independent, idempotent API calls.

7. Self-Extension

The mechanism that lets the system grow without touching core infrastructure. A specialist whose function is hiring other specialists. When a task requires expertise the roster doesn’t cover, this agent runs a two-phase process: research brief, then approval, then creates the agent file, updates the team profile, and initialises the memory stub.

Most producers skip this component. It’s the one that separates a static setup from a system that learns. A production is not a fixed domain. It changes scope, adds disciplines, hits unexpected technical problems. The Production Context Stack needs to grow with it, and that growth should cost one approval, not an afternoon of configuration work.

Building it

The instinct when reading a seven-component framework is to conclude it needs to be built all at once. It doesn’t.

Start with the Project Constitution. Get the ground rules, naming conventions, and process standards into one version-controlled file. Load it at the start of every session. That single change ends the re-briefing cycle for the most common context, your project’s identity, and starts the habit of treating your AI configuration as a maintained asset.

Add domain rules one context at a time. Start with the context where the agent gets things wrong most often. If it keeps misformatting your tickets, write a ticket rules file. If it consistently misses your spec structure, write a spec conventions file. Each file narrows the gap between what the agent produces and what your production requires.

Build the coordination layer when you add a second specialist. The folder structure takes an afternoon. The hook that injects review alerts takes another hour. Once it exists, the shape of multi-agent work becomes visible in a way it wasn’t before: you can see where work is, what’s queued, and what’s completed.

Persistent memory follows naturally. Once you have specialists and a coordination layer, memory is the next missing piece. It’s also the component with the longest return horizon: the first week, it saves you from re-explaining the same preference twice. After six months, the agent’s accumulated context of your project is a production asset in its own right.

Tool integrations come when you identify the manual task you do most often that an agent could run at scale. For most productions that’s ticket management. Connect your PM tool, write the intent-level instructions, and watch an afternoon of administrative work become a two-minute batch operation. Then find the next one.

Self-extension is the last thing to build, and the most optional. Most productions don’t need it until the roster is already working well. When you reach the point where you’re regularly creating new specialist files, automate the process.

Keeping it alive

The Production Context Stack needs an owner and a review cadence.

Review it every three to six months, and after every major model release. Delete rules written for a previous model’s limitations. A more capable model doesn’t need the guardrails you built because the last one kept making a specific mistake. Dead rules accumulate fast, and they degrade performance: the agent spends attention on constraints that no longer apply.

A standing session review (what worked, what didn’t, what the constitution should say differently) handles continuous maintenance. One owner handles the scheduled reviews. Those two inputs together address the two failure modes: drift from model improvement and drift from project change.

Add a third trigger to the review calendar: policy changes. Your organisation’s AI usage policy will evolve. If you’re delivering work to external clients, their policies may impose additional constraints on which tools you use, which data enters the context, and which integrations are permitted. The Project Constitution is the right place to encode those constraints. Check both sets of requirements when you build, and treat a policy update the same as a model release: a reason to review.

The competitive picture

The GDC 2026 survey found that around 30% of AAA studios now report using proprietary AI systems built on internal data and assets. Two years ago that number was much lower. The studios investing in proprietary infrastructure aren’t doing it because the models got better. They’re doing it because internal AI infrastructure encodes something external tools can’t replicate: your team’s conventions, your project’s domain, your accumulated decisions.

A January 2026 analysis by Aakash Gupta on the agent infrastructure landscape put it plainly: you can’t download this from a package repository. You have to build, test, fail, learn, and rebuild. The Production Context Stack is bespoke by definition. It gets more valuable the longer you maintain it. And it’s not transferable to your competition.

Leave a comment

Developers understood this first. The pattern is clear enough now that producers can follow it deliberately, rather than arriving at it by accident after a year of expensive iteration.

The model is commodity. The Production Context Stack is not.

• Claude Code Game Studios encodes a five-step collaboration protocol into every agent interaction: Question, Options, Decision, Draft, Approval

• This is not a code safety mechanism. It is a production discipline, and the distinction matters more than the repo’s 16,000 stars suggest

• The producer agent in the system is explicitly forbidden from making decisions. Its job is to quantify scope and surface trade-offs. That is textbook producer behaviour

• Producers have been running this protocol by hand for thirty years. The question is why it took this long for someone to write it into an AI system

A few days ago I wrote about Claude Code Game Studios, a GitHub repo that appeared last week with 49 specialised AI subagents, 73 workflow skills, and a studio hierarchy that mirrors real game development. I spent most of that piece on where the architecture falls short: the context window, the false independence of parallel reviewers, the markdown-as-institutional-memory problem. All of that stands.

Subscribe now

What I didn’t have room to say is that the repo accidentally got something right that almost nobody in agentic AI is getting right. And the reason it got it right is that it was thinking like a producer without knowing that’s what it was doing.

The protocol

Buried in the repo’s docs/COLLABORATIVE-DESIGN-PRINCIPLE.md is a five-step workflow that every agent must follow on every interaction:

Question. Options. Decision. Draft. Approval.

The agent asks clarifying questions before proposing anything. It presents two to four options with reasoning and trade-offs. The human decides. The agent drafts based on that decision. Nothing goes to file without explicit sign-off.

It is worth noting the structural similarity to John Boyd's OODA loop, the decision framework developed for fighter pilots: Observe, Orient, Decide, Act. The parallel is real, but the difference is the point. OODA assumes the observer and the decision-maker are the same person, moving fast under pressure. Q→O→D→D→A splits them deliberately. The agent observes, researches, and generates options. The human decides. That separation is not a limitation of the system. It is the system. Boyd was designing for a solo pilot in a cockpit. This protocol is designed for a producer with a team.

The README makes the principle explicit: “you still make every decision.” The CLAUDE.md configuration reinforces it: “Agents MUST ask ‘May I write this to [filepath]?’ before using Write/Edit tools.” This is not a suggestion. It is a constitutional constraint baked into every agent definition in the system.

Most people reading the repo are treating this as a cautious engineering choice. It is not. The repo has plenty of those: automated checks that run on every commit, rules that block dangerous commands, validation scripts that fire whenever an asset gets changed. Those are developer instincts applied to agent behaviour, and they are sensible. The Q→O→D→D→A protocol is doing something different. It is not preventing bad code. It is preventing bad decisions from being made by the wrong party.

That is a production instinct.

The tell

The producer agent in the CCGS system has a specific, hard-coded constraint that reveals everything about where this thinking came from.

It is forbidden from making design decisions. It is forbidden from making technical decisions. Its job, as written in the agent spec, is to “quantify the production impact in concrete terms” and “surface the conflict to the user with the scope implications clearly stated.” When the creative director and technical director disagree, the producer does not pick a side. It calculates how many sprints the disagreement will cost and puts the trade-off in front of the human.

The producer does not resolve conflicts. It prices them.

If you have worked in production, that sentence will land immediately. If you have not, it might read as a limitation. It is the opposite. The moment a producer starts resolving creative or technical conflicts instead of surfacing them, they have stopped being a producer and started being a bottleneck with a title. The CCGS producer agent is correct about its own role in a way that most descriptions of the producer role get wrong.

A developer who worried about AI agents going off-script would build automated validation. CCGS has that too, and it is clearly developer-authored. But a developer worried about AI agents going off-script would not think to write a rule that says “do not make the decision, price the decision and give it back to the human.” That is thirty years of production instinct encoded in a markdown file.

What happens when you skip it

I follow something close to Q→O→D→D→A in my own Claude Code work, mostly by habit. I ask before I let it write. I push for options before I commit to a direction. I approve file writes explicitly.

I did not always do this, and I have paid for the gaps.

The worst version of skipping the protocol is not an agent that writes the wrong file. It is an agent that confidently continues from stale context. In one session, old data crept in without my noticing. The agent had picked up assumptions from an earlier state of the project and started elaborating on them. By the time I caught it, those assumptions had propagated through several connected decisions. The cost was not just undoing the work. It was unpicking the scope implications, identifying everything the stale assumption had touched, and re-running the reasoning from the point where the corruption entered.

That is a familiar failure mode for any producer. It is what happens when a decision gets made in the wrong room, or by the wrong person, and nobody catches it until three sprints later when the dependencies start complaining. The Q→O→D→D→A protocol exists precisely to stop that from happening. The Question phase is the checkpoint where stale assumptions get caught. Skip it, and you are running without gates.

The question phase is the checkpoint where stale assumptions get caught. Skip it, and you are running without gates.

The autonomy narrative in agentic AI treats human checkpoints as friction to be eliminated. More speed, fewer interruptions, less oversight. The problem is that the checkpoints are not slowing the work down. They are the mechanism by which the work stays aligned with what the human actually wants. Remove them, and you get faster output and worse decisions.

Why this is a producer problem

The industry arrived at agentic AI from the developer side. When everything looks like a nail, the hammer is autonomy: how much can the agent do without asking, how far can it run before it needs a human. The Q→O→D→D→A protocol comes from a different trade entirely. The question it is answering is not how to reduce human input. It is how to protect the decisions that matter while still letting the agent handle the execution.

Producers have been thinking about that question since before AI was in the room. The whole job is managing the boundary between what the team executes and what the human with authority over the product decides. A producer who can answer the question “who approved this?” at any point in production is doing their job. A producer who cannot is not.

CCGS encodes that accountability in its agent architecture. Every write requires approval. Every direction change goes through a decision step. The --review solo flag that turns off director gates for a game jam is the production equivalent of “we’re in crunch, skip the full review, get it done.” The review intensity modes, full versus lean versus solo, are a recognition that the overhead of governance scales with the stakes of the work. That is not a developer’s model. Developers tend to want consistent standards regardless of context. Producers live in the trade-off space.

The implication is uncomfortable for a field that has mostly thought of producers as project managers with Jira access. If the most sophisticated agentic AI system currently available for game development had to solve its core governance problem by reaching for production thinking, then production thinking is not a soft skill adjacent to the real work. It is the architecture.

What this means now

The CCGS repo has over 16,000 stars. The discussion in its wake, on GitHub, on LinkedIn, in the AI newsletters that picked it up, is almost entirely about the technical achievement: 49 agents, 73 skills, three engine specialist sets. The Q→O→D→D→A protocol gets mentioned as a feature of the collaboration model. It is not a feature. It is the load-bearing wall.

Remove the protocol, and what you have is a collection of well-named agents that will confidently produce output based on whatever they last understood about your project. That is a faster way to build the wrong thing. The protocol is what makes the structure meaningful rather than decorative.

Leave a comment

For producers moving into agentic AI workflows, the lesson is not that CCGS is the right system to use. I went into the structural limitations of the current implementation in detail in a recent piece. The lesson is that the governance layer, the thing that determines who decides what and when, is not secondary to the agent design. It is the agent design. The engineers will build the capability. The producers are the ones who know how to build the constraint.

That combination is what the current moment actually needs.

• How a non-technical, dyslexic game producer uses Claude Code as a serious daily tool

• Why “explain this like I’m ten” is a power move, not an admission of failure

• The screenshot as interface: treating error output like a bug report you can’t read

• What you actually need to understand before agentic tools will work for you

When I write about Claude Code, I probably sound like someone who has a home server running Arch Linux and strong opinions about package managers. I want to set the record straight. I don’t know what Arch Linux is. I have no opinions about package managers. I have used a terminal for eighteen months and I remain, at best, an unreliable tenant.

Subscribe now

I am a game producer. I have been one for thirty years. I have shipped over twenty free-to-play titles, built production systems for studios with hundreds of people, and spent more time thinking about flow metrics and delivery cadence than most people consider healthy. I am not a developer. And I have dyslexia.

I mention both of those things together because they interact. Dyslexia is not, for me, primarily a reading problem. It is a processing problem. When I look at a wall of monospace text in a console window, my brain does not parse it the way yours might. Error messages, stack traces, dependency warnings. They blur. The structure disappears. I can read the individual words and still not extract what the text is telling me.

That is the starting point. Not a barrier I overcame. Just the context.

About 10% of the UK population is dyslexic. Around 73% of dyslexic employees have never received formal support at work. That second number does not surprise me. Dyslexia is one of those conditions that companies acknowledge in their inclusion policies and then forget about the moment the work is actually happening. The support that exists is mostly designed around documents and communication, not around the specific texture of technical work.

Claude Code is not designed as an accessibility tool. But for me, it functions as one.

Here is what my working session with Claude Code actually looks like.

I have a project running. Something goes wrong, or I need to do something I have not done before, or a process I kicked off produces output I cannot interpret. My first move is a screenshot. I take a picture of whatever is on my screen and I paste it into Claude Code. Then I write: “This is what I see. I don’t understand it.” That is the whole message. Sometimes I add: “What do I do next?”

That is not a workaround. That is my interface.

The screenshot as communication method probably sounds primitive to a developer. It is, in some ways. But it is precise. I am not trying to describe what I am seeing and introducing translation errors. I am showing it directly. Claude Code can read the screen. It tells me what the error means, what caused it, and what I should do. Then I do that thing. If I do not understand the instruction, I ask again.

“Read me step one like I’m a ten-year-old.”

I say this regularly. I say it without embarrassment. Because “explain it simply” is not a confession of stupidity. It is the most efficient path through confusion when you are stuck and time matters. The developers who pride themselves on wrestling with documentation and figuring it out the hard way are doing something admirable and something slow. I am not there to be admirable. I am there to ship.

Between Claude Code and the console, my role is cut and paste. I take the output from the console, paste it in. I take what Claude Code tells me to run, paste it into the console. I am the messenger. This is not an embarrassing admission. The reasoning is happening. The work is getting done. My value is not in my ability to memorise terminal syntax. It is in my ability to understand what I am building, why it should work, and what to do when it does not.

None of this means I skipped the foundations. I took the time, early on, to understand what these tools actually are.

What is a terminal? What is an agent? What is the difference between a model and a tool? Why does Claude Code need access to my file system? What happens when I run a command? I did not need to understand the implementation. But I needed to understand the concept well enough that I could make good decisions. That investment is not optional. You cannot successfully direct a tool you have no model of.

This is the line I think a lot of people miss. The promise of AI coding tools sometimes gets framed as: you do not need to understand anything, just talk to it. That is wrong. You need to understand the shape of what you are building. You need to know when something has gone sideways, even if you cannot diagnose it yourself. What you do not need is fluency in the syntax.

Those are different things.

I have built content generation pipelines, archive processing systems, project management integrations, and game prototypes, all using Claude Code as my primary development tool. None of those projects started as technical projects. They started as ideas I understood well enough to articulate. Claude Code handled the rest, with me asking questions at every stage and feeding error output back in whenever it appeared.

People with dyslexia have a 60% greater chance of connecting ideas through alternative methods, according to some research. I do not know if that is me. But I do know that my instinct, when faced with something I cannot read, is to find another way to communicate it. The screenshot. The plain-English question. The “explain it to me simply” request that developers sometimes feel is beneath them.

Those are not workarounds. They are methods.

Claude Code’s actual superpower, the one nobody writes about in the launch posts, is patience. It does not get frustrated when you paste the same error three times. It does not assume you know what it meant the first time. It does not care if your question has a typo in it. It adjusts when you tell it you did not follow.

For someone who has spent thirty years in environments that were not built for how my brain works, that is not a small thing.

I am not suggesting that Claude Code is a perfect accessibility tool, or that it solves the problems dyslexic professionals face at work. It does not. Most of those problems are structural, and they sit well above what any software can fix.

Share

But I am saying this: if you have been looking at Claude Code and thinking it is for developers, or for people who are more technical than you, you have misread the situation. The thing that makes it work is not syntax knowledge. It is the willingness to ask the question, however simple the question sounds, and to keep asking until you understand the answer.

I have been doing that for thirty years in meetings, reviews, and postmortems. The terminal is just a new room to do it in.

I genuinely did not think I would get here. A few months ago I thought I was done with this. I stepped away, told myself I had run out of things to say, and half-expected not to come back.

I was wrong.

I am back now, and I have more energy for this than I have had at any point since I started. There is a lot more to write.

To those of you who have been here from the beginning: I see you. You stayed when the readership was tiny and the posts were rough. That meant more than you probably know.

To everyone who has joined along the way: glad you are here too.

This newsletter has always been a conversation, even when it felt like I was writing into the void. If something lands, or frustrates you, or sparks an idea, say so. Comment, reply to this email, reach out directly. I read everything.

Here is to the next hundred.

Rob

Subscribe now

• The project organises 49 Claude Code subagents into a three-tier studio hierarchy that mirrors how real game teams actually work

• Its director gate system, path-scoped coding rules, and review intensity modes solve genuine coordination problems in intelligent ways

• But all 49 agents share one session context, session memory is a markdown file, and parallel “independent” reviewers are the same model running different prompts

• Understanding the gap between the architecture’s ambition and its constraints tells you something useful about where agentic AI actually sits right now

A GitHub repo called Claude Code Game Studios appeared about a week ago. By the time I found it, it had 16,000 stars and 2,400 forks. The pitch is direct: one Claude Code session, 49 specialised AI subagents, 73 workflow skills, a studio hierarchy mirroring real game development. Directors at the top, department leads in the middle, specialists at the bottom. Creative director guards the vision. Technical director owns the architecture. Producer coordinates across departments. Gameplay programmers implement stories. QA lead signs things off.

Subscribe now

I spent some time reading the repo carefully, not the README, but the actual implementation: the agent definitions, the skill workflows, the hooks, the director gate system, the coordination rules. It’s worth the time. The project is doing something genuinely interesting, and the places where it falls short reveal as much as the places where it works.

What’s actually there

The structure is clean. Agents are defined as markdown files with YAML frontmatter, carrying a name, description, permitted tools, model tier assignment, and a detailed system prompt. The three-tier hierarchy is real, not decorative. Directors run on Opus. Leads and specialists run on Sonnet. Read-only status checks get Haiku. That tiering reflects an actual cost/capability trade-off rather than a cosmetic decision.

The 73 skills are slash commands, each with their own SKILL.md file defining a multi-phase workflow. /dev-story is a good example to read in detail. It loads a story file, cross-references it against a technical requirements registry, finds the governing Architecture Decision Record, checks the control manifest for the story’s layer, validates dependencies, checks for manifest version staleness, routes to the right programmer agent based on story type and layer, spawns an engine specialist as a secondary agent when risk is flagged as high, collects results, and updates session state. That’s a serious piece of workflow design. It isn’t just “ask Claude to write some code.”

The director gate system is where the project gets genuinely clever. Rather than embedding gate prompts inside individual skills, it maintains a single director-gates.md reference with named gates: CD-PILLARS, TD-ARCHITECTURE, PR-SPRINT, QL-STORY-READY, and so on. Skills reference gates by ID. The Creative Director, spawned via a Task subagent, returns a structured verdict on its own line, [GATE-ID]: APPROVE or [GATE-ID]: CONCERNS, because the calling skill reads that line programmatically rather than parsing prose. That is tidy engineering.

The review intensity system shows genuine production thinking. Three modes: full (every director gate active at every step), lean (phase gates only, skip per-skill gates), solo (no gates, maximum speed). You set it once in a text file, override it per-run with a flag. A game jam does not need the same overhead as a pre-production milestone review. The project knows this and accounts for it.

Path-scoped coding rules are another quiet win. The rules directory contains eleven separate files, each scoped to a specific path pattern. gameplay-code.md enforces data-driven values, delta-time usage, no direct UI references. prototype-code.md relaxes everything and just requires a README with a documented hypothesis. These rules fire automatically when an agent edits files in the relevant directories. You do not have to remember to invoke them.

The collaboration protocol is the right instinct for agentic work: agents must ask “May I write this to [filepath]?” before any write operation. They must show drafts before requesting approval. Multi-file changes require explicit sign-off for the full changeset. The README puts it plainly: “you still make every decision.” In a year when agentic tools have repeatedly surprised developers by doing more than expected, encoding human-in-the-loop approval at the architectural level is the correct call.

Where it hits the wall

The context window is the problem that does not get solved.

The /dev-story skill asks Claude to simultaneously load: the story file, the TR registry at docs/architecture/tr-registry.yaml, the governing ADR, the control manifest, engine preferences, and the engine version reference. Then it spawns a programmer agent via Task, which carries its own context budget. If engine risk is flagged high, it spawns an engine specialist as a secondary. A medium-complexity game project will have a GDD for every system, multiple ADRs, a growing TR registry, and a growing epic/story directory. The context will compress constantly. The project ships pre-compact.sh and post-compact.sh hooks, and there’s an active.md session state file, but a markdown file is thin institutional memory for a system of this complexity.

This is not a criticism of the project specifically. It is the fundamental constraint every multi-agent Claude Code system faces right now. The project at least acknowledges it with the compaction hooks. But it does not solve it, and the skill workflows do not account for what degrades when context gets compressed mid-session.

Agents that ask before writing, show drafts before committing, and surface blockers before ploughing through them, are safer to work with than agents that sprint.

The second problem is the independence of parallel reviewers.

The director gate system is designed so that the Creative Director and Technical Director review a design simultaneously and independently, with the strictest verdict winning. In a real studio, that catches real errors, because the creative director has genuinely different knowledge, intuitions, and blind spots from the technical director. Here, both agents are the same model running different system prompt priming on the same session context. They share latent biases. They have read the same documents. A creative director spawned from Claude Sonnet and a technical director spawned from Claude Sonnet, both reading the same GDD in the same session, will not give you the same quality of independent review that two humans in different disciplines give you. They will probably catch formal and structural errors well. They will not reliably catch the errors that require genuinely different institutional knowledge.

The session memory problem is related. The project has a single MEMORY.md file in .claude/agent-memory/lead-programmer/. One file, for one agent, covering the entire project history. The creative director’s opinion about your crafting system from session four does not exist in session eight unless someone wrote it down correctly in session four. The producer’s risk log is only as good as what the producer wrote to disk before the session ended. Real studios carry institutional memory in human heads, in culture, in the relationships between people who have shipped things together. This system carries it in markdown files that agents read at session start. That is not nothing, but it is also not a studio.

Real studios carry institutional memory in human heads, in culture, in the relationships between people who have shipped things together. This system carries it in markdown files.

The third problem is the maintenance burden on the person the system is supposed to help.

The project targets solo and indie developers. The README says as much. But the system it delivers has 49 agent definitions, 73 skills with multi-phase SKILL.md workflows, 12 hooks, 11 rules, 41 document templates, three engine reference directories (Godot, Unity, Unreal) each with module-by-module API notes and deprecation logs, and an UPGRADING.md for managing migration between versions. Who maintains the engine reference docs when Godot 4.6 ships something relevant? Who keeps the 73 SKILL.md files accurate as Claude Code’s capabilities change? Who runs /skill-improve and /skill-test across the full catalog regularly?

A solo developer who lacks production discipline, which is the person this system is designed for, now has a meta-production system to maintain on top of the game they are trying to build.

The Microsoft Project problem, applied to Claude Code. The planning tool becomes the project.

What genuine value remains

Here is what I think the project actually delivers, as opposed to what it claims.

For a developer who has never worked in a structured production environment, the template provides a forcing function. The GDD templates are well-structured. The story lifecycle, readiness check into implementation into code review into story done, mirrors a real workflow. The design/, docs/, production/, src/ directory structure enforces separation between the game design artefacts and the code. The /gate-check command at phase transitions is a real accountability moment, even if the reviewers are not truly independent.

The collaboration protocol is valuable in ways that go beyond gate theatre. Agents that ask before writing, show drafts before committing, and surface blockers before ploughing through them, are safer to work with than agents that sprint. The explicit --review solo mode for game jams is practical. The path-scoped rules that apply different standards to prototypes/ versus src/ are the right model for how coding standards should work in a game project.

The engine knowledge gap documentation is addressing a real problem. Claude’s training cutoff means it does not know whether a Godot API changed in the last release, or whether a Unity plugin deprecated a key function. The engine reference directory, with version numbers and a knowledge cutoff acknowledgment per engine, is the right shape of solution even if the manual maintenance burden is significant.

The project has over 16,000 GitHub stars five days after launch. That is signal. The idea of structured agentic game production is clearly resonating with people who have hit the limits of open-ended vibe-coding on a big project and want something with more scaffolding. The hunger for this kind of structure is real.

What this tells you about agentic AI right now

Claude Code Game Studios is worth studying not because it fully works, but because it is one of the most honest attempts I have seen at mapping what agentic AI can currently do in a complex creative production context.

It works where structure provides value regardless of whether the agents are truly independent: forcing documentation, enforcing coding standards by path, creating a collaboration protocol that requires human approval. These things help even if the underlying model is the same in every agent.

It strains where the gap between the metaphor and the mechanism is largest: context that collapses under the weight of a real project, reviewers who share more than they should, memory that lives in files that have to be managed. These are constraints of where the technology sits in mid-2026, not permanent features of the architecture.

Leave a comment

The project’s ambition is running slightly ahead of the tools. That is not unusual. The interesting question is whether the structure it imposes now, while the tools are still catching up, produces better games than the alternative. My guess is that for a certain kind of developer on a certain kind of project, it probably does. For others, the meta-system overhead will outpace the benefit.

The only way to find out is to ship something with it.

• Researchers who tore apart Claude Code’s source code found it’s 98.4% deterministic infrastructure and 1.6% AI decision logic

• In March 2026, Claude Code degraded for six weeks. The model didn’t change. Three infrastructure changes did.

• The producer’s job has always been this ratio: build the conditions for good decisions, not make every decision yourself

• The producers building the surrounding system are running a fundamentally different operation to those still prompting

Researchers at Mohamed bin Zayed University of AI just published a 46-page teardown of Claude Code’s TypeScript source. They counted what’s actually in there. The model, the AI reasoning layer, the part that actually “thinks”? That’s 1.6% of the codebase. The remaining 98.4% is deterministic infrastructure: permission gates, context pipelines, compaction layers, recovery logic, tool routing.

That number lands differently if you’re a producer.

Subscribe now

What surrounds the model

The 98.4% has a name. In agent system design, it’s called the harness. It’s everything that surrounds the model: the structures that determine what information the AI sees, what actions it’s permitted to take, what happens when something goes wrong, and how the system recovers without interrupting the human.

In Claude Code, the model never directly touches the filesystem. It never runs a shell command on its own authority. Every action it proposes passes through layers of deterministic infrastructure first. Permission rules. Safety classifiers. Sandboxing. Context management pipelines that run five separate compression strategies before every model call, each cheaper than the last, escalating only when the previous layer wasn’t enough.

The model reasons. The surrounding system enforces, routes, recovers, and manages constraints. The researchers described the design philosophy plainly: the harness creates conditions under which the model can decide well, rather than constraining its choices.

That sentence is worth sitting with.

Because the inverse is also true. A badly designed surrounding system creates conditions under which even a capable model decides poorly. The model is not the variable. The infrastructure is.

When the surrounding system breaks

In April 2026, Anthropic published a postmortem explaining why Claude Code had felt noticeably worse for the previous six weeks. Users across GitHub and Reddit described what they called “AI shrinkflation.” The model felt less intelligent, more repetitive, prone to choosing the simplest fix rather than the correct one.

The model hadn’t changed. Three infrastructure changes had.

On 4 March, Anthropic lowered Claude Code’s default reasoning effort from high to medium to reduce UI latency. On 26 March, a caching bug caused the model’s reasoning history to be wiped on every subsequent turn instead of just once after an hour of inactivity. On 16 April, a system prompt addition capping responses at 25 words between tool calls caused a measurable drop in coding quality. Three separate infrastructure decisions. None of them touched the model. All of them changed what users experienced as the model’s intelligence.

Because each change affected a different slice of traffic on a different schedule, the aggregate effect looked like broad, inconsistent degradation. Users blamed themselves. Wrong prompts, wrong approach. One AMD engineer published an exhaustive audit of 6,852 Claude Code session files and 234,000 tool calls, documenting that reasoning depth had collapsed. Third-party benchmarks measured Opus 4.6’s accuracy dropping from 83.3% to 68.3%. Anthropic’s ranking among production coding models fell from second to tenth. The raw API, hitting the model directly without the Claude Code layer, was unaffected throughout.

The model was fine. What surrounded it wasn’t.

This is the clearest demonstration I’ve seen of something the research paper makes explicit but most producers haven’t internalised. The surrounding system is not a wrapper around capability. It is a significant portion of the capability itself. Change it and you change the outcome, whether or not a single model weight has shifted.

The ratio producers already know

Here’s what experienced producers will recognise in that 98.4%.

The best producers I’ve worked with don’t spend most of their time making calls. They spend it building the conditions under which good calls get made reliably, by the right people, with the right information, at the right point in the process. Milestone structures. Escalation paths. The discipline of deciding what information reaches the team, and when, and in what form. Permission models that specify who can approve what without asking upward. Recovery procedures for when things go sideways, so the project doesn’t stall waiting for a human to unblock something that could have been handled automatically.

That’s the 98.4%. It just doesn’t have that name in game production.

The producers who struggle with AI workflows are often the ones trying to get the ratio backwards. They build decision scaffolding. They prompt-engineer every interaction. They sit in the loop for each action, approving, redirecting, correcting. They’re doing the 1.6% work while leaving the 98.4% unbuilt. The result is an AI that feels unreliable, because it is. The infrastructure isn’t there to make it reliable.

The model will do what models do. Everything else is yours to build.

A production team works the same way. The producer who has to approve every asset, attend every standup, and unblock every dependency hasn’t built a production system. They’ve built a bottleneck with good intentions. The work still gets done. It just goes through them every time, which means it only moves as fast as they can clear the queue.

The fix, in both cases, is the same. Build the structure that lets the right output happen at the right level without constant intervention. Then get out of the way.

The thing that changed for me

The lightbulb moment, for me, was not about capability. It was about something more specific.

For most of my career, getting work done well has involved other people. That’s mostly a feature. Cross-discipline experience improves the work. Different perspectives catch things you’d miss. But working through other people also means negotiating assumptions. Someone arrives with ideas about how it should be done, formed at a previous studio. Someone else defaults to the format they’re comfortable with rather than the one you specified. You ask for X, you get something adjacent to X, shaped by whoever made it and what they thought you probably meant.

With a well-built surrounding system, that stops happening.

The first time I ran a spec authoring workflow where the output matched exactly what I’d specified, with no interpretive drift and no unasked-for opinions about how they used to do it somewhere else, I found it disorienting. The deviations that did exist were mine to fix, not someone else’s to defend. There was no negotiation. No “I thought you meant...” No prior studio habits quietly baked into the output.

I value other people’s input. Most of the time it makes the work better. But sometimes you want what you want, without it going through someone else’s prior experience first. A well-built surrounding system gives you that option.

What made it possible was not the model. It was what I’d put around it: context documents that specified the format precisely, scope limits that kept the agent inside the brief, output standards that left nothing to interpretation. The agent wasn’t guessing at what I wanted. It was executing against a spec. The spec was mine, unmediated.

That’s the operational infrastructure. The model just ran inside it.

What to actually build

The research paper identifies several layers in Claude Code’s surrounding system: context assembly, permission rules, memory hierarchy, tool routing, and a five-stage compaction pipeline that manages what the model sees at any given moment. For producers building their own agent workflows, the equivalent work looks like this.

Context architecture. What does the agent know, and in what order does it learn it? Your GDD, naming conventions, milestone structure, output format standards, all of it needs deliberate structure. The agent needs to know which document is authoritative and which is reference material. This is information architecture work, and producers already do it. The difference is the audience.

Scope and permissions. What can the agent touch, and what is it not permitted to touch? This is a quality question as much as a safety one. An agent without clear scope fills gaps with assumptions. Clear boundaries keep the output inside the territory you’ve defined. Scope that’s too broad produces work that’s technically correct and contextually wrong.

Output standards. What does good look like? Not in general terms. For this deliverable, in this workflow, at this stage. Agents don’t have taste. They have context. Give them enough of it and they’ll execute reliably. Give them too little and they’ll interpolate from training data that may not match what you actually want.

Recovery procedures. What happens when the output is wrong? The question most producers skip is not how to correct it manually but how the system catches it without your manual intervention. This is the difference between a workflow and a process you have to babysit.

None of this is prompting. It’s system design. The prompting is the 1.6%.

Leave a comment

Anthropic’s postmortem ended with a list of internal changes the company committed to: a larger share of staff using the exact public build, broader evaluation suites for every system prompt change, tighter controls on what gets deployed and when. Every item on the list is an infrastructure decision. None of them involve changing the model.

The producers who understand that ratio are not using AI better than everyone else. They’re building something structurally different.

• When something goes wrong in an agent workflow, engineers add a constraint. Producers fix the brief. These are not the same response.

• The Claude Code architecture paper validates the producer approach: minimal decision scaffolding, maximal operational infrastructure

• An engineer’s system accumulates constraints over time. A producer’s system accumulates clarity. One gets more rigid; one gets better.

• Vibe-production is not a low-structure mode. It’s what the right mental model looks like in practice.

When something goes wrong in an agent workflow, engineers and producers do different things.

The engineer adds a constraint. A rule, a conditional, a state node, a tighter prompt. The mental model is that the agent is an unreliable function that needs to be pinned down. It did the wrong thing, so you restrict what it can do next time. The fix lives in the code.

Subscribe now

The producer asks what the agent didn’t know. Or what it wasn’t clear on. Or whether the scope was tight enough to prevent it from drifting. The mental model is that the agent is capable but underinformed. It did the wrong thing because the conditions weren’t right, not because it needed a shorter leash. The fix lives in the brief.

Those are not different tactics. They’re different operating philosophies, and they produce structurally different systems over time.

How engineers build agent systems

LangGraph is the clearest expression of the engineering instinct. It models agent workflows as directed graphs: nodes for each state, typed edges for each transition, explicit decision logic at every branch point. The developer defines exactly what the agent can do at each step, what it can do next, and what happens when specific conditions are met. Control is the design goal. Predictability is the design goal. The agent’s autonomy is precisely bounded by the graph.

This is good software engineering. State machines are a solved problem. Finite, auditable, testable. When something breaks you can trace it to a node. When something needs to change you update the edge. The system is explicit about everything.

It is also, in the framing of the research paper that tore apart Claude Code’s source architecture, the opposite of what the most capable production agent systems actually do.

The paper contrasts Claude Code’s approach directly with LangGraph and systems like it. Claude Code uses a single reactive loop. The model reasons about what to do, the surrounding infrastructure handles execution, permission checking, context management, and recovery. There are no explicit state graphs constraining the model’s choices. There is no developer-defined decision logic routing the model from node to node.

The design bet, stated plainly in the paper: increasingly capable models benefit more from a rich operational environment than from frameworks that constrain their choices.

That is not how an engineer’s instinct reads the problem. And it is exactly how a producer’s does.

How producers build agent systems

A producer’s mental model for a team member is not a state machine.

You don’t manage a designer by defining every possible state they can be in and specifying which transitions are permitted. You brief them. You tell them what good looks like. You give them the context they need to make the right call without asking you first. You define the scope clearly enough that their judgment operates inside the territory you’ve agreed on. When something goes wrong, the first question is whether the brief was clear, not whether you need tighter rules.

This is so instinctive to producers that most don’t think of it as a method. It’s just how you work with people.

It turns out it’s also how you work with agents.

When my agent workflows produce wrong output, the fix is almost never to add a constraint. It’s to look at what the agent was working with. Did it have the right context document? Was the output format specified precisely enough, or was it left to interpretation? Did the scope allow it to make a judgment call where I should have made a decision in advance?

The answer is usually one of those three. I update the brief. The next run is better. I didn’t write any code. I didn’t add a rule. I clarified the conditions.

The engineer’s system grows by accumulating constraints on what the agent can do. The producer’s system grows by accumulating clarity about what good looks like.

Those trajectories diverge fast. The constraint-based system gets more rigid as rules multiply, harder to change, more brittle when the task changes shape. The clarity-based system gets more reliable as the brief sharpens, more adaptable, because clearer conditions work across more situations than narrow rules do.

What the research validates

The Claude Code paper identifies thirteen design principles behind the architecture. One of them is called “minimal scaffolding, maximal operational harness.” The description: invest in the infrastructure that lets the model reason freely, not in scaffolding-side reasoning that constrains its choices.

The paper estimates that roughly 1.6% of Claude Code’s codebase is AI decision logic. The remaining 98.4% is deterministic infrastructure: context assembly, permission rules, recovery logic, tool routing, compaction pipelines. None of that infrastructure tells the model what to decide. It creates the conditions under which the model can decide well.

The contrast with LangGraph is explicit. LangGraph “encodes decision logic as explicit state graphs with typed edges, choosing scaffolding over minimal harness.” Claude Code does the opposite: “the harness creates conditions under which the model can decide well, rather than constraining its choices.”

Anthropic built one of the most widely used production coding agents in the world on the producer’s mental model. Not because producers were consulted. Because the model’s capabilities had advanced to the point where constraint-based design was the wrong tool. The model doesn’t need a shorter leash. It needs better conditions.

This is the structural advantage that producers bring to agentic AI, and most of them don’t know they have it.

Why the difference compounds

The March 2026 Claude Code regression is instructive here, even for producers building their own workflows rather than using Claude Code directly. Anthropic published a postmortem confirming that three infrastructure changes had degraded the system for six weeks. None of them added constraints. They removed conditions: less reasoning time, lost reasoning history, truncated responses. The model’s capabilities hadn’t changed. The environment it was operating in had gotten worse.

Anthropic’s fix was not to add more rules. It was to restore the conditions. Revert the reasoning effort. Fix the caching bug. Remove the verbosity cap. Put back what had been taken away.

The engineering instinct, faced with a system behaving badly, is to add control. The production instinct, faced with a team member behaving badly, is to check the conditions first. Are they missing context? Are they unclear on the scope? Do they understand what good looks like?

Those instincts produce different responses to the same problem. In the Claude Code case, and in most agent workflow failures I’ve seen, the production instinct is the correct one.

What this looks like in practice

I’ve written before about vibe-production as a distinct way of working with agents. The producer-vs-engineer contrast gives me a more precise way to define it.

Vibe-production is not low-structure work. It’s a specific structure. The investment goes into the brief: context documents, output standards, scope definitions, permission models. The agent then operates inside that brief with significant autonomy. You review the output. You refine the brief. You don’t add rules unless a rule is genuinely what the situation requires, which is less often than you’d think.

I direct agents the way I’d direct a senior team member on a tight brief. I don’t specify every step. I specify the destination, the format, the constraints that are genuinely constraints, and the context they need to get there without asking me. When the output is wrong, I look at the brief before I look at the agent.

This works because capable models, briefed well, make good decisions. They don’t need a state graph. They need to know what you actually want.

The producers who haven’t figured this out yet are building agent workflows that feel like managing a difficult contractor: constant correction, constant intervention, outputs that never quite match the spec. The problem is almost never the model. It’s that the brief is doing work it isn’t equipped to do, and the conditions that would let the model succeed on its own haven’t been built.

The producers who have figured it out are running something closer to a well-briefed team on a clear project. The agent executes. They review. They sharpen the brief. The system improves without getting more complicated.

Leave a comment

The engineering instinct and the production instinct are both coherent. For constraint-based problems with predictable shapes, state machines are the right tool. For open-ended work with capable models, they’re the wrong one.

The research says so. The architecture of the most capable production agents says so. Thirty years of production practice says so, for anyone who was paying attention to what they were actually doing.

The structural advantage was there the whole time. Most producers just hadn’t needed to name it yet.

• Nick Allan’s London Games Festival warning to swerve generative AI targets a use case that is roughly one-fifth of how the industry actually uses it

• GDC 2026 State of the Game Industry data shows 81% of devs using AI deploy it for research and brainstorming, only 19% for asset generation, only 5% for player-facing features

• Allan’s claim of “no IP ownership” in AI-generated work is overstated even in his home jurisdiction, where Section 9(3) of the CDPA grants 50-year copyright to computer-generated works

• The legal defensibility argument against vibe-coding ignores that game cloning lawsuits do not turn on source code copyright

Nick Allan, partner and head of video games at Mishcon de Reya, told an audience at London Games Festival to avoid using generative AI to produce key assets. Game Developer’s Chris Kerr summarised the tenor of the talk as advice to swerve genAI like the plague. The number to set against that advice is nineteen.

Subscribe now

That is the percentage of game industry professionals using AI tools who are using them for asset generation, according to the GDC 2026 State of the Game Industry survey published in January. Eighty-one percent are using AI for research and brainstorming. Forty-seven for code assistance. Five percent for player-facing features. Allan’s warning targets the part of the surface area that is, by some distance, the smallest.

Before getting into where the framing comes apart, one part of his talk earns its place. Allan told indie devs that any IP created by people who aren’t employees, by which he means contractors, freelancers, and external developers, is probably not going to be owned by the studio. It will be owned by them. He is right, and this catches indie devs out repeatedly. The default position under both UK and US law is that contractors retain ownership of what they create unless there is a written assignment, regardless of whether the studio paid in full. Specialist game lawyers have been making this point year after year, and I have seen it bite small studios more than once. If Allan’s whole talk had been about that one issue, it would have been a more useful piece of journalism than the one Game Developer published.

But on generative AI specifically, the framing falls apart in three places.

The nineteen percent problem

The GDC survey is the closest thing the industry has to a representative snapshot. Over 2,300 professionals responded. Across the full population, thirty-six percent said they use generative AI as part of their job. That headline number is the one most coverage focused on. The interesting numbers are inside it.

Of those thirty-six percent, here is what they are doing with the tools. Eighty-one percent for research and brainstorming. Forty-seven for code assistance. Forty-seven for writing emails. Thirty-five for prototyping. Twenty-two for testing and debugging. Asset generation comes in at nineteen. Procedural generation at ten. Player-facing features at five.

Asset generation: nineteen. Procedural generation: ten. Player-facing features: five.

The IP question Allan is warning about applies most directly to the bottom three of those numbers. It applies barely at all to the top five.

There is a reason the breakdown looks like that. Generating a key character, a background environment, a piece of music, or a story bible with a prompt and shipping that artefact as the studio’s IP is the use case where the legal risk Allan flags is most relevant. Using a model to interrogate a design decision, scaffold a piece of code, write a meeting summary, or produce a test plan is a different activity. None of those outputs are claimed as the studio’s copyright in the first place. There is nothing to register, nothing to defend, nothing to lose.

Half the industry has decided generative AI is having a negative impact on game development, up from thirty percent the year before and eighteen the year before that. Seven percent think the impact is positive. Those numbers are real and worth taking seriously. But the same survey shows that the people most opposed to genAI on principle are not the people who have stopped using it. They are using it. They are using it cautiously, and for the things where they think the trade-off is worth it. Research, brainstorming, code assistance, prototyping. The legal advice to swerve the technology assumes a use pattern that the data does not support.

Two risk profiles

A lawyer’s job is to minimise litigation risk. That is what they are good at. That is what their clients pay them for. When a specialist video games partner at a Tier 1 firm tells a room of indie devs to avoid generative AI, he is making the right recommendation against the risk profile he is paid to optimise.

A studio’s job is different. Studios survive or die on shipping velocity, runway management, and parity with competitors who are using the same tools. The risk a studio is optimising against is whether it will still exist in twelve months. Litigation in three years is somewhere lower on the list.

These two risk profiles point in different directions when it comes to genAI tooling. A studio that swerves AI to preserve theoretical IP defensibility is paying a real shipping-velocity cost to mitigate a hypothetical legal cost. The first cost shows up on the burndown chart this sprint. The second cost might never arrive at all, and if it does, will arrive in a form the studio will not be in business to face.

Reporting after GDC noted that adaptability to AI tools is becoming a hiring prerequisite, with job listings in 2026 considerably more likely to mention AI proficiency than they were a year earlier. Thirty-five percent of studios are now relying primarily on self-funding. The market is tighter, the runway is shorter, and the studios still standing have the most reason to take the productivity gains AI tooling actually delivers, rather than worry about hypothetical IP exposure that may never crystallise.

This is what I mean when I say legal advice and studio survival are pointing in different directions. They address different risks. They cannot be optimised together by the same heuristic. A studio that takes Allan’s advice without filtering it for relevance is solving the wrong problem.

Allan said that “most jurisdictions will just say there’s no IP ownership” in AI-generated work. Kerr did not push back on this in the article. It is worth pushing back on. Allan and his audience were both based in the UK, and the UK is one of the few jurisdictions on earth that does grant copyright to computer-generated works without a human author.

Section 9(3) of the Copyright, Designs and Patents Act 1988 provides fifty-year copyright protection to literary, dramatic, musical or artistic works “generated by computer in circumstances such that there is no human author of the work.” Authorship is attributed to “the person by whom the arrangements necessary for the creation of the work are undertaken.” The UK government’s own consultation paper notes that for a general-purpose AI generating output from a prompt, “the author will usually be the person who inputted the prompt.” The UK is one of perhaps four major jurisdictions globally with this kind of provision, alongside Ireland, India, and Singapore. Most of the rest of the world, including the US, has no equivalent and treats fully AI-generated work as uncopyrightable.

The UK is one of the few countries on earth that does grant copyright to computer-generated works without a human author.

The provision is contested. The government consulted on it between December 2024 and February 2025 and received over eleven thousand responses. It may be repealed. But it is currently the law, and a London-based partner addressing a London audience telling them there is no IP ownership in AI-generated work is glossing over the bit of the law that contradicts him.

What cloning lawsuits actually turn on

Allan’s other genAI argument concerned source code. Using a tool like Claude to vibe-code a video game, he said, will not necessarily create an ownership issue, but if someone copies your source code, “you probably wouldn’t be able to sue them in the way that you would if it had been written by human beings.”

This is technically arguable. It is also practically irrelevant for the vast majority of game studios.

Game cloning lawsuits do not turn on source code copyright. They turn on audiovisual look-and-feel, trade dress, character likeness, and trademark. The leading authority is Tetris Holding LLC v Xio Interactive Inc (2012), where Tetris won on the protectable expression of the game’s visual elements and the trade dress of its piece colours, playfield ratio, and packaging. The court explicitly distinguished protectable expression from unprotectable rules and functionality. Xio’s source code was never the issue.

The same pattern holds across the canonical game cloning cases. Spry Fox v LOLApps (Triple Town v Yeti Town, 2012) followed Tetris reasoning before settling. Atari v Amusement World (1981). Capcom v Data East (1994). The Fortnite dance emote suits. All of them turned on expressive elements. None turned on source code.

There is a structural reason for this. Source code is rarely accessible to a cloner in the first place. Compiled game binaries do not include readable source. Cloners are looking at the running game from the outside, screenshotting it, prototyping a copy of what they can observe, and rebuilding the implementation from scratch. The thing being copied is the audiovisual surface, not the codebase. Source code copyright is the wrong tool for the job because the situation in which it applies almost never arises. A studio worried about clones is worried about the trade dress, the character art, the music, the iconic mechanics expressed as visible behaviour. None of those are at additional legal risk because the underlying code was scaffolded by Claude.

Here is the point. If your studio’s competitive moat depended on source code copyright, you would have a problem. But it does not. The moat for any small studio is execution speed, brand, and the audiovisual expression you ship around the code. The legal defensibility argument against vibe-coding solves for a category of risk that does not exist for small studios in the games space. It is solving the wrong problem twice over: once for being targeted at the wrong type of asset, and once for being relevant to a kind of dispute that does not happen.

Where the moat actually sits

What survives all this is a smaller, sharper version of Allan’s advice. The contractor IP point is right, and indie studios should fix it on Monday morning. Trademark in your core markets is cheap and obvious. Avoid Ferraris and real-world logos in scenes you can replace with originals. None of this is new. All of it is bedrock. All of it gets ignored.

Where the framing comes apart is the genAI specific advice. The legal exposure on AI-generated assets is real for the nineteen percent doing asset generation and the five percent doing player-facing features. Those teams should think carefully about which outputs they treat as protectable studio IP and which they ship behind the work of human creators who can take authorship of the final form.

I have been in this fight. On a recent cricket project for a client extremely averse to infringement risk, the generated outputs kept producing real-world brand logos because the models had been trained on millions of images of actual cricket. Logos ghosted into helmet stickers, shirt sponsors, sightscreens, anywhere a real broadcast frame would carry them. I spent more time than I would have liked correcting them out in post. None of it was even for production assets. It was material going in front of the client. The risk Allan describes is real for this slice of the work, and managing it means clean-up workflows, prompt discipline, and human authorship layered over the generated output. The fix lives in the workflow.

Leave a comment

For everyone else using AI for the things the data shows they are using it for, the swerve costs more than it saves. The competitive advantage in this market is in the scaffolding around the model. The skill files, the prompts, the orchestration, the pipeline glue, the choice of when to call which model on which problem.

The moat is in the scaffolding around the model.

Almost none of that scaffolding is what Allan was warning about. Almost none of it is at legal risk. The studios that confuse one risk for the other will spend the next twelve months losing on shipping velocity to the studios that don’t.

I am not an attorney. This piece is a producer’s read of the debate, not legal counsel. If you are making real decisions about your studio’s IP, hire a specialist.

• 52% of game industry professionals think generative AI is bad for the industry, up from 18% two years ago

• Layoffs have hit junior roles hardest. Studios are having seniors absorb the work that used to develop junior talent

• The paradox of supervision: you need craft to supervise AI well, and AI is eliminating the work that builds craft

• Nobody is building a replacement pathway. Nobody is admitting that yet either

“Everyone is just having seniors do the work.”

A veteran game developer at Xbox said that to Wired earlier this year. It was offered as an observation about how studios are coping with layoffs and AI adoption simultaneously. It sounds like pragmatism. It sounds like studios making do. It isn’t. It’s a description of a pipeline eating itself.

Subscribe now

What the industry thinks the problem is

The 2026 State of the Game Industry report, based on responses from more than 2,300 professionals, found that 52% of game industry workers now think generative AI is having a negative impact on the industry. Two years ago that figure was 18%. Only 7% think it’s having a positive impact, and that number has declined every year since tracking began.

The fears driving those numbers are real. Job displacement. Creative erosion. A quality floor that keeps dropping as AI-generated content floods storefronts. Studios using AI to justify headcount reductions they were planning anyway. These are legitimate grievances and they deserve serious attention.

But they’re pointing at the wrong problem.

The conversation the industry is having is about what AI takes away now. The conversation it isn’t having is about what AI takes away over the next ten years, quietly, from a generation of developers who never get the chance to become senior.

The paradox of supervision

Research into AI-assisted software development produced a finding that should make anyone who manages creative teams uncomfortable. Developers working with AI assistance scored 17% lower on code comprehension tests than those working without it. The more work they delegated to AI, the less capable they became of supervising the AI’s output. The researchers called it the paradox of supervision: the tool that amplifies your capability today degrades the capability you need to use it well tomorrow.

Game production has the same structural problem. Possibly worse. Code comprehension is at least testable. Production judgment isn’t. You can’t give a producer a comprehension test and find out whether they actually understand what a schedule is telling them, or whether they’re pattern-matching on surface features and calling it instinct.

Production judgment is built through accumulation. A specific kind of accumulation: doing things badly, recovering from them, and carrying the scar tissue forward.

What junior production work actually builds

I’m not going to romanticise the entry-level production experience. It’s mostly unglamorous. Chasing people for updates. Maintaining schedules nobody reads until something slips. Running triage meetings where you make calls on incomplete information and find out two weeks later whether you called it right. Preparing milestone builds and having a lead tell you that what you thought was done isn’t.

But that accumulation installs something. Dependency tracking you let slip and had to claw back teaches you what a schedule is actually measuring, which is risk, not time. Bug triage under pressure teaches you to make decisions without complete information and live with the consequences. Milestone preparation where someone pushes back on your definition of done teaches you the difference between activity and progress. Stakeholder communication when a project is in trouble teaches you to read what people aren’t saying.

None of that knowledge transfers through observation. You don’t get it by watching a senior producer do it. You don’t get it from a postmortem or a course or a framework document. You get it by doing it badly enough that it costs you something, and then doing it again.

That’s the pipeline. That’s always been the pipeline. Thirty years in production is thirty years of recoverable mistakes compounding into judgment.

“You don’t get it by watching a senior producer do it. You get it by doing it badly enough that it costs you something, and then doing it again.”

The pipeline is now broken from both ends

Here’s what’s happening structurally. Layoffs across the industry have disproportionately hit junior roles. 28% of the professionals surveyed in the GDC report were laid off in the past two years, rising to 33% for US-based workers. The roles that went first were the ones at the bottom: coordinators, associate producers, junior designers. Studios responded to the capacity gap by having seniors absorb the work. Which is where the Xbox developer’s observation comes in.

At the same time, AI is handling an increasing share of the work that used to sit at the junior level. Scheduling support. Documentation. Status reporting. Research and brainstorming. The GDC report found that the professionals most likely to use generative AI are business professionals and upper management, not rank-and-file developers. The tool is being adopted most enthusiastically by exactly the people who already have the judgment to supervise it, and applied most directly to the work that used to build that judgment in the people coming up behind them.

Junior roles are being eliminated from above by layoffs and from below by automation. What’s left is a generation of people entering the industry with fewer opportunities to do the painful, developmental work that produces senior producers.

The question nobody is asking

The industry’s anger about AI is focused on the present. Whose job does it take. What it does to creative work. Whether it degrades quality. All worth debating.

The question that isn’t being asked is ten years out. Who supervises the AI in 2036? Not in the abstract sense, but specifically: where are the producers with thirty years of recoverable mistakes behind them, the ones who can look at an AI-generated production plan and know, from the scar tissue, exactly where it’s going to fail?

Leave a comment

That cohort is currently being trained, or it isn’t. The conditions that produce it are either in place or they’re not. And as far as I can tell, the industry is so focused on the immediate disruption that it hasn’t noticed the developmental pipeline quietly draining.

Nobody is building a replacement pathway. As far as I can tell, nobody is admitting that yet either.

• In 2015 I defended the F2P model using the industry’s own vocabulary. In 2017 I called myself a parasite. This is what happened in between.

• The dirtiest secret in the industry: everyone knows these are addiction machines. The career-limiting move is saying it out loud.

• The model is broken. I accept that. I’d still tell a junior producer to take the job.

• Part four of a four-part series on the F2P trap.

If you’ve read parts one through three, you’ve seen the evidence. The science behind Skinner box mechanics and variable reinforcement. The whale economy where 5% of players fund 65% of revenue. The FTC settlements totalling billions. The regulatory wave crossing continents. The self-regulation theatre that failed by every measure the industry’s own trade body set.

Subscribe now

Now read this again:

‘I don’t make Skinner Boxes. I do use reward schedules in an attempt habitualize behaviour as a tactic, but main difference is my players are not confined and focused on the reinforcement apparatus. They have free will and lots of distractions. The cleverest engagement gag cannot trick a player into doing something that is not fun or lacks anticipation of a reward.’

I wrote that in April 2015. I was a producer at a free-to-play studio in Toronto. I’d spent the previous three years studying the psychology of compulsion, reading books on applied behavioural economics, deconstructing competitor games, and building pitch decks with core loop diagrams showing sources and sinks. The whiteboard scenes in ‘Freemium Isn’t Free’ hit too close to home because I had stood in front of actual whiteboards making those exact presentations, with real data instead of Canadough.

I wrote that post for my friends. The ones who stayed in console and PC development, making what the industry quietly calls ‘real games’. I felt them judging me. Hedonic adaptation, appointment sessions, operant conditioning: that vocabulary was a performance of expertise designed to make my work look legitimate to the people whose opinion mattered to me. I wanted to be seen as someone who understood the craft at a level most people didn’t.

Two years later, Facebook surfaced the post as a memory. I shared it with a new caption:

‘Damn, I was really drinking the coolaid back then justifying my parasitic profession of making free to play “games”. At least I became a very good parasite.’

The question this series has been building toward: what happened in between?

It started in 2012 at Fuse Powered Games. The free-to-play gold rush was underway and Smurfs’ Village had written the template: place buildings, wait for them to produce currency, collect rewards, reinvest. Optional purchases to skip the wait. That loop, simple as it looked, became the foundation for an entire genre. I played Smurfs’ Village for hundreds of hours. I was a grinder and a payer, studying the compulsion from the inside while it worked on me.

I read Nicholas Lovell’s Design Rules for Free-to-Play Games, with its chapters on operant conditioning and whale economics. I read Natasha Dow Schüll’s Addiction by Design, about how slot machines engineer the ‘machine zone’ of repetitive play. The appendices of both books took me deeper into academic papers on variable reinforcement and dopamine regulation. I was assembling the same reading list a regulator would use to build a prosecution, and I was using it to build pitch decks.

I thought this was my ticket to a life-changing cheque. I became a student of the craft. I did extensive research. I was obsessed.

We produced Universal Movie Tycoon. Kingdom Vail. Zoo Country. Duck Dynasty. I pitched and built more that never got past soft launch. None of those games hit the revenue targets. I assumed I hadn’t cracked the formula yet. The next one would work.

Then I worked at studios where the formula had been cracked. At Product Madness and Zynga, I worked on games that made hundreds of millions of dollars. The model, when it works, works at a scale that makes every justification easier to maintain and every doubt easier to shelve. When the numbers are that big, the room stops asking whether the design is ethical and starts asking how to do more of it. Over twenty free-to-play games across my career. Some failed. Some made fortunes. The ones that made fortunes used every mechanic the South Park episode described.

Then the money people arrived.

When acquisition costs were modest, it was just producers and developers trying to figure out the model. There was room to tell yourself this was craft. You were a student of the game. But as the stakes grew, the investors showed up. Then the product managers. Then the data scientists. The language in the room changed. It stopped being about making a game that worked and started being about optimising a revenue instrument. The moment the data scientists walked into the meeting, I stopped being the expert. I became the content wrapper for their monetisation model.

All the executives saw was dollar signs. There was big money on the line and we all wanted a piece. I kept doubling down. But the distance between what I told myself I was doing (making games) and what I was actually doing (building systems designed to extract money from compulsive behaviour) got harder to maintain with each project that shipped.

I read the revenue reports. I data-mined for whales. I have family members who have had gambling problems, and I knew there were players of my game spending $1,000 a day. I didn’t picture a nameless data point. I pictured a specific person. Someone I knew. Sitting at a screen, doing the same thing my family member did at a betting terminal, except my name was on the product.

There’s a moment I think about more than any other.

I was honest in the office. Too honest, apparently. I said out loud what I’d come to believe: that we did not make games. We made addiction machines.

A boss I hold in high regard pulled me aside. The conversation was not about ethics. It was career advice. Saying things like that around the office was self-limiting and not a good look.

The problem was never the addiction machines. The problem was naming them.

This is the dirtiest secret in the industry, and nobody talks about it. In every top-grossing studio, in every monetisation meeting, in every room where the core loop diagrams go up on the whiteboard, people know. The producers know. The designers know. The data scientists definitely know. The first rule of the addiction machine is that you don’t call it an addiction machine. You call it engagement. You call it retention. You call it live ops. You call it player lifetime value. You never call it what it is, because calling it what it is ends the conversation, and ending the conversation is a career-limiting move.

My boss was right, by the way. It was career-limiting. I don’t hold it against them. They were trying to protect me. That’s what the trap looks like from the inside: the people who care about you telling you to stop saying the thing that’s true.

So here’s where I’ve landed after thirty years.

The model is broken. I accept that. The science from part two confirms it. The regulatory wave from part three confirms it. My own experience confirms it.

I also don’t hide my past. I’m proud of the games I worked on. People fed their families. I got to travel the world. I worked with talented people who brought genuine craft to the UI design, the content, the production pipelines, the shipping discipline. The work had value. I separate the craft from the model. I can be proud of the work without endorsing the system it sat inside.

But I don’t pretend that separation is comfortable.

The 2015 post was me performing expertise to an audience that mattered to me, using vocabulary borrowed from the very research that now underpins FTC enforcement actions. The 2017 post was me dropping the performance. The industry hadn’t changed between those two dates. I had. I’d seen enough revenue reports, sat in enough meetings, built enough core loops, data-mined enough whales. I stopped being able to maintain the distinction between what I said I was doing and what I was actually doing.

The question I get asked now, by mentees and junior producers who read the GPA blog, is whether ethical free-to-play is possible. Whether you can build a F2P game without the predatory mechanics. Whether there’s a clean version of the model.

I don’t have a good answer. I’ve come to terms with the fact that the model, as it exists, is broken. That doesn’t mean every F2P game is evil. It means the economic structure rewards the worst version of itself, and the further you go toward the money, the more the worst version wins.

The question I get asked even more often is simpler. A junior producer, or someone looking to break in, wants to know: I’ve been offered a role on a F2P mobile game. Should I take it?

Given today’s industry, with the layoffs, the studio closures, the thousands of experienced people looking for work, I am compelled to say: take it. Break in any way you can. But know that mobile is a specific subset and it is hard to pivot to AAA. I have mentees in that boat right now.

Take the job. Learn the craft. Understand the systems. Go in with your eyes open about what you’re building. And if one day a boss pulls you aside and tells you to stop saying the quiet part out loud, know that you’re not wrong. You’re just inside the trap.

Leave a comment

That’s where this ends. The F2P model is a collective trap. The people who see it clearly, Parker and Stone, the regulators, the researchers, the thirty-year veterans who added ‘Minister of Just Barely Fun’ to their Facebook profiles, all end up either participating or watching others participate, because the economics leave few alternatives. The system is the problem. The trap is structural. And the broken model is the one hiring.

• Why burndown charts throw away most of what your Jira instance actually knows

• How an agent connected to a Jira project can surface sentiment, risk, and team health

• A practical look at what AI agents are actually good at

• The producer’s qualitative override, made legible and repeatable for the first time

A few weeks ago I argued that agentic AI shouldn’t replace Monte Carlo simulation in agile forecasting, and that the interesting play is to point agents at the contextual layer Monte Carlo was never designed to see.

Several people asked the obvious follow-up. What does that actually look like on a Tuesday morning?

Subscribe now

This is the answer. The cheapest, most informative version of “agents in production for game producers” is connecting one to your Jira instance and asking it the questions a burndown chart can’t.

Your Jira instance is one of the largest unstructured-data corpora your studio owns. Tickets, descriptions, comments, transition histories, linked PRs, attachment threads, watchers, label changes, time-in-status, reopen counts, sub-task dependencies. Every interaction is logged, timestamped, attributed, and stored.

And what does the standard agile-reporting toolkit do with all of it? It counts the tickets and draws a line.

The Jellyfish guide to Jira metrics admits this directly. “Jira metrics may not capture the full context of a project. Excessive focus on performance metrics alone can lead to tunnel vision, neglecting qualitative aspects of development.” That’s not a hot take from a critic. That’s a vendor selling Jira reporting tools, telling you their own product category has a blind spot.

Burndowns and velocity charts are a severe information loss function applied to a rich source. The qualitative layer is right there, sitting in your database, and the standard reports are designed to throw it away.

Good producers already know this, even if they’ve never put it in those words. Every experienced producer I know reads their Jira for qualitative signal as well as quantitative.

They scan the comment threads on the bug ticket that’s been reopened three times. They notice the tone shift in the lead engineer’s standup notes. They spot the dependency that’s been quietly slipping for two sprints, mentioned in passing in three different tickets, formalised as a blocker in none of them.

None of that work shows up in any chart. It happens in the producer’s head, lives in the producer’s notebook, and disappears the moment the producer leaves the room or rotates onto a different project.

An agent connected to Jira makes that labour legible, auditable, and repeatable across teams that don’t have a senior producer reading every comment. The point is to make the producer’s already-existing judgement work at scale.

There are three categories of signal worth looking at first. Each one is something an agent can do well, that a burndown cannot do at all.

Sentiment.

Researchers have been mining issue trackers for developer sentiment for over a decade. There’s a 2016 study by Mäntylä et al. that analysed 700,000 Jira issue reports containing more than 2,000,000 comments, using Valence-Arousal-Dominance metrics to detect symptoms of productivity loss and burnout in software engineering teams. The Senti4SD classifier, trained specifically on Stack Overflow developer language, reaches accuracy levels that off-the-shelf consumer sentiment tools never match, because developer language is its own dialect with its own emotional register and its own vocabulary for frustration.

A more recent study evaluated machine learning classifiers on 10,000 GitHub commit comments and reported 98% accuracy on developer sentiment classification with a tuned Support Vector Classifier.

None of this is speculative. It’s an established academic field that producers have somehow never operationalised.

What it looks like in practice on your Jira project: an agent flags that comment sentiment on the combat module has shifted measurably negative over the last three sprints. One engineer’s responses have moved from problem-solving to terse acknowledgement. The team’s previously playful ticket descriptions have stopped being playful. A ticket that used to attract quick collaborative replies now sits for a day before anyone responds.

None of these signals appear in a burndown. None of them are visible on a velocity chart. All of them are visible to a producer who reads every comment, which no producer at scale does.

The corpus has been there the whole time. The agent’s contribution is having the time to read it.

Risk.

Move from people to work. The agent reads ticket bodies, comment threads, linked PRs, and attachment text to surface risk signals that the structured fields are blind to.

A ticket flagged “low priority” in the priority field but whose comment thread contains the words “save system”, “regression risk”, “we should probably look at this” buried in a sub-thread from October. A cluster of recently created tickets that all touch the same module with no parent epic linking them. A dependency on an external API that’s been mentioned in five separate tickets across two sprints but has no formal “blocks” relationship in the issue graph.

Risk in production is rarely what’s labelled risky. It’s what’s been talked about in a worried tone with no structured field to capture the worry. Producers know this, which is why we spend so much of our time reading between the lines of tickets that the priority field would tell us to ignore.

The agent’s job is to find the worry. To pull together the half-formed concerns scattered across twenty tickets into a single observation: “There are seven tickets created in the last two sprints that mention the audio middleware in their comments, none of them linked, and three of them include the phrase ‘this is going to be a problem’. Worth a look.”

That’s a sentence Monte Carlo cannot produce, a sentence a burndown cannot produce, and a sentence a producer would absolutely produce if they had the time to read seven tickets they’d otherwise have skimmed past.

Team health.

Carnegie Mellon’s research on toxicity in open source communities is the academic anchor here, but the production application is more modest and more useful. We are not trying to detect toxicity. We are trying to detect pattern changes in a small, known team.

The engineer who used to comment on five tickets a day and is now commenting on one. The reviewer whose code review comments have shortened from paragraphs to single lines. The QA lead whose “blocked” tickets used to come with detailed reproduction steps and now come with “see Slack”. The artist whose tickets used to close in two days and now close in five, with no explanation in the comments.

These are the early warning signs of disengagement, burnout, fatigue, or one of the half-dozen other things that producers exist to notice. Every producer should care about them. No burndown chart will surface them.

The important thing about the agent in this category is what it doesn’t do. It doesn’t diagnose. It doesn’t tell you the engineer is burning out. It doesn’t tell you the QA lead is checked out. It surfaces a pattern, attributes it to specific tickets and timestamps, and lets the producer decide whether the pattern means what it might mean.

The agent doesn’t diagnose. It flags patterns worth a conversation, then gets out of the way.

Producers still do the producer’s job. The agent makes sure the producer has time to do it on the things that matter.

Bringing this back to the Monte Carlo post: the agent in this configuration is not generating reports for executives. It’s not predicting ship dates. It’s not pretending to be a forecasting tool. It’s reading the corpus your producers don’t have time to read and surfacing the signals that should make them ask better questions.

Monte Carlo still does the maths. Burndowns still do whatever it is burndowns do for the people who like burndowns. The agent fills the gap between what the structured fields capture and what the unstructured fields actually contain.

Same configuration as the Monte Carlo piece, applied to a different tool. Neither pretending to be the other.

Leave a comment

The connection itself is trivial. Atlassian’s MCP server makes hooking an agent to a Jira project a job for an afternoon, not a quarter. The hard part is not the integration. The hard part is deciding what questions to ask, which is the producer’s job, which is the job producers were already doing in their heads.

Your Jira already knows. The interesting question is whether you’re willing to listen to it.

• The games industry’s response to criticism follows the same self-regulation playbook as alcohol and tobacco, documented in peer-reviewed research.

• The UK’s voluntary loot box rules had less than 10% compliance. The self-regulation experiment failed.

• Belgium banned loot boxes. Brazil banned them for minors. The EU is drafting continent-wide rules. The FTC has settled for billions.

• Part three of a four-part series on the F2P trap.

In the episode, the Minister of Mobile Gaming proposes an awareness campaign to promote responsible freemium spending. He points to the alcohol industry as the model. The show then cuts to a parody advert: thirty seconds of fast cars, tuxedos, attractive people drinking, and a half-second flash of ‘Drink Responsibly’ at the end. The Minister makes the pitch explicit:

Subscribe now

‘You think the f*cking alcohol industry cares? They don’t care that 10% are gonna get addicted. They’re counting on it! It’s the same with us.’

In 2014, critics treated this as a comic exaggeration. In 2023, a study in the European Journal of Public Health analysed how the alcohol and gambling industries respond to government consultations about regulation. The researchers found that both industries use identical framing strategies: emphasise that harm only affects a minority, present themselves as socially responsible, and promote voluntary codes to block population-level regulation. The study was peer-reviewed and published by Oxford Academic.

South Park’s satirical comparison between ‘drink responsibly’ and ‘play responsibly’ is now an empirically documented industry strategy. The joke became a journal article.

Part 1 and 2:

The playbook works like this.

Step one: frame the problem as individual, not systemic. The alcohol industry says most people drink responsibly. The gaming industry says most players spend responsibly (or spend nothing at all). Both are true in isolation. Both are designed to make population-level regulation seem like an overreaction that punishes the responsible majority.

Step two: invest in visible self-regulation. Create an industry body. Publish guidelines. Announce voluntary codes of conduct. The alcohol industry spends less than 1.25% of its advertising budget on ‘drink responsibly’ messaging. The rest goes to advertising that makes drinking look glamorous, social, and consequence-free. The self-regulation budget is a rounding error. Its purpose is to exist, not to work.

Step three: cite the self-regulation as evidence that legislation is unnecessary. When government asks if the industry needs regulation, the industry points to its voluntary codes and says it’s already handling it.

This is the pattern the games industry adopted. I’ve been in meetings where it was deployed. I’ve watched the language shift from ‘how do we make this less predatory’ to ‘how do we demonstrate responsible practices’ without the underlying design changing at all. The conversations regulators are now having, I had versions of those conversations years ago. The difference is that in those meetings, the conclusion was always ‘add a disclaimer’ rather than ‘change the system’.

The UK ran the cleanest test case for industry self-regulation.

In 2020, the government launched a call for evidence on loot boxes as part of a broader review of the Gambling Act. It received over 32,000 responses and 50 submissions from the gaming industry. 98% of players who responded said they had opened a loot box. The government published its formal response in July 2022 and concluded that there was a link between loot box use and problem gambling.

The decision: let the industry self-regulate. The UK trade body Ukie introduced voluntary rules covering disclosure, parental controls, and advertising standards. The government promised it would ‘not hesitate to consider legislative change’ if the self-regulation proved ineffective.

In 2025, Leon Y. Xiao, a Presidential Assistant Professor at the City University of Hong Kong, published the results in Royal Society Open Science. His team found that fewer than 10% of social media ads for games containing loot boxes disclosed the presence of those loot boxes, as required by Ukie’s own rules. Games reported to Ukie and the UK government for non-compliance had no enforcement action taken against them, even after six months. They remained available for download.

Xiao’s conclusion: ‘the industry self-regulation experiment has failed again’. He called on the UK government to stop relying on what he described as ‘demonstrably ineffective industry self-regulation’ and to adopt stricter rules with proper enforcement.

The government promised to act if self-regulation failed. The research says it failed. The government has not yet acted.

The FTC has been less patient.

In January 2025, the FTC settled with Cognosphere, the developer of Genshin Impact, over charges that the company deceived users about the real costs of in-game transactions and the odds of obtaining rare items. The settlement required age verification, odds disclosure, and parental controls.

The Epic Games settlement totalled $520 million. $245 million went to refunds for players who had been charged through what the FTC called dark patterns: confusing button layouts, single-tap purchase flows, and designs that facilitated charges during loading screens and sleep-mode wakes. In June 2025, the FTC distributed $126 million to nearly one million Fortnite players.

The Amazon Prime settlement reached $2.5 billion. The FTC alleged that Amazon used deceptive flows to sign up consumers for Prime subscriptions and then made cancellation deliberately difficult. Amazon’s internal codename for the cancellation flow was ‘Iliad’, a reference to the Trojan Horse. The company was required to simplify enrolment, provide a clear decline button, and submit to oversight by an independent monitor.

A 2024 sweep by the FTC, ICPEN, and GPEN reviewed 1,010 websites and apps and found that 76% used at least one dark pattern, with 67% using multiple.

The term ‘dark patterns’ didn’t exist in 2014. The episode described the mechanics before the vocabulary caught up: deliberately confusing interfaces, obscured costs, premium currencies that hide real-money spending, friction engineered to push purchases. Everything the FTC now prosecutes, the Minister of Mobile Gaming explained on a whiteboard a decade earlier.

The regulatory response outside the United States is fragmented but accelerating.

Belgium classified paid loot boxes as gambling in 2018, effectively banning them. Fines run up to €800,000, with potential prison sentences for company officers. The Netherlands banned certain loot boxes the same year. Brazil signed a child-safety law in 2025 banning loot box sales to minors under 18, effective March 2026. Australia now rates chance-based purchases at 15+. Germany’s Bundesrat is pushing for stricter rules that would classify loot boxes as gambling, requiring an 18+ rating.

In October 2025, the EU Parliament’s Internal Market and Consumer Protection Committee adopted a report urging the European Commission to solve jurisdictional inconsistencies and ban loot boxes in games accessible to minors. The EU’s proposed Digital Fairness Act, expected in Q4 2026, will likely include loot box provisions. The loot box market generates an estimated $15 billion per year globally.

The pattern from part two’s Smurfs’ Village is still visible at industrial scale. In 2010, players made accidental purchases and the publisher added warnings. In 2025, the FTC is distributing $126 million in refunds to Fortnite players. The response has always been the same: problems visible from day one, disclaimers added after the damage, regulation arriving because disclaimers were never going to be enough.

The industry had fifteen years to fix this. It chose the ‘drink responsibly’ playbook instead. The regulators have arrived.

‘Alright, alright, I never played it. I stay away from the stuff. I just push it to people because I need the money.’

Leave a comment

That’s Jimmy, confessing that he pushed the Terrance and Phillip game like a street-level dealer while being addicted to a different freemium game himself. He needed the money. He knew what it was. He did it anyway.

Part four is about what that feels like when it’s your career, not a cartoon.

• Satan’s dopamine monologue was dismissed as pop psychology in 2014. The neuroscience now backs every claim he made.

• B.F. Skinner’s variable ratio reinforcement is the foundational mechanic behind loot boxes, gacha, and every ‘one more go’ loop in mobile gaming.

• 5% of players generate 65% of all in-app purchase revenue. The model runs on the people it hooks hardest.

• Part two of a four-part series on the F2P trap.

In season 18, episode 6 of South Park, Stan Marsh gets on his knees and prays for help understanding his addiction to a freemium mobile game. Satan appears. And then Satan, of all possible characters, delivers the most accurate explanation of behavioural reinforcement in the history of animated television:

Subscribe now

‘So you’ve got dopamine, right? That’s the chemical that gets released in your brain whenever you do something pleasurable like eating, sex. And that’s just nature, right? Like, rabbits and fish and shit, they need dopamine so that they want to consume and reproduce. But because humans have progressed and now have access to all the shit they want whenever they want it, it’s easy for them to overdo and have dopamine problems. You know, it’s not fucking rocket science, this stuff.’

A week after the episode aired, Eric Seufert at Mobile Dev Memo published a rebuttal. He called the episode’s dopamine argument ‘pop psychology at its worst’. He argued that low conversion rates in freemium are a feature, that most people play for free and get genuine value, and that comparing game spending to substance addiction is a category error.

In 2014, that was a reasonable position. In 2026, it’s harder to defend. The science moved. The money moved. The regulators moved. Satan, it turns out, was doing a better job of reading the literature than most of us in the industry were.

Part 1:

The science behind Satan’s monologue starts with a man named B.F. Skinner and a box full of rats.

In 1957, Skinner published his findings on operant conditioning. The setup was simple. Put a rat in a box. Give it a lever. When the rat presses the lever, sometimes it gets food. The critical finding was about the schedule. Fixed rewards (press the lever ten times, get a pellet) produced steady but moderate behaviour. Variable rewards (press the lever, maybe get a pellet, maybe not, you won’t know until you press) produced behaviour that was extraordinarily resistant to extinction. The rat kept pressing long after the rewards stopped coming. Skinner himself compared it to a slot machine.

That comparison is now the foundation of a $104 billion industry.

Every freemium game with a loot box, a gacha pull, a spin-the-wheel daily reward, or a mystery chest is running a variable ratio reinforcement schedule. The player performs an action. The reward is randomised. The uncertainty is the mechanism. The player keeps pressing.

I knew this. I studied it. In 2012, I was working at a free-to-play studio in Toronto and I read two books back to back. The first was Nicholas Lovell’s Design Rules for Free-to-Play Games, which had chapters on operant conditioning, Skinner boxes, appointment mechanics, and whale economics. The second was Natasha Dow Schüll’s Addiction by Design, published the same year, about how slot machines engineer compulsive play through what Schüll calls ‘the machine zone’. The appendices of both books led me deeper into academic papers on variable reinforcement, dopamine regulation, and loss aversion.

I was reading the game design playbook and the addiction research side by side. The same reading list a regulator would use to build a prosecution. I was using it to build games.

Satan’s monologue gets the mechanism slightly wrong and the principle completely right. Dopamine is more complicated than ‘the pleasure chemical’. Current neuroscience shows that dopamine release peaks during anticipation of a reward, not during receipt. The hit comes before the chest opens, before the gacha animation resolves, before the loot box reveals its contents. Every spinning wheel, every countdown timer, every slow-reveal animation in a free-to-play game is engineered to stretch that anticipation window. The longer the player spends in the state of not knowing, the more dopamine the brain produces.

A 2025 study by Kumar and Manohar in the Journal of Communication and Management analysed the dopamine loop mechanics in Genshin Impact, Fortnite, Clash of Clans, and Candy Crush Saga. They confirmed that variable reward systems trigger dopamine release, encourage habitual play, and drive microtransaction spending. The study also raised the question that the industry has spent a decade trying not to answer: where does engagement end and exploitation begin?

The answer, at the neurochemical level, is that the distinction may not exist. A study published in PMC demonstrated that rats exposed to variable-ratio reinforcement schedules (the same pattern used in slot machines and loot boxes) developed dopamine sensitisation equivalent to that produced by amphetamine exposure. The variable schedule itself, without any drug, caused the same neuroplastic changes associated with substance addiction.

Satan called the game ‘a blatant Skinner box manipulation’. The research says he undersold it.

The episode’s Minister of Mobile Gaming explains who pays for all of this:

‘The truth is a very small percentage of people who download freemium games ever pay anything for them. It’s all about finding the heaviest users and extracting the most amount of cash from them.’

He was right too. The numbers in 2026 are more extreme than anything the episode depicted.

Unity’s 2025 Gaming Report found that 5% of players generate 65% of all in-app purchase revenue. 72% of players spend nothing at all. Industry data from Udonis puts it starker: 1–2% of the player base, the whales, fund 50–70% of a game’s total IAP revenue. The top 5% of spenders average roughly $66 per day across genres. In casual games, that figure peaked near $100 during the hyper-casual boom. Companies routinely pay upwards of $500 to acquire a single ‘super whale’.

Mobile in-app purchase revenue reached $92.6 billion in 2024 and is projected to exceed $104 billion by 2026. The entire model, all of it, runs on the small percentage of people whose brains respond most strongly to variable reinforcement. South Park said 1%. The real number is 1–5%, depending on genre. The revenue concentration is steeper than the cartoon version.

I have a specific memory of this. I played Smurfs’ Village for hundreds of hours, as both a free player grinding through the progression and a paying player buying my way past the friction. Smurfs’ Village was the seminal free-to-play village-builder, released in 2010: rebuild the Smurfs’ home after Gargamel scattered them, place buildings, wait for them to produce currency, collect rewards, reinvest. Optional in-app purchases (Smurfberries) let you skip the wait. That loop became the template for an entire genre. It also became one of the first F2P controversies: players made large accidental purchases, and the publisher had to add warnings that Smurfberries cost real money. The problems the FTC would prosecute fifteen years later were visible from day one. I was studying it from the inside, feeling the compulsion loop work on me in real time, while taking notes on how to reproduce it. The line between ‘I love this game’ and ‘I know exactly how this game is manipulating me’ was never clean. I was the player and the producer at the same desk.

The strongest counterargument to all of this deserves a fair hearing. Seufert’s 2014 rebuttal made four points that still circulate in industry discussions.

First: low conversion is the entire point of freemium. Most people play for free and get genuine value. The model lets millions access entertainment that would otherwise cost money upfront.

Second: in-game currency is a convenience mechanism. Skype uses credits. iTunes uses gift cards. Obfuscation is not the only explanation.

Third: comparing game spending to substance addiction is a category error. Most people who spend money on games they enjoy are making a consumer choice, not feeding an addiction.

Fourth: the Pareto distribution (a small percentage generating most revenue) applies to every consumer product. This is not unique to gaming and is not, by itself, evidence of exploitation.

These arguments were more persuasive in 2014 than they are in 2026. The FTC did not settle with Epic Games for $520 million over a convenience mechanism. Belgium did not classify Kinder Eggs as gambling. The PMC study did not find that fixed-price consumer goods cause amphetamine-equivalent neuroplasticity. The distinction between ‘some people choose to pay’ and ‘the system is engineered to exploit a neurochemical vulnerability in a small population’ has sharpened considerably in the twelve years since Seufert wrote his piece.

The counterargument describes what freemium is supposed to be. The data describes what it became.

Three years after Parker and Stone made the sharpest critique of freemium ever broadcast, Ubisoft released South Park: Phone Destroyer. A free-to-play card battler. Premium currency. Loot packs. Microtransaction-driven progression. It launched with a disclaimer warning players about its own monetisation, echoing the show’s content warnings. Tongue in cheek. Self-aware. TV Tropes filed it under ‘Broken Aesop’.

The people who understood the problem best, who did the research, who wrote the satire, who animated Satan explaining dopamine to a ten-year-old, still released the game. Because the model works. Because the money is real. Because the economics of mobile gaming in 2017 left very few alternatives for a franchise that wanted to exist on phones.

The science is settled. Variable reinforcement causes compulsive behaviour. The revenue model depends on a small population of heavy spenders. The dopamine mechanics are the same ones that power slot machines. None of this is disputed by anyone who has read the research.

So the question is no longer ‘is this wrong?’ The question is: what did the industry do about it?

Leave a comment

Part three covers the answer. It involves the alcohol industry’s playbook, a decade of self-regulation theatre, and a regulatory wave that arrived because the industry chose not to fix itself.

• In 2014, South Park made six specific claims about free-to-play monetisation. Everyone is now the subject of enforcement action or legislation.

• Parker and Stone were pitched a South Park freemium game, thought it was offensive, and made an episode about it instead.

• One producer’s path from defending the model in 2015 to calling himself a parasite in 2017.

• Part one of a four-part series on the F2P trap.

In April 2015, five months after South Park aired an episode called ‘Freemium Isn’t Free’, I was still quite defensive about it. I wrote this on Facebook:

‘I don’t make Skinner Boxes. I do use reward schedules in an attempt habitualize behaviour as a tactic, but main difference is my players are not confined and focused on the reinforcement apparatus. They have free will and lots of distractions. The cleverest engagement gag cannot trick a player into doing something that is not fun or lacks anticipation of a reward.’

Hedonic adaptation. Appointment sessions. Operant conditioning. I threw the whole vocabulary at it. I was a producer at a free-to-play studio in Toronto, and I wanted my friends in the industry, the ones still making ‘real games’, to know I understood the craft. That what I did was legitimate.

Subscribe now

Two years later, Facebook surfaced the post as a memory. I shared it with a new caption:

‘Damn, I was really drinking the coolaid back then justifying my parasitic profession of making free to play “games”. At least I became a very good parasite.’

I’d also added ‘Canadian Department of Mobile Gaming, Minister of Just Barely Fun’ to my Facebook employment history. I was living in Canada. The episode’s satirical Canadian government conspiracy to fund the country through predatory mobile apps hit close enough that I made it part of my identity. I thought it was funny. It was funny. It was also true.

This is part one of a four-part series about the free-to-play model, what South Park got right, what the industry got wrong, and why people like me kept building the thing we were laughing at.

The episode aired on 5 November 2014. Season 18, episode 6. Trey Parker wrote and directed it. He and Matt Stone had been pitched by multiple companies on the idea of creating a South Park freemium mobile game. On the DVD commentary, they said they thought the model was ‘pretty offensive’ in how shamelessly it asked for money, so they did what they called ‘a shit load of research’. They turned the pitch into a satirical episode instead.

The episode made six specific claims about freemium games. I’m going to state them plainly because the precision matters.

One: freemium games are deliberately boring. The tedium is the product. You pay to skip it.

Two: premium currencies (the episode’s fictional ‘Canadough’) obscure the real cost of purchases. The conversion from dollars to in-game currency lowers the player’s inhibitions around spending.

Three: revenue depends on a tiny minority of players with addictive tendencies. The Minister of Mobile Gaming explains this directly:

‘The truth is a very small percentage of people who download freemium games ever pay anything for them. It’s all about finding the heaviest users and extracting the most amount of cash from them. That’s how you get addicts to pay 200 bucks for a game that’s not even worth 40 cents.’

Four: the dopamine reward loop in freemium games mirrors gambling and substance addiction. Satan (yes, Satan) appears to explain the neuroscience to Stan in a monologue about variable reinforcement schedules and dopamine regulation.

Five: the industry’s ‘play responsibly’ messaging is cosmetic. The episode draws a direct parallel to alcohol industry self-regulation, complete with a parody ‘drink responsibly’ advert that spends thirty seconds glamorising drinking before flashing the disclaimer.

Six: the people pushing the games (represented by Jimmy acting as a street-level dealer) are themselves victims of the same system.

The Prince of Canada sums up the business model in one line:

‘Freemium. The “mium” is Latin for “not really”.’

Critics were mixed. The AV Club gave it a B-minus and wrote that drawing a line between freemium games, gambling, and alcohol addiction ‘seemed like a bit of a stretch’. IGN gave it a 7.5 and complained about ‘longwinded explanations of freemium games and how they worked’. The general consensus was that the target was valid but the execution was heavy-handed. Too much teaching, too little comedy.

Parker and Stone called it their favourite episode of the season.

The episode was nominated for a Primetime Emmy for Outstanding Animated Program. It didn’t win. The industry didn’t listen. And then, three years later, Ubisoft released South Park: Phone Destroyer, a free-to-play card battler with premium currency, loot packs, and microtransaction-driven progression. It launched with a tongue-in-cheek disclaimer warning players about its own monetisation. The franchise that produced the sharpest critique of freemium ever broadcast went ahead and released the exact game it had satirised. TV Tropes catalogues this as a ‘Broken Aesop’. That’s generous.

More on Phone Destroyer in part two. For now, what matters is the scorecard. Here’s where the episode’s six claims stand in 2026.

Claim one, deliberate tedium: the FTC now prosecutes ‘dark patterns’ in games, including designs that create friction to push spending. Epic Games settled for $520 million. Amazon settled for $2.5 billion over deceptive enrolment and cancellation flows.

Claim two, currency obfuscation: in January 2025, the FTC settled with Cognosphere, the developer of Genshin Impact, over charges that the company deceived users about the real costs of in-game transactions and the odds of obtaining rare items.

Claim three, whale dependence: Unity’s 2025 Gaming Report found that 5% of players generate 65% of all in-app purchase revenue. 72% of players spend nothing. The model runs on the people it hooks hardest.

Claim four, the gambling parallel: Belgium classified paid loot boxes as gambling in 2018. Brazil banned loot box sales to minors in 2025, effective March 2026. The EU Parliament’s consumer protection committee adopted a report in October 2025 urging a continent-wide ban on loot boxes in games accessible to minors. The EU’s proposed Digital Fairness Act is expected in late 2026.

Claim five, self-regulation theatre: a 2025 Royal Society study found that fewer than 10% of social media ads for games with loot boxes disclosed their presence as required by the UK industry’s own voluntary rules. The lead researcher concluded that ‘the industry self-regulation experiment has failed again’. A 2023 study in the European Journal of Public Health found that the alcohol and gambling industries use identical strategies: frame the harm as affecting only a minority, present themselves as responsible, and promote voluntary codes to block actual regulation.

Claim six, the pushers are victims too: I’ll get to that in part four. That one’s mine.

Every claim the episode made in 2014 is now backed by enforcement action, academic research, or pending legislation. The AV Club thought the gambling comparison was a stretch. The FTC disagreed. Belgium disagreed. Brazil disagreed. The European Parliament disagreed.

A cartoon saw it. The industry that made the cartoon saw it. The producer writing this post saw it, added ‘Minister of Just Barely Fun’ to his Facebook profile, and went back to work the next morning.

Leave a comment

If a comedy show could see this coming a decade early, why didn’t the industry course-correct? And why did the people who agreed with the critique, people who laughed at the joke, who shared the clips, who understood the references, keep building the thing they were laughing at?

That’s what this series is about.