Read the first few chapters. No strings.

Here is a scene I have played out more times than I would like to count. I am at a whiteboard with a marker, mapping a creative pipeline for a team, and I am doing value stream mapping on work that will not hold a line. Concept, model, texture, rig, review. It looks clean on the wall. Then I present it, and within about four minutes somebody in the room finds the asset that skipped three of those stages, or the one that looped back into concept after texturing, or the one that was in review and development at the same time. And the fix, every single time, was the same fix. Another column. Another queue state. Another lane.

I have thirty years in game production and I kept reaching for the same tool to solve a problem the tool was built to create.

The board always grew. It grew to chase a process that has no fixed process. Creative work bounces around by nature: the route is discovered in the doing, and the path of the next asset cannot be read off the last one. I knew that. I would say it out loud in the very session where I was drawing a fixed left-to-right sequence on the wall and pretending it described the work. The contradiction did not register, because I had been trained, like most of us, to see a board as a picture of the steps.

The frustrating part is that I was not doing anything unusual. Column sprawl is a documented anti-pattern. The advice you will find everywhere is that teams inflate their boards with columns like Analysis, Testing, Approval, and Waiting on Feedback until flow goes sluggish, and that once you pass ten or so states the card metaphor starts to fall apart entirely. I was living inside that failure mode and I thought the problem was discipline. If I just mapped harder, interviewed the team more carefully, found the true sequence, the board would settle. It never settled, because there was no true sequence to find.

I want to be fair to myself here, because I did not stand still. I spent decades attempting value stream mapping on knowledge work and getting nowhere useful with it. Then I read Karen Martin and Mike Osterling’s Value Stream Mapping, the first book I found that was written for service and office work rather than the factory floor, and it was a real step forward. Later I adopted the flavour in Flow Engineering by Steve Pereira and Andrew Davis soon after it came out in 2024, which took the practice further still: lightweight, iterative, built for collaborative mapping conversations rather than a static diagram. Two genuine upgrades, each moving me further from the crude version, each honest that knowledge work is messier than a production line.

Here is the thing neither book could fix, because it sits one level below both of them. However modern the mapping gets, it is still mapping the flow as a route. It still lays the work out as a stream with a direction, and it never questions the one assumption underneath all of it: that the work has a shared path worth drawing. Even the friendliest advocates admit that when a process involves creativity, judgment calls, or heavy variability, a static map oversimplifies to the point of being misleading. For creative work there is no shared path. The map was always wrong the moment I finished drawing it, and a better mapping method could not save it, because the problem was in the shape of the tool, not the quality of the map.

So the frustration had two layers. I was applying a route-shaped tool to work that has no shared route, and I was blaming myself for the tool not settling.

The reframe I did not have a word for

The fix came from reading, of all things, a run of essays on Medium by Bruno Baketarić, who works on flow at SAP and writes about Kanban with more care than almost anyone I have read on the subject. I want to be precise about what he did to my thinking, because it was not a technique and it was not a template. It was one distinction, stated cleanly, that reorganised a problem I had been carrying around for decades.

The foundational piece is called The Board Is a State Space. The claim at its centre is this: a Kanban board models the state space of the work items, not the action space of the people working on them. A state is a condition the work item is in. An activity is something a person does. They are different kinds of thing, and putting the second one on the board is a category error that no amount of practice discipline can clean up, because the error is baked into the model.

A state is a property of the work item. An action is something a person does. The two are not the same kind of thing, and confusing them produces exactly the dysfunctions this essay is about.

Read that and then look again at every board I ever drew. My columns were activities. Concept is not a state, it is what a concept artist does for a living. Texturing is not a state, it is a job. I had built board after board out of the wrong unit, and then I had spent years patching the consequences.

A second essay, The Flow in Workflow, takes the argument down to the word itself. Workflow is work and flow, and flow, on the tradition’s own definition, is the movement of work through a system. So a workflow is the structure through which work moves: a space of states, with the transitions between them. The activities are the labour that carries an item from one state to the next, and they matter, but they are not the workflow. That is why the same field defines flow in terms of items and then, a paragraph later, defines workflow as a series of activities, and never notices the switch. I had inherited the switch and never noticed it either.

Why it dissolved the problem instead of solving it

Here is the mechanism, and it is the thing I wish someone had told me in 2005.

When your columns name activities, every new way of working needs a new column. You are modelling what people do, and people keep doing new things, so the board has to keep growing to keep up. That is the treadmill. That is why the edge case in the room always cost me a column. The asset that looped, the asset that skipped a stage, the asset worked in parallel: each one was a new action pattern, and an action-based board has to represent each new pattern with new structure.

When your columns name states, varying routes share one space. An asset in a given state has told you what is true of it, and it does not matter which of fifteen different paths it took to get there. The loop, the skip, the parallel work, all of it happens inside the states, and the states do not multiply, because a condition like “in production” or “awaiting review” holds true regardless of the sequence that produced it. The edge case that used to cost me a column now just traces its own path through states that already exist.

I was modelling the action space. That is why the board never stopped growing.

The same reframe quietly killed a second argument I had refereed a hundred times: the backflow fight. You know the one. Development calls something done, QA finds a problem, the card goes “back” to development, and the team spends the standup arguing whose fault the backward move was. Baketarić’s answer is that there is no backward move, because the item never left its state. If a finding surfaces in verification, that finding is information produced in the verification state, and the item stays in verification while somebody acts on it, even if acting on it means writing more code. State transitions go forward, or the item leaves the flow entirely. Nothing moves back, because the previous states no longer exist for that item. Once I saw that, an entire genre of team conflict I had learned to manage turned out to be an artefact of a mislabelled board.

The essay that explained my specific pain

There is a third piece in the run, The Family the Board Assumes, and it named the exact thing that had been happening to me for as long as I had been drawing these boards.

Value stream mapping works on a factory floor because every product in a family shares a route: press, then weld, then paint, same stations in the same order for every part. The order of activities is a faithful portrait of the work because the work is a fixed order. That shared route is a precondition, and on the factory floor it is so obviously met that nobody writes it down. When the technique crossed into knowledge work, the shape came along and the precondition got left behind. Creative work forms no families. Each asset finds its own path, so there is no shared route for the columns to portray.

That is my whiteboard, explained. I had been mapping design-flow work with route-shaped instruments for a long time, and feeling the precise pain of a missing precondition without ever being able to name it. Better mapping methods, Martin and Osterling then Flow Engineering, moved me along the surface of the problem without ever reaching the floor of it. The tool was not failing me. I was asking a route to describe work that has no shared route, which is a thing no mapping method can be scoped to fix.

What the reframe unlocked

The satisfying part is that this did not just retire an old irritation. It opened up something new in the work I do now.

I run production for a co-development studio, which means my teams make assets that flow into someone else’s pipeline, on someone else’s approval, on someone else’s timeline. Once I stopped carving boards by activity and started carving them by the condition the asset is in, a distinction fell out that I had never been able to see before: the difference between the time my team controls and the time the client controls.

On an activity board, a client’s three-week wait for a licensing sign-off is buried inside whatever column the card happened to be sitting in, and it quietly drags down every metric I report. On a state board, I can make “awaiting client review” its own state, sitting right next to the states my team owns. Now the flow data splits cleanly. Here is the time we held. Here is the time they held. For a service business that runs on trust and renewal, that split is not a reporting nicety. It is the argument I make in the quarterly review when delivery slipped and it was not my team’s doing.

The state framing also sat neatly on top of a position I had already held for years. I used to run Blocked columns like everyone else, until Daniel Vacanti’s When Will It Be Done? sent me down the flow-metrics rabbit hole, and I came out the other side convinced they were a mistake. A Blocked column is its own well-known anti-pattern: it lets cards drift sideways and quietly inflates your work-in-progress limits. I have argued against them in almost every studio I have worked in since, and I have long preferred a tag. Blocked is a flag on the card, timestamped in place, and the asset never moves. It stays in the state it is genuinely in, carrying a marker that says what it is waiting on, and your data separates active time from waiting time without anyone editing a clock. What the state-space reframe did was explain why the tag was right all along. A block is a condition, not a place, so it was never a column to begin with.

None of the co-development material was in Baketarić’s essays. His work is about a single team’s internal board. The client-owned split, the application to art co-development, those are mine, built on top of his frame. And the blocked-as-tag habit I brought with me from Vacanti. Which is rather the point. A good idea is generative. It does not just fix the thing the author aimed it at. It hands you a unit to think with, and it clicks into the things you already believed and shows you why they were right.

An old dog, a new trick

I have been doing this a long time, and I do not change how I work very often, because most of what gets sold as a new method is an old method with new vocabulary. This was different. Three careful essays gave a precise name to a thing I had been fumbling at for most of my career, and the name did real work: it dissolved a frustration, retired a recurring team fight, and opened a way to run a co-development board that I could not have designed the week before.

If you build boards for creative work and you have felt that same treadmill, the columns multiplying to chase a process that never holds still, go and read Baketarić’s essays. Start with the state space one. I have been at this since before some of my producers were born, and he taught me something. That is worth saying out loud.

Read the first few chapters. No strings.

Earlier this week I picked apart a framework for classifying AI-touched work after it ships. Where the model touched the pipeline, how much it drove the output, what it was trained on, who stopped getting paid. Useful questions, all of them. All useful after the fact.

This one is about before the fact. About the version of this problem that shows up as a policy, or doesn’t, months before it shows up as a headline.

On 30 June, the Godot Foundation published a new contribution policy. The headlines called it an AI ban. It is not that, and the difference is the entire post.

Godot has been drowning in pull requests for years. Some of that is a good sign: more people using the engine, more people willing to contribute, a maintainer team cautious enough to resist feature creep. The Foundation says as much in its own announcement. But the backlog was never just enthusiasm. The number of qualified reviewers has stayed roughly flat while the number of PRs kept climbing, and reviewing a pull request has never gotten any cheaper. Writing one has.

That is the whole mechanism, and it is not specific to Godot. GitHub itself has shared figures showing site-wide merged pull requests growing from 25 million a month in January 2023 to 90 million a month in March 2026, a 3.6x increase in three years, and it just added PR rate caps of its own to cope with the same imbalance. Nobody’s reviewing capacity grew 3.6x in that time. The cost of submission collapsed. The cost of review did not move. Every open source project running on volunteer maintainers is sitting on the same unbalanced ledger, whether or not they have written a policy about it yet.

Godot’s maintainers noticed the imbalance long before June. Maintainer Rémi Verschelde said publicly earlier this year that AI pull requests were becoming, in his words, increasingly draining and demoralising. That is not a throwaway complaint. That is a maintainer naming a problem out loud, in public, months before the organisation did anything structural about it.

Here is the line from the Foundation’s own announcement that the whole post turns on.

“This reviewer shortage was already a problem, but it was one that we successfully ignored. We can no longer ignore it.” Godot Foundation

Read that again slowly. They are not saying the problem appeared in June. They are saying it existed earlier, they knew, and the organisation’s response for however many months was to successfully not deal with it. Successfully ignoring a problem is not the same as it not being a problem. It just means nobody paid the cost yet.

I’ve written before about the difference between a risk and an issue. A risk is something that might happen and needs mitigation. An issue is something that has already happened and needs a response now. Confusing the two is not a rare failure mode. It is close to the default setting for any team, studio, or foundation that would rather keep monitoring something than admit it needs a decision.

Godot’s own language gives away exactly when the crossover happened. A rising backlog you are cautiously optimistic about is a risk. A backlog that maintainers are calling draining and demoralising, in public, is not a risk any more. It is an issue wearing a risk’s clothing because issue means somebody has to act and risk means you can keep watching a little longer.

The gap between those two states, Verschelde’s comment earlier in the year and the Foundation’s policy in June, is the gap where the actual damage happens. Not the code quality damage, though that’s real too. The damage is to whoever was doing the reviewing during those months, absorbing a cost the organisation had not yet agreed to name.

This reads closer to a compliment than a criticism. Most projects never get to the point of writing the policy at all. They stay in the successfully ignored phase indefinitely, because naming an issue means somebody owns the response, and an unnamed risk requires nothing from anyone.

The thresholds that separate the two are not exotic. A backlog that has been growing for more than a quarter without a change in reviewer capacity has already failed the assumption it was going to resolve itself. A maintainer publicly describing the work as demoralising is not a mood, it’s a data point with a date on it. A concern raised in three separate maintainer discussions without a resulting decision has demonstrated, empirically, that discussion alone was never going to produce one. None of those thresholds are precise to the day. What they do is convert a feeling, this seems to be getting worse, into a trigger: when the condition is met, the conversation stops being optional.

What actually shipped on 30 June is worth reading as a decision, not a stance. Strip the headline framing and you get four things Godot’s maintainers actually decided.

Who counts as a new contributor. Anyone with three or fewer merged pull requests. Below that threshold, no new features or significant refactors without explicit maintainer permission. That is a specific, checkable line, not a vibe about trust.

What is still allowed. Code completion, regex help, debugging lookups, translation. All still fine. What changed is the requirement to disclose AI assistance in the pull request discussion itself, not bury it.

What is not allowed at all. Autonomous agents submitting PRs directly, and anything that reads as heavy AI generation the submitter cannot explain or defend under review. Violating the agent rule triggers an automatic ban, no appeal mentioned.

Human to human, always. AI-generated text in conversations with maintainers is out, on the basis that machine translation of something a human actually wrote is fine, but an AI standing in for the conversation itself is not.

Four decisions. Every one of them answers a specific question rather than gesturing at a value. That is what separates a decision from a stance, and it is the same distinction that matters on a project with two people instead of two hundred maintainers.

I’ve written about the decision log before: four fields, what was decided, why, who decided it, when. Run Godot’s policy through those four fields and it holds up cleanly. What: no autonomous agent PRs, disclosure required for assisted code, a new contributor threshold. Why: reviewer capacity has not scaled with submission volume, and it is undermining the mentorship pipeline the project depends on for future maintainers. Who: the Foundation board and maintainers, named as the decision owner in their own post. When: 30 June 2026, with an explicit note that the policy will be revisited as tools change.

That last part matters more than it looks. They did not write a permanent commandment. They wrote a decision with a date on it and an acknowledgement that the date might need revisiting. That is exactly what a decision log entry is supposed to look like, and it is exactly what most teams skip, because writing “we will revisit this” feels like admitting the decision might be wrong. It’s admitting the decision was made under current conditions, which is the only honest way to make one.

“Things change every day with respect to the current suite of AI tools available. We will continue taking a conservative approach in our policies towards them, but we will re-evaluate as things evolve.” Godot Foundation

That sentence is doing quiet, useful work. It converts a decision into a monitored condition rather than a fixed law, without letting the condition drift back into being nobody’s job to watch.

None of this requires two hundred maintainers or a foundation board to translate down to a two or five person team. The mechanism is identical at a smaller scale, just quieter, and quieter is exactly why it’s more dangerous.

Nobody on a three person indie team is going to write a formal contribution policy. What you actually need is one written line: what is AI allowed to touch on this project, and what is off limits. Not a philosophy. A specific answer for concept art, for dialogue, for code, for anything that ships. Dated. Owned by a named person, even if that person is you. Revisited when something changes, the same way Godot’s policy explicitly leaves room to.

Run it through the same four fields. What: AI-assisted concept work is fine for exploration, nothing generated ships without a named person redrawing or substantially reworking it by hand. Why: the team wants to be able to stand behind the art as authored, and a generated asset shipped with a light edit is a legal and reputational question nobody has actually answered yet. Who: the two of you, agreed on a specific Tuesday, not assumed. When: today’s date, with a note to revisit once either of you actually tests a shipping pipeline that changes the calculation. Four lines. It takes less time to write than this paragraph took to read, and it is the difference between a decision and an assumption nobody remembers making.

Without that line, the same drift Godot experienced happens by default, just without anyone noticing until it costs something. Someone generates a placeholder asset that quietly becomes the shipped asset because nobody said it couldn’t. Someone uses an agent to write a system nobody else on the team fully understands, and six months later the person who prompted it has moved on and nobody can maintain what’s left. The team was never against using AI. Nobody ever decided anything either way. The decision happened by accretion, the same way scope creep happens, one reasonable-seeming choice at a time, with nobody holding the line because nobody knew holding it was a job.

The Godot story is useful precisely because it is not about AI. It is about a review bottleneck that existed for months before anyone treated it as something requiring a decision rather than continued observation. Swap “reviewing pull requests” for “deciding what AI is allowed to touch on your project” and the shape is identical. The risk was there earlier than the response. It always is. The only real choice a team has is how long the gap between those two points is allowed to run.

Godot’s gap ran from at least February to the end of June. That is not a long gap by the standards of most projects that eventually address something like this. Most teams never write the policy at all. They keep calling it a concern, worth watching, until the cost shows up somewhere they can no longer pretend not to see it.

Write the line before that happens. It costs less now than it will later, and it will cost something either way.

Read the first few chapters. No strings.

Josh English wrote the best thing I have read on AI in games, and I want to argue with it.

His piece, “’Was AI Involved?’ is the Wrong Question for Games,” makes a case I have been trying to make in the C-suite for two years and doing worse. The blunt question, did AI touch this game, sweeps a code assistant fixing a build script into the same bucket as a store page full of generated portraits, and once everything is in one bucket the bucket tells you nothing. His fix is a vocabulary. He lays out five layers, from ambient AI in the background of the toolchain, through disposable internal drafts, through shipped generated content, through runtime systems, up to games built around AI as a design pillar. Each layer carries a different creative burden, a different legal exposure, a different obligation to the player. The right question, he says, is not whether AI was involved but how.

He is right. I have shipped work using cruder frameworks than his, and I would use his tomorrow. So this is not a takedown. It is the thing you do to a good framework, which is push on it until you find where it bends.

It bends in one specific place, and the place tells you something.

He wrote the list himself

Before English builds anything, he tells you what a good framework would have to hold. A single label, he says, cannot responsibly cover all of the following: production tooling, internal drafts, shipped assets, runtime behaviour, legal provenance, labour substitution, creative authorship, player data, and design intent.

Nine things. Now count the rungs he builds.

Ambient AI is production tooling. Internal drafts is internal drafts. Shipped content is shipped assets. Runtime AI is runtime behaviour. The fifth, AI as a design pillar, takes creative authorship and design intent together.

Five rungs. Nine items. Legal provenance, labour substitution, and player data get no rung at all.

I think this is what happens when you build a framework around one question, in this case what a player is owed, and then find it will not hold the things that never reach the player. The list is the honest inventory. The ladder is what survived the design.

This piece finishes his list.

Two rulers, one label

Start with the five that did make it, because even those measure two different things.

The layers look like a ladder. English calls ambient the lowest layer and design pillar the highest category, and everything else ranks in between by how seriously you should take it. Read them again and the ladder comes apart in your hands, because the bottom three rungs and the top two are measuring different things.

Ambient AI, internal drafts, shipped content. Those three answer one question: where does AI sit in the production pipeline. Background, upstream, or in the box the player buys. That is a location.

Runtime AI, AI as a design pillar. Those two answer a different question: how much does AI determine what the player actually experiences. A live model generating dialogue is not further along the same line as a shipped texture. It is on a different line. “Design pillar” is not a place in the pipeline at all. It is a statement about ambition, about whether intelligence is the point of the game or a way of making the game.

You cannot rank a location and an intensity on the same axis. Try it and you get the exact ambiguity English spends the piece trying to escape. Is a game with one AI-voiced side character “runtime AI” or “shipped content”? Both. Is a procedural quest system a design pillar or a production shortcut? Depends entirely on how much of the game leans on it, which is a question his ladder has no rung for.

A single label cannot hold the disagreement. Neither can a single axis. A ladder with two different rulers welded end to end is still a slogan, just a longer one.

Split them and the framework stops fighting itself. One axis for pipeline location: where did AI touch the work. A second axis for output intensity: how much did AI determine what shipped. Now you have a grid, and the grid has cells the ladder could not name. A generated image repainted so heavily that nothing of the original survives sits in one cell. A generated image shipped with a colour tweak sits three cells away. English names both of those cases and then cannot place them, because on a single line they look adjacent. On a grid they are nowhere near each other, which is the truth.

The messy middle he keeps gesturing at is not messy. It is two-dimensional, and he was trying to read it with a ruler.

The axis he keeps rediscovering

Watch what English does across the piece with the question of where a model came from.

In the shipped-content section: a licensed commercial model trained on cleared data is not the same as an unknown tool with murky provenance. In the same section: a vendor asset under contract is not the same as a marketplace pack nobody verified. In the artist section: model training and consent are real questions that deserve direct discussion. Three times he raises the origin of the model, and three times he raises it as an aside inside a layer that is really about something else.

Once, at the top of the piece, he raises it properly. Legal provenance is item five on his own list of what a label cannot hold. It spends the rest of the essay as a footnote to other people's tiers.

When a thing keeps surfacing in every section as a side note, it is not a side note. It is a dimension you have not drawn yet.

Provenance cuts across every layer he has. Same pipeline location, same output intensity, wildly different exposure depending on whether the training data was licensed, whether the vendor indemnifies you, whether the actor consented. Two studios can ship the identical generated portrait at the identical level of human editing. One licensed a model trained on cleared data with a contract behind it. The other pulled a marketplace pack of unknown origin. English’s framework files those two acts in the same cell. A court would not.

There is a fair objection to compressing this into one question, and Edvard Toth made it to me directly, with English agreeing. Most training data is scaffolding, the statistical substrate that lets a model generalise at all, and it rarely surfaces in any particular output. The specific dataset, the fine-tune, the reference image handed to the model at generation time, sits much closer to the work. Asking what a model was trained on flattens those together.

They are right, and it is the charge I have just laid against the ladder. One question doing several jobs.

So the axis has four fields. The pretraining corpus. The fine-tune or reference set. Consent, where a likeness or a voice is involved. Indemnity, which decides who absorbs the loss. A model can be clean on the first and catastrophic on the third.

What survives the objection is the part a producer needs. Scaffolding describes how a model generalises. Licensing describes how the data was obtained. Those are separate questions, and the second does not dissolve because the first is interesting. Every image in that substrate was acquired from somewhere. A court will not ask whether a JPEG contributed to abstract capability or to the final render, and neither will an actor whose voice was cloned.

Steam has already run into this wall in public. Valve’s January 2026 rewrite split efficiency tools from shipped content, which is English’s distinction almost exactly, and it works. But Valve publishes no threshold for how much human editing removes the disclosure obligation, and it will not rule on where your training data came from. Their own guidance lands on: keep the original output, keep your revision history, and if generated material is still recognisable in the final product, disclose. That is an honest admission that the platform can see pipeline location and can roughly see intensity, and cannot see provenance at all. It has outsourced the axis it cannot measure back to the developer.

The market is pricing that missing axis whether or not anyone charts it. Research from Ross Burton at Game Oracle found games carrying an AI disclosure drew around 53% fewer reviews than games without one, and almost a fifth got no reviews at all. Players cannot see your licensing paperwork. They see the badge, they assume the worst provenance, and they price it in. The absence of a provenance axis does not make provenance stop mattering. It just means everyone guesses, and the guess runs against you.

The axis the ladder is built to hide

Here is the place the framework bends hardest, and the bend is structural. It follows from what the framework was built to measure.

English sorts the disposable material into its own layer: mood boards, rough concepts, graybox levels, placeholder dialogue, test audio, pitch images, the exploratory work that helps the team think and never reaches the player. He is careful about it. He says the tier still matters, that studios should care about vendor terms, licensing, provenance and contractor policy, and that “only for reference” is not a magic spell. He is right about all of it. EU Artificial Intelligence Act

Read the risks he names in that tier again. Vendor terms. Licensing. Provenance. Contractor policy. Every one of them is a risk to the studio. Not one of them is a risk to a person.

Labour substitution was item six on his list. It never appears in the tier where labour substitution happens.

Job loss does not happen when the asset ships. It happens when the role gets automated. And the roles get automated upstream, in precisely the tier English marks as not the player’s business: the concept pass, the placeholder, the first-draft asset, the graybox. A framework that tracks only what reaches the player cannot see labour substitution by construction, because labour substitution is invisible on the pipeline axis. Nothing shipped. No badge required. A person is still gone.

He named labour substitution in the sentence that set up the whole framework. Then he built five rungs and gave it none.

The data is not subtle about who is standing there. Read against the GDC State of the Game Industry survey, artists are the group most opposed to generative AI, 64% viewing it negatively, with designers close behind at 63%. Visual arts also sat among the hardest-hit departments in the layoffs of the last two years, with 16% of survey respondents in the field reporting cuts. Analysis of the layoff patterns finds junior staff targeted in greater numbers than senior, and the entry-level work now handed to AI, early-stage art, QA, basic programming, is exactly the foundational work people used to climb through to build expertise. Senior talent keeps its value because it can direct the model. The junior who would have become that senior never gets the reps. You automate the bottom of the ladder and then wonder, in five years, why there is nobody halfway up it.

None of this shows up if the only question you ask is what the player experiences. English’s framework asks a genuinely better question than “was AI involved.” It still asks the player’s question. The worker’s question runs on a different axis, and a framework built around disclosure to a buyer has no reason to draw that axis. This is not a charge against English. It is the natural blind spot of any model organised around what reaches the player: labour substitution is the one cost that leaves no trace in the finished product. The honest move is to add the axis, not to pretend the ladder already covered it.

Why this is a producer’s problem, not a critic’s

I am not writing this to win a discourse point. I run production, and the grid matters to me because I cannot manage a risk I have collapsed into a slogan. Each axis is a different column in the register, and the columns do not trade off against each other. They accumulate.

Two of them English already handed me. Pipeline location is my disclosure exposure: where AI touched the work decides what I owe a platform, and getting it wrong delays a store page or invites a pile-on. Output intensity is my creative defensibility: how much a model drove the result decides whether I can stand behind the work as authored, or whether I have shipped a heap of generated output with no point of view, which players smell in a trailer and reviewers punish in week one.

The two the ladder cannot hold are the two that keep me up. Provenance is my legal exposure, and it runs on a delay timer. Where the model was pretrained, what it was fine-tuned on, whether the vendor indemnifies me, whether the actor consented, none of it shows in the shipped asset and all of it shows in discovery. And labour is the slow one, the cost that arrives years after the saving. Automate the concept pass and the graybox and the first-draft asset and you bank the money this quarter. You pay it back when the junior who would have learned the craft on that work was never hired, and the senior who could have trained them is directing a model instead. A studio can look efficient and be quietly eating its own future, and no disclosure form will ever flag it.

Four columns. The single label holds none of them. English’s ladder holds two and reaches for the third. Draw provenance and labour as their own axes and you have a register a producer can actually run, in place of a purity test a mob can run at you.

English says the industry needs a vocabulary instead of a purity test, and he is right. A vocabulary with one axis is a purity test with better manners.

So yes, AI was probably involved. The better question is how, and the producer’s version of how is four questions wearing a coat: where did it touch the work, how much did it determine what shipped, what was it trained on, and who is no longer getting paid. Answer all four and you have said something true. Answer only the first and you have swapped a blunt instrument for a quieter one.

Correction, 9-Jul. An earlier version of this piece attributed to Josh English a verdict on internal drafts that he did not make. His remark about not burdening the buyer with production detail refers to ambient tooling, such as build scripts and bug reports, and not to concept work. English says the internal-drafts tier still carries licensing, provenance and contractor-policy risk, and that calling something reference-only settles nothing. The argument here has been revised, and I think it is stronger for it: he names labour substitution himself, in the sentence that introduces his framework, then gives it no rung on the ladder.

The provenance section has also been extended, following a public exchange with Edvard Toth and Josh English about what "trained on" actually asks.

• External producers work on the publisher side, overseeing games built by outside development studios, from initial pitch through to launch.

• The role spans pitching, developer selection, contract negotiation, milestone oversight, budget management, platform submissions, and commercial alignment.

• It requires financial and legal literacy that surprises most people coming from a development background.

• The defining structural challenge is influence without authority: you are accountable for outcomes you cannot directly control.

Read the first few chapters. No strings.

In the previous post I covered the internal producer, the person running the team from inside the studio. This post is about the other side of that relationship: the external producer, sitting at the publisher, managing a game being built by someone else.

It’s a role that gets less airtime than internal production, partly because fewer people do it and partly because the publisher side of the industry is less visible than the studios themselves. But it’s a genuinely distinct set of skills, and for some producers, it’s a much better fit than working inside a development team.

The external producer works for the publisher. The studio making the game is not your employer. You’re the bridge between what the publisher has agreed to fund and what the studio is actually building. That gap is where the job lives.

What “publisher” means varies. It could be a traditional game publisher like EA, Ubisoft, or Paradox. It could be a platform holder commissioning an exclusive. It could be a mobile publisher licensing a brand and funding a developer to build around it. The shape of the relationship changes, but the external producer’s function stays roughly the same: represent the publisher’s interests while keeping the development partnership healthy enough to ship something good.

What an external producer actually does

The external producer works for the publisher. The game is being built by a development studio that is separate from the publisher, sometimes across the country, sometimes across the world. The external producer is the publisher’s primary point of contact with that studio, and the primary conduit back.

That sounds simple. In practice, the role touches almost everything.

You’re involved from the beginning, assessing potential projects for market appeal, audience fit, and how they sit within the publisher’s existing portfolio. You help evaluate which studios are right for which projects, looking at their skills, their creative approach, and their track record. Once a deal is struck, you own the relationship from that point through to submission and launch.

What you’re managing is a set of obligations and expectations that run in both directions. The developer needs to understand what the publisher requires: the quality bar, the commercial positioning, the branding constraints, the platform requirements. The publisher’s leadership needs to understand what the developer is building, how it’s progressing, and what’s at risk. You’re the person who carries information across that gap accurately and without distortion.

“You’re the person who carries information across that gap accurately and without distortion. Getting that wrong in either direction is how projects fall apart.”

The responsibilities in detail

The scope of the external producer role is wider than most people expect when they first encounter it.

On the commercial side, you’re thinking about branding, audience fit, and market positioning. If the game involves licensed intellectual property, you’re managing the licensor relationship too, which means additional approval cycles, compliance obligations, and a set of relationship dynamics that sit entirely outside the development team itself.

Project management looks familiar to any producer: maintaining production plans, schedules, and roadmaps. The difference is that you’re doing it across multiple projects simultaneously. At any point you might be managing a game in early production with one studio, overseeing a game in full production with a second, and coordinating the submission process with a third.

Milestone oversight is one of the more formal parts of the job. When a developer submits a milestone, you review it against the milestone schedule and the Statement of Work. You decide whether to approve it, which means sending the approval email and processing the invoice, or to document the shortfall, describe what’s missing, and begin the formal discussion about remediation before any rejection is issued. This is consequential work. Milestone approvals trigger payment. Formal rejections have legal weight. You need to be precise.

Budget management at this level involves predicting costs from early in the project, often before the final game is fully defined. External expenses, travel, licensing fees, QA costs, certification fees: you’re estimating and tracking all of these from a publisher perspective, which is a different set of numbers from the developer’s own budget.

Contract work is a constant thread. You’re involved in negotiating milestone achievements, payment schedules, and scope of work details. When scope changes, the contract has to change with it, and that means working with legal, negotiating with the developer, and documenting the agreement correctly. If you’ve come from a purely creative or development background, this part of the job may require more adjustment than anything else.

Platform submissions are the path from a finished game to a game that’s actually available. The external producer guides the developer through first-party requirements, certification, and the approval processes specific to each platform. The certification requirements for PlayStation, Xbox, Nintendo, and mobile storefronts are different in their detail and different in how they’re enforced. Knowing them, and knowing the people at the platform holders, matters.

Risk management runs through everything. The external producer is supposed to identify risks before they become problems, which means maintaining enough understanding of the project’s real status that early signals don’t get missed.

Working with other teams and partners

The external producer’s role extends well beyond the studio relationship. A significant part of the job involves coordinating with departments inside the publisher’s organisation and with third parties outside it.

Marketing. The external producer is typically the link between the studio and the marketing team. That means sharing game features and content at the right time, providing game assets (screenshots, trailers, builds for review), and overseeing the creation and approval of marketing materials in collaboration with the studio. Getting this right requires discipline on both sides: marketing needs assets on time to plan campaigns, and the studio needs enough notice to produce them without disrupting development.

First-party platform holders. If your game is shipping on console or mobile storefronts, you have a formal relationship with Sony, Microsoft, Nintendo, Apple, Google, or Amazon, depending on the platforms. Each has its own submission, certification, and approval processes. The external producer shepherds the project through these processes: managing the submission schedule, responding to certification failures, and maintaining the relationship with the platform representative. First-party processes have their own timelines that don’t bend for development slippage, so planning these carefully is non-negotiable.

“First-party certification timelines don’t bend for development slippage. Plan them carefully or they become a crisis.”

QA and localisation. The external producer liaises with the publisher’s QA and localisation managers to ensure proper resource allocation and task prioritisation throughout the project. In the final stages of production, this means managing bug prioritisation and waiver decisions: which bugs get fixed before ship, which get deferred, and which get waived as known issues. These are often high-stakes calls made under time pressure, and the external producer owns the process.

Legal and licensors. If the game involves licensed IP, whether a sports licence, a film tie-in, or a brand partnership, the external producer manages that relationship on the publisher side. This includes coordinating approvals, managing licensor feedback on builds, and ensuring the studio has what it needs to satisfy the licence terms. Legal sits alongside this: contract compliance, amendments, milestone approval language. It’s not glamorous, and a lot of it is slow-moving, but failures here can hold up a release.

User research, consumer insights, and analytics. On larger projects, the external producer will bring in consumer insight and user research teams to run playtests or surveys on studio builds. The findings then need to be communicated back to the studio in a way that’s useful, not demoralising. This is a genuine skill. A user research report that lands badly with a development team can create friction that lasts for months.

The skills this role actually requires

[PERSONAL EXPERIENCE] I’ve talked to a lot of producers who moved from internal to external production and said some version of the same thing: they didn’t expect how much financial and legal literacy the role required.

That’s not because the financial concepts are complicated. It’s because internal production rarely puts them in front of you directly. An internal producer might know the project’s budget in broad terms; the external producer is managing the publisher-side P&L, forecasting costs before the scope is settled, and communicating budget and scope implications to executive management. Those are different demands.

The legal side is similar. Understanding the difference between a fixed-price contract and a time-and-materials contract, knowing what a Statement of Work needs to contain, understanding what happens when a milestone is formally rejected: these things matter, and not knowing them creates real exposure.

The interpersonal side is substantial too. You’re managing relationships with developers, with vendors, with internal teams across the publisher, and with platform holders and licensors. Each of those relationships has different dynamics, different expectations, and different communication norms. The ability to read those differences and adapt accordingly is something you develop over time.

“An internal producer might know the project’s budget in broad terms. The external producer is managing the publisher-side P&L, forecasting costs before the scope is settled, and communicating budget implications upward. Those are different demands.”

Prior experience in internal or external game development is the practical foundation. You need to have shipped console, PC, or mobile titles. You need to understand how development teams actually work, because you can’t evaluate a studio’s progress or flag risks in their delivery if you don’t know what healthy development looks like from the inside. The external producer who has only ever been on the publisher side is at a real disadvantage.

The other thing worth naming is comfort with independence. On a publisher team, you’re often working without the day-to-day peer support structure that exists inside a development studio. You’re expected to make judgements, manage your own time across multiple projects, and escalate when escalation is appropriate, rather than doing it reflexively.

What does a day actually look like?

[PERSONAL EXPERIENCE] This is the question I get most often, and I think it’s the right one to ask. Job descriptions and responsibility lists are useful, but they don’t tell you what it feels like to do the job.

So here’s a specific day. Not a representative average. A real one.

The morning starts with email and project management tools. Bug reports have come in overnight from QA on Developer A’s game, and I scan them for anything urgent. I check in with the associate producer: what do they need from me today, and do they have any blockers?

The latest build from Developer A has landed on the FTP. I pull it down and verify it runs on the dev kit, then coordinate with QA to confirm they have the same build and are working through the test plans.

The QA lead wants to discuss a set of bugs the developer has asked to be waived. Some waiver requests are straightforward; others need a harder look, because waiving a bug that later becomes a certification failure is a problem that comes back to you. That conversation takes focus.

Then there’s a separate issue to investigate: dev kits that were supposed to be delivered to Developer B for a different project haven’t arrived. I need to find out where they are and what that means for the developer’s schedule this week.

Mid-morning shifts to milestone review. Developer C has submitted their latest milestone. I sit down with the milestone schedule and the Statement of Work and go through the submission methodically: what was promised, what was delivered, where the gaps are. Either the milestone passes and I send the approval and process the invoice, or I need to document the shortfall clearly before any formal conversation about rejection begins. This documentation isn’t bureaucracy; it’s what protects both parties.

Between that and a status report that needs to go out later, I’m also working on a concept approval deck for a new game in early consideration. Consumer insights and product teams have provided feedback, and I’m folding that in. The deck is trying to make the case for a game that doesn’t exist yet, to an audience who will fund it or not, based on what I can show them about the opportunity.

Lunch exists. I eat it, talk to people informally, and if I have the time, play a game. This is not optional. You cannot represent games you haven’t played.

The afternoon brings a marketing request: screenshots from Developer A’s game for upcoming promotional use. Some of the assets in the current build are placeholder, so I work with the associate producer on how to compose and frame shots that capture what the game actually does without featuring assets that aren’t final. It requires knowing the game well enough to make those calls.

I check in on the associate producer’s development. Their Individual Development Plan needs attention, and they should have a mentor meeting scheduled. I make sure that’s happening.

Then I demo the latest working build from Developer A to the head of sales and marketing. I hand them the controller. I let the game speak for itself. After the demo, I float the new game concept to gauge early interest from someone whose read of the market I trust.

Late afternoon is meetings and calls. First, a meeting with the licensor about improving approval cycle times: the current cycle is adding weeks to the schedule and nobody is happy about it. Then a call with legal about a development agreement amendment covering a scope change with Developer B. The scope change affects the payment schedule and the delivery timeline, and the amendment has to reflect both accurately.

After that, I negotiate the scope and schedule impact directly with Developer B. We’re trying to find an arrangement that works for the developer’s team without undermining the publisher’s release calendar. Neither side will get everything they want.

A call with the first-party developer rep to get a status update on a submission that’s been in certification longer than expected. I want to understand whether there’s any willingness to waive specific bugs that are holding things up, and how much of that is a negotiation versus a hard requirement.

I check in with the QA lead to hear how the day’s testing went and get an early view of the bug report before it’s finalised. Then I pick up Developer A’s game again and try to get further than I did yesterday.

“You cannot represent games you haven’t played. That’s not a peripheral observation. It’s part of the job.”

The structural challenge: influence without authority

[UNIQUE INSIGHT] Everything about this role flows from one central fact: you are responsible for a game that you do not control. You can ask the developer to do something. You cannot make them. You can document a shortfall and withhold a milestone payment. You cannot walk across the floor and fix it yourself.

That distinction is the structural reality of external production. Authority over the development team sits with the studio’s own leadership. Your authority runs through the contract, through the relationship, and through the quality of your judgement. If the developer respects your read of things, your calls carry weight. If they don’t, the legal tools are the last resort, not the first.

This creates a set of practical tensions. The developer is a partner, and you want that relationship to work. But the developer is also a contracted party with legal obligations. Balancing genuine rapport with the readiness to enforce those obligations, when necessary, is one of the skills that separates experienced external producers from people who are still learning what the role requires.

The same tension appears with internal stakeholders. Senior leadership at the publisher has priorities and preferences. Sometimes those priorities are well-calibrated to what the developer can actually deliver; sometimes they’re not. Part of your job is translating between what leadership wants and what the developer can do, managing expectations accurately in both directions, and protecting the developer from scope requests that would derail production, while also making sure leadership’s genuine requirements are heard and acted on.

Time zones complicate all of this. If you’re managing studios across multiple regions, every conversation requires scheduling discipline and asynchronous communication practices that hold up when you can’t talk in real time. Cultural differences across international teams add another layer: the norms around how disagreement is expressed, how bad news is delivered, and how commitments are made vary considerably, and misreading those norms creates friction that’s hard to trace back to its source.

“Your authority runs through the contract, through the relationship, and through the quality of your judgement. If the developer respects your read of things, your calls carry weight.”

The part of the job nobody talks about

The formal structure of the role is teachable: milestone reviews, marketing coordination, first-party management. The hard part isn’t.

The hard part is maintaining an honest relationship with a studio team you don’t manage, who may feel scrutinised or second-guessed by everything you do. You’re there on behalf of the publisher, which means you sometimes have to deliver bad news, push back on deliverables, or escalate risks that the studio would prefer to handle quietly. Done badly, this creates an adversarial dynamic that makes the project worse. Done well, the studio sees you as an extension of their own production capability: someone who has their back with the publisher and who surfaces problems early rather than waiting for them to become contractual disputes.

The external producers I’ve seen struggle most are the ones who default to process: they do the milestone reviews, write the reports, attend the meetings, and still somehow miss the fact that the project is in trouble. The role requires you to read the room, notice when a studio’s communication pattern changes, and ask the questions that aren’t comfortable. Process supports that work. It doesn’t replace it.

“The external producers who struggle most default to process. The role requires you to read the room.”

Building commercial value into the project is also part of the brief. External producers look proactively for opportunities to expand a project’s commercial footprint: consumer and trade marketing initiatives, demos, downloadable content (DLC), OEM deals, platform extensions, territory-specific localisation. These aren’t afterthoughts. An external producer who only manages what’s already agreed isn’t doing the full job.

How to get into external production

There’s no single route. Some external producers come up through internal production at studios, move to the publisher side, and bring that development-facing credibility with them. Others start in QA or production coordination at a publisher and build outward from there.

What the role selects for, regardless of background, is the ability to manage relationships across organisational boundaries and to stay calm when the information you’re getting doesn’t add up.

I’ve rarely seen anyone succeed in external production without having spent meaningful time first inside a development studio. The reason is practical. If you haven’t been inside a development team, you don’t have a reliable mental model of what healthy development looks like. You can learn the publisher-side processes without that model. What you can’t do reliably is evaluate a studio’s real status, identify when they’re struggling versus when they’re just in a difficult phase, or read the difference between a team that’s behind and one that’s in trouble. Those distinctions matter enormously in this role.

The most useful thing you can do early is understand both sides of the relationship. If you’ve only ever worked at a publisher, try to get close to a studio-facing project. If you’ve only worked at studios, understanding what a publisher’s internal approval chain looks like will help you enormously when you’re trying to get decisions made quickly.

The more common path is to work as an internal producer first, often at the associate or producer level, ship one or more titles, and then move to the publisher side. Some people make that move deliberately, because they’re drawn to the portfolio scope, the commercial and legal dimensions, or the variety of working with multiple studios. Others find themselves in it because an opportunity came up and they took it.

Live game experience is increasingly valued in these roles, partly because publishers are increasingly in the business of operating live titles rather than just shipping them. Understanding how live games work operationally, and what the post-launch support relationship between a developer and publisher looks like, gives you a more complete picture of what you’re managing.

The role tends not to have a formal career ladder. At larger publishers, there are often associate, producer, and senior producer levels with defined scope. At smaller publishers, a single external producer might own three or four projects simultaneously. That breadth can be a feature, not a limitation, if you’re the kind of person who needs variety to stay sharp.

How the role is changing

The publisher-developer model has shifted considerably in the past decade. More studios are self-publishing than before, which means fewer games have a traditional external producer relationship. For the ones that do, the role has grown in complexity: more platforms, more certification requirements, more marketing surface area, and greater pressure on milestone quality as publishers have become more risk-averse since the economic contractions of 2023-2024.

Remote work has changed the day-to-day. When I started working in this area, visits to the development studio were routine. You sat with the team, walked the floor, got a read on morale and momentum. That’s harder to do at a distance. Video calls compress the relationship. You need to be more deliberate about maintaining it.

The role also intersects increasingly with data and analytics. Publishers want to see player research baked into development earlier, and external producers are often the ones pushing for that: arranging playtests, commissioning surveys, getting early builds in front of players and feeding the results back usefully. Studios that resist this tend to struggle commercially, regardless of how well they execute technically.

Leave a comment

The next post in this series covers a different production context entirely: Production 101 #5 looks at Free-to-Play game economics and what producers need to understand about how those games are designed to make money. The full series index is here.

Read the first few chapters. No strings.

The first prompt was 147 words, and I thought that was a lot.

It described a lane, two flanking blocks, a balcony platform, a horizontal beam, a back wall, two cover primitives. Matte white, grey ground, no characters. A whitebox, the kind of greybox blockout any environment artist would build in-engine before a single texture goes down. The image came back in sixty seconds and cost five cents. The proportions were off. The platform read as a window ledge. The lane felt like a corridor.

So I wrote another 147 words, more specific this time. A flat walkable balcony platform at upper-storey height, roughly four metres wide by two deep, projecting horizontally from the inner face of the upper storey, large enough for a person to stand on. Closer. Still wrong. On the third attempt I gave up on the lane entirely and rethought the whole thing as an interior arena. Another sixty seconds. Another five cents.

Then I did what I should have done first. I had a reference image: a 3D blockout I’d built myself, colour-coded, labelled, with human-scale figures and storey-line annotations. The real spatial ground truth, straight from the engine. I fed it to the edit endpoint and asked the model to clean it into a matte white whitebox, strip the figures, strip the labels.

It removed most of the labels. Not all. The scale came back wrong. The purple wall, the one that was meant to be the tall dominant surface at the back right, came back medium height like everything around it. So I added the sentence I’d assumed the model would infer from a reference image that literally showed it: the back-right wall is dramatically taller than the others, roughly two to three times their height, soaring above and dominating the back-right portion of the arena.

That worked. After four attempts and twenty-three minutes I had a clean whitebox. Cost: nineteen cents.

I want to be clear about what nineteen cents and twenty-three minutes had actually bought me. Not a concept. Not a piece of art. A starting line. A grey box I could now begin to detail. And reaching even that had taken a fight with a tool that was looking at my own geometry the entire time.

None of this was a chatbot, by the way. We were driving the model through API-level controls, prompting in structured JSON for the extra fidelity it buys you over typing prose into a text box. This was the tool operated near its ceiling, by people who build production pipelines for a living. Hold onto that, because it matters for everything that follows.

The thing the surveys won’t tell you straight

If you read the trade press you’d think concept art was the settled, obvious win for AI in game development. The practical application. The one nobody argues about.

The data says something quieter. The GDC State of the Game Industry survey, 2,300 developers, breaks AI use down by task, and asset generation, the thing my team was doing, sits near the bottom. Eighty-one percent of the developers who use AI use it for research and brainstorming. Thirty-five percent for prototyping. Asset generation comes in at 19%, and only 5% will put it anywhere near a player-facing feature. The pattern is plain: the further you move from idle ideation toward something that ships, the faster the hands come off the tool.

Sentiment is moving the same direction, hard. The share of developers who think generative AI is bad for the industry went 18% in 2024, 30% in 2025, 52% now. It tripled in two years and crossed into the majority. Only 7% call it positive. That’s not a wobble, it’s a curve, and it’s pointing down.

Part of that is the job market underneath it. Seventeen percent of those surveyed were laid off in the last year, 28% within two, and the people on the floor watching colleagues go while executives talk efficiency are not the same people writing the AI-first press releases. The gap between leadership enthusiasm and artist buy-in is wide and well documented. The “most practical application” story is, to a large degree, a story told from above the work.

One honest caveat, since I work in India and this matters to me: the GDC sample skews US-based, white and male, and GDC says so itself. It is not the whole world. Japanese studios, for one, report far higher adoption. Read the numbers as a strong Western signal, not a global verdict.

But here’s the easy misreading I want to head off. The tempting conclusion is that this is pure ideology, artists resisting the future on principle. I don’t buy it. I think a lot of those developers tried the tool on real work, at the scale real work demands, and quietly concluded the maths didn’t close. The 19% isn’t squeamishness. It’s a verdict. And the rest of this is the mechanism behind the number, told from inside one engagement where the client was fully aligned on using AI and we still walked into every wall there is.

Null going in, null coming back

Here is the part that took me a while to understand, because it sits underneath the craft and only shows up when you read your own logs.

There’s a feature in image generation called a seed. The idea is simple. The random starting point that produces an image is just a number, and if you know the number you can run the same prompt again and get the same image back. When something almost works, you fix the seed and change only the words. The composition holds still while you adjust. It’s the one handhold the medium offers.

It doesn’t exist here. Not “it’s hard to use.” It isn’t there.

I went back through the records. More than ninety generations across four projects. Every seed field in every log entry, null. Null going in, null coming back. A slot in the schema that was wired up and never carried a value.

The reason is structural, and it comes in two layers. The first is the endpoint. Text-to-image on gpt-image-2 will at least nominally accept a seed. But every style pass we ran went through the image edit endpoint, because we were transforming an existing reference. That endpoint doesn’t expose seeds. You can pass one. The API ignores it. Nothing comes back.

The second layer is worse, and it would bite even if the endpoint behaved. Our canonical whitebox, the grey box that cost nineteen cents, was itself the output of a non-deterministic edit. Every style we generated downstream used that image as its reference. So even if I could have locked a seed on a given style pass, I’d have locked one link of a chain whose very first link was already a roll of the dice. There was no point in the pipeline where reproducibility was even theoretically available.

This is not an oversight someone will patch. The newer image models, gpt-image-2 among them, work autoregressively. They build an image the way a language model builds a sentence, predicting the next piece from everything before it, rather than starting from a fixed field of seedable noise and denoising it. There’s no seed because there’s no noise origin to seed. And here’s the cruel symmetry: that same architecture is exactly what makes these models so good at following instructions, so good at the 147-word prompt, so good at the thing that made me want to use one. The instruction-following I loved and the determinism I lost are the same design decision. You cannot keep one and recover the other.

The seed field in every schema file says null. That single null is the whole problem written in one character.

Thirty styles, ninety minutes, one sentence I had to keep retyping

With the whitebox locked, the real work started, and for about an hour it felt like flying.

I wanted to know what the space could become. The first style was a Tadao Ando raw concrete interior: form-tie holes, board-formed surfaces, tall narrow windows throwing raking daylight. Fifty-six seconds. Then a variant with a warmer concrete palette. Then a third that added formwork reveals and a shadow gap where wall meets floor. By the third Ando prompt I was writing six hundred words for a single image.

Then I opened the throttle. Between roughly eleven and noon I ran a dozen more directions in parallel. Retro-futurist seventies in three lighting moods. Space-age with op-art murals. Frank Lloyd Wright Prairie across five variations, from hearth glow to rain-grey cedar. The afternoon went to Mexico: hacienda, Barragán, Tulum, Spanish Mission, Pueblo. Then a run of Western Gothic, modernist through to border desolation. By the end I had something like thirty fully realised interiors, all grown from that one whitebox.

Some were extraordinary. The Barragán marigold came back exactly right. The Wright hearth glowed with the precise warm weight I’d asked for. The op-art read with Vasarely sharpness.

But look at what closed every single one of those prompts, thirty times over:

The space is entirely empty. The back-right wall is dramatically taller than the other back walls, roughly three times their height, soaring above and dominating the back-right portion of the space. Maintain the existing camera angle, composition, and spatial layout.

I typed that, or a version of it, every time. Not because I forgot the geometry. Because the model did. There was no persistent space for it to remember. Each generation was the first time it had ever seen the room, so each time I had to rebuild the room in words before I could change its lighting.

A different room every time you turn around

The single clearest failure was the one I opened with: move the camera, lose the room.

It’s worth sitting with why, because it isn’t a glitch you can prompt around. North gave us a beautiful, coherent image. South gave us another beautiful image of somewhere else. The walls didn’t agree with the first render, the proportions had wandered, and the reference images didn’t save us, because they pin down style and rough content, not a stable three-dimensional truth you can walk around.

This is object permanence, and the model hasn’t got any. It was never holding a room. It was producing, each time, a plausible picture conditioned on some tokens. “The same arena from behind” is not a question it can answer, because there is no arena in there to turn around. There is only the next plausible image.

Scale broke the same way, and at production it broke worse, because we had several artists working several versions of the same scene at once. Each one of them was rolling their own dice. We’d built proxies, we had a defined human scale, and still the sizes drifted across the set, person to person, version to version, with no shared anchor to hold any of it together. That’s the part the single-image demos never show you. The trouble isn’t one image. It’s coherence across a set, and the set is the actual unit of work in real development.

Writing legal disclaimers to an image model

The exterior work, an outdoor plaza built from a different blockout, produced my favourite absurdity of the whole job.

The reference had three back walls at different heights. I wanted them read as one continuous flat surface, the enclosing back wall of a plaza. The model kept turning them into three separate buildings. Which is, to be fair, a reasonable thing for something trained on architectural photography to assume: three wall segments at two, two and three storeys look like three structures with depth and passages between them. So the second-attempt prompt opened like this:

Critical geometric constraint: the back walls are continuous flat planar surfaces forming the enclosing back wall of an outdoor plaza. They are NOT separate building masses and NOT volumetric structures extending forward or behind. The height difference is a difference in wall height only, not a difference in building footprint.

I was writing a legal disclaimer to an image model. And then, underneath it, instructions to strip out the magenta dashed lines and the storey labels reading GROUND, FIRST, SECOND, because the model was rendering my annotation scaffolding as actual architecture. The very marks I’d drawn to communicate intent, it was building as structure.

By the third environment I’d developed a whole private vocabulary. A “Rest Area,” the central eighty percent of each wall kept smooth, because if I left it open the model filled it with detail that would bury a character silhouette. A rendering manifesto pinned to every prompt: flat matte painted pipeline, no specular, no reflection, no wet sheen, no engine-cast shadow. Precise placement rules: form-tie holes and joint lines clustered at the top corners and base edges only, never the centre.

Those prompts reached nine hundred words each.

The conversation only goes one direction

Read the logs end to end and you can see the shape of the thing. Every prompt contains the whole of the previous prompt, plus the corrections for whatever went wrong last time. The language only accumulates. Each failure leaves a scar in the text, and the text is the only place a scar can live, because the model keeps none of them.

By the end I wasn’t writing art direction. I was writing annotated specifications. The creative brief and the technical correction had fused into one unwieldy document, rewritten from scratch for every image, hand-delivered to a system with no memory of the thirty attempts before it.

And there was a tax for trying to fix things in place. Push too hard on a near-perfect image, prompt and prompt and prompt to correct the one object that’s wrong, and the output starts to degrade. Context rot. The thing you were refining gets worse because the context you’ve piled up has turned against you. A diffusion re-roll doesn’t punish persistence like that. This pipeline does.

So where was the constraint infrastructure, the seed-locking and control nets and trained adapters that are supposed to claw determinism back out of these tools? We didn’t have it on this job. Our only instrument of control was the prompt itself, swelling from 147 words to 900 as it absorbed every lesson. The determinism I recovered, I recovered by hand, in language, one generation at a time, and none of it persisted past the single image it produced.

The speed that wasn’t

Speed is the whole case for this. Strip it out and “most practical application” collapses. So count it honestly.

The generation cost four cents and took under a minute. That’s the number everyone quotes. But that was never the cost. The cost was the nine-hundred-word prompt in front of it, the four attempts to reach a usable whitebox, the time spent choosing among near-misses, the re-rolls that fixed one wall and broke another, and the simple fact that the artist I was supposedly replacing was still right there, now doing forensic correction instead of authorship. The four cents is real. It’s also the smallest line on the invoice.

What the tool actually did was move the labour, not remove it. It shifted the work from the front of the process, where an artist makes decisions from intent in a more or less straight line, to the back, where a producer reverse-engineers a machine’s near-misses inside a composition it chose. Reactive correction is slower and grimmer than authorship, and it fights you with sunk cost the whole way, because the image is so close and surely one more prompt does it.

That 19% is a room full of people who did this arithmetic on their own work and walked away from it as a shipping tool. Not because the pictures are bad. Because the fully-loaded path to a consistent set of them isn’t faster than the thing it was meant to replace. The studios that do use it well, by the reporting that exists, have all landed in the same place: AI for pre-production exploration and pitch decks, artist-led pipelines, mandatory human paintover as a standard stage, consistency held together by curated prompt libraries and trained style anchors rather than by the base model. They didn’t find a shortcut. They built a frame strong enough to contain the tool, and kept the artist at the centre of it. That frame is a thing you build deliberately, and I’ve written before about the configuration layer a production has to put around an AI model before it behaves. The lesson from this job is that concept art needs one too.

What you can’t buy twice

Here’s what keeps you pulling anyway. The first shot was eighty percent there. The model showed you, on day one, that it can deliver, so every miss after that feels like luck rather than a ceiling. The near-perfect image is stickier than a clean failure, because it reads as almost yours. And there’s never a moment the tool tells you to stop. It will always make one more.

And the hook doesn’t stop at the person holding the mouse. A dozen working concept artists told Creative Bloq that AI made their jobs harder, not easier, and the mechanism they named is the same one, scaled up the chain. Art directors anchor on the first AI image they’re shown, even when it’s spatially wrong or incoherent, and stronger human concepts then get measured against that first hit and rejected. The honeymoon pull doesn’t just trap the operator. It quietly resets the taste of the person approving the work. That’s the part that should worry a production lead more than any wasted afternoon: the tool isn’t only slow, it bends judgement toward whatever it happened to produce first.

The null seed is where the slot machine turns cruel. When the Barragán marigold came back exactly right, when the Wright hearth got the glow, there was no way to keep it. No seed to bank, no coordinates to return to. A winning ticket I couldn’t photograph, in a lottery I couldn’t re-enter. All I could carry from one roll to the next were words, which is exactly why the prompts swelled into incantations describing outputs rather than inputs. “The back-right wall soars three times their height.” “Warm interior, like a Mexican hotel at dusk.” Those weren’t art direction. They were me trying to encode a result I’d already seen and lost, because language was the only thing the next roll would inherit.

The images at the end were genuinely remarkable. The dusk plaza with its lavender-to-amber sky over flat concrete exists because someone wrote nine hundred words exact enough to summon it. The prompts had become a strange new kind of technical writing, part fiction, part specification, part incantation, and the skill in them is precision, not creativity.

But remarkable and reproducible are different properties, and production runs on the second one. A commissioned artist holds the world in their head. They can give you the same helmet tomorrow, from the other side, after the note, in the marketing render, because the world persists in them between jobs. gpt-image-2 holds nothing between generations. So the job, the actual producer’s job in a pipeline like this, becomes supplying the memory and the determinism the tool refuses to keep. You are the seed it doesn’t have. This is the same problem I keep circling from other angles, how a producer carries state across sessions an AI model won’t remember. Concept art turns out to be one more place where the human is the persistence layer.

The better these models get at making any single image, the less they hold of the one before it. We’ve built a tool that improves at everything except remembering what it just did, and handed the remembering back to the human who was told the tool would do it for them.

Read the first few chapters. No strings.

Cristiano Pierry published a thoughtful piece last week arguing that evaluation is becoming a product surface, not a back-office activity. He’s right about the problem. I want to push on the diagnosis.

The evaluation problem isn’t new. What’s new is the rate at which AI is making it impossible to ignore.

Larry Smith coined the term “shift left” in a 2001 article in Dr. Dobb’s Journal. The idea is simple enough to fit on a Post-it: find defects earlier in the development lifecycle, because defects found late cost more to fix and cause more damage. Move quality gates left on the timeline, toward the work, rather than leaving them clustered at the end.

Game studios learned this expensively. I lived through the era when QA was something that happened after production, when the build was “done.” It wasn’t done. It was never done. It was just at a point where the team had run out of time to keep making it better. The bugs were always there. The only question was whether we found them in a sprint review or in a launch post-mortem.

The discipline eventually moved. Studios got better at involving QA earlier, at writing acceptance criteria before implementation, at treating a failed test in week three as cheaper than a failed launch in week forty. It required culture change, and culture change in studios is slow, but the direction was correct and the reasoning was sound.

What Pierry is describing, the need for evaluation to be continuous and structural rather than deferred and ritual, is shift-left applied to AI product work. The insight is good. The reason it keeps needing to be rediscovered is worth examining.

The artefact is why.

In older workflows, the artefact moved slowly. A design review happened while sketches were still rough. A requirements review happened while the spec was still being written. The incompleteness of the thing in front of you was visible, and visibility triggers the review instinct. When something looks unfinished, people know to bring judgment to it.

AI collapses that gap. The first output is fluent and polished. It has the texture of something that has been through several iterations. It sounds confident. The UI renders. The copy flows. The prototype responds.

That texture short-circuits the review instinct in the people who most need to apply it.

A fluent artefact does not mean a sound one. But it feels that way in the room, and feelings drive process.

Senior stakeholders in a position of approval have a pattern I have seen repeatedly across studios and clients: they do not take early drafts seriously. They want to see it in situ. They want to see it on device. They resist forming a view until the thing feels real, which usually means until it looks finished.

This was already a problem before AI. With AI, it becomes a crisis, because the thing always looks finished. The prototype that takes forty minutes to build looks, to a distracted VP with fifteen minutes in their calendar, indistinguishable from the prototype that took four months. The review instinct never fires. The evaluation layer gets skipped.

Then ten more artefacts arrive the next day.

Shannon’s channel capacity theorem, first published in 1948, describes the theoretical maximum rate at which information can be reliably transmitted over a communication channel given its bandwidth and signal-to-noise ratio. Exceed the capacity, and you don’t get a little degradation. You get overflow. The signal doesn’t slow down gracefully. It stops being received correctly.

Communication has two sides. Transmission and reception. Both sides matter, and they are not symmetrical.

AI has made the transmission side of product work effectively infinite. The cost of generating a prototype, a spec, a set of test cases, a visual variant, a conversation path has dropped so far that volume is no longer a practical constraint. A team that used to produce three artefacts a sprint can now produce thirty.

The reception side has not changed. Senior stakeholders have the same number of hours they always had. Their ability to process, evaluate, and form a judgment on what they are seeing has not increased. Their attention is a finite channel with a fixed capacity.

What happens when you transmit more information than the channel can receive? The buffer fills. The signal overflows. The receiver stops processing correctly, not because they are incompetent or disengaged, but because the incoming rate exceeds their capacity for reception.

This is not a stakeholder problem. It is a systems problem. And it is a producer problem.

Producers are not just deliverable managers. They are communication channel managers. The job has always involved monitoring both sides of every information exchange: are we transmitting clearly, and is the receiving party actually receiving?

In practice, this means pacing. It means knowing that a stakeholder who has just reviewed six artefacts this week has a degraded capacity to usefully engage with a seventh. It means understanding that sending more is not the same as communicating more. It means recognising that an unanswered email chain with twelve attachments is a channel in overflow, not a team that is working hard.

The temptation with AI is to celebrate throughput. The discipline is to regulate it.

A team that uses AI to generate thirty artefacts and submits them all for review has not improved its output. It has created a reception problem. The evaluation that gets skipped is not a stakeholder failure. It is a production failure. Somewhere, someone chose to maximise transmission without accounting for what the receiving end could handle.

Shift-left does not solve this on its own. Moving the evaluation gate earlier helps when you have one artefact and a willing reviewer. When you have thirty artefacts and a reviewer whose buffer is already at capacity, shifting left just means the overflow happens sooner.

The producer’s job is to manage the flow rate. Decide what goes through the channel and when. Batch thoughtfully. Sequence for attention, not for volume. Give stakeholders the right thing to review at the right time, in a form that makes the review instinct fire rather than suppress.

Pierry’s framing, that evaluation is becoming a product surface, is a useful provocation for teams that have not thought about it at all. For producers who have been doing this for any length of time, it is a restatement of something we already know: quality gates belong in the work, not at the end of it.

The part worth adding is this: when you can generate artefacts faster than your stakeholders can evaluate them, the constraint is no longer production. It is reception. And managing reception has always been part of the job.

The channel has a capacity. It always did. AI just made it possible to exceed that capacity so fast that no-one notices until the reviews stop happening, the sign-offs go quiet, and the artefacts keep coming. That is not a stakeholder attention problem. It is a production problem. And fixing it is the producer’s job.

• An internal producer is accountable to two things simultaneously: the schedule and the team. Those two accountabilities are not always in tension, but managing both honestly is what defines the role.

• The responsibilities span schedule planning, cross-department coordination, budget management, scope control, risk management, and stakeholder communication.

• There is no single correct path into internal production. QA, development roles, and product management are all common starting points.

• The shape of the role depends heavily on studio size. A small studio’s internal producer is a generalist covering most of production; a large studio’s is typically a specialist owning one area deeply.

This is part of the Production 101 series. Post #2 covered the specific roles and levels in a studio’s production hierarchy. This post focuses on the internal producer specifically: what the role is structurally, what it requires of the person doing it, how people arrive at it, and what a working day looks like in practice.

What the Internal Producer Actually Is

People often describe the internal producer as a project manager, and that description is accurate as far as it goes. The internal producer does manage the project. But the framing misses something that matters.

An internal producer carries two distinct accountabilities. The first is to the delivery: the schedule, the milestones, the deliverables, the expectations of everyone outside the team who has a stake in the outcome. This is the accountability most people think of when they think of production. It’s visible, it’s measurable, and when it goes wrong, everyone notices.

The second accountability is to the team: their capacity, their wellbeing, and the sustainability of their working environment. This one is less visible, but it shapes whether the team can keep functioning at a high level across the months and years a production actually takes. A producer who treats it as secondary tends to find that hitting short-term milestones comes at the cost of team stability, and that instability shows up in the work eventually.

“An internal producer carries two distinct accountabilities. The first is to the delivery. The second is to the team.”

The internal producer sits between the game’s vision and its execution. They don’t set the creative direction. They don’t write the code or build the assets or design the systems. What they do is create the conditions where all of those things can happen reliably, at a pace the team can sustain, to a standard the project requires.

That dual accountability is the structural truth of the role. Everything else in this post is detail that sits underneath it.

Read the first few chapters. No strings.

What the Role Requires Day to Day

The responsibilities of an internal producer tend to fall into a set of recurring areas, though how much time any one of them takes depends on the phase of production and the studio’s size.

Schedule planning and milestone tracking are the foundation. The internal producer builds the production plan, maintains it as the project changes, and keeps track of whether the team is on course to hit the next milestone. This is not a static document updated once a week. It’s a living picture of where the project is, which requires constant input from every department.

Cross-department coordination is where much of the practical work lives. Art, design, and programming are all producing interdependent output, and the dependencies between them need active management. An artist can’t finish a character if the design specification is still in flux. A programmer can’t integrate a feature if the build is broken. The internal producer is the person monitoring those dependencies and moving things before they become blockers.

Budget management sits alongside the schedule. The internal producer owns the financial picture of the project: what was budgeted, what has been spent, what is committed, and where the gaps are. On smaller teams the producer may own vendor relationships and payments directly. On larger productions there’s usually finance involvement, but the producer remains accountable for knowing the numbers.

Scope management and risk management are related. Scope will change during any production. Features get added, features get cut, platform requirements shift, playtest feedback reveals something that needs rethinking. The internal producer’s job is to manage those changes in a way that doesn’t quietly move the goalposts for everyone else. Risk management is the forward-looking version of the same work: identifying what could go wrong before it does, and building contingency into the plan while it’s still possible.

Stakeholder communication runs through everything. Publishers, investors, studio leadership, and platform holders all need a picture of where the project is and where it’s going. The internal producer is typically responsible for that picture. Getting it wrong in either direction, by being too optimistic or too pessimistic, causes different problems but both are expensive.

“Scope will change during any production. The internal producer’s job is to manage those changes in a way that doesn’t quietly move the goalposts for everyone else.”

Quality assurance sits in a complicated relationship with production. The internal producer doesn’t run QA, but they do own the conditions that let QA do its job: making sure builds reach the testing team in a state worth testing, that defect tracking is integrated into the milestone picture, and that feedback from playtests gets into the development process in a form designers and engineers can act on.

Most productions of any size use some flavour of agile methodology. Scrum and Kanban are the most common, though studios frequently run hybrids adapted to game development’s particular rhythms. The internal producer needs to understand the methodology well enough to run it intelligently, to know when to hold the process and when to adapt it, and to explain to the team why the process serves the work rather than the other way around.

Who Becomes an Internal Producer?

There is no degree that leads directly to internal production, and no single career path that defines it. I’ve seen people arrive in this role from every direction, and the variety is genuine rather than the result of a permissive industry.

The most common starting point is game testing. QA work builds familiarity with the full project across all disciplines, and a good QA lead is already doing a version of production work: tracking issues, coordinating responses, managing relationships with multiple teams. The step into production is a natural one for someone who has been paying attention to how the project works rather than just cataloguing defects.

Development roles are another path. Programmers, artists, and designers who find themselves drawn to the whole project rather than just their piece of it sometimes move across. They bring something that pure administrators don’t: a working understanding of how the craft actually happens, which makes them more credible in conversations about feasibility and risk.

Product management from outside the games industry has become more common as studios have grown and professionalised. The planning and stakeholder management skills transfer well. The gap is games knowledge, and that can be closed over time, though it takes longer than people expect.

Education backgrounds in the people I’ve worked with span game design, computer science, digital media, business, humanities, and several things I wouldn’t have predicted. What they have in common is less about what they studied and more about what they developed: the ability to organise complex work, communicate clearly across people with genuinely different working languages, and think about the project as a system.

“The variety of routes into internal production is genuine rather than the result of a permissive industry.”

One thing I’d add, based on what I’ve seen across thirty years: the people who do well in this role tend to be the ones who were always asking questions at whatever they did before. The QA tester who wanted to know why a design decision was made that way. The programmer who noticed how the team’s morale changed when planning slipped. That curiosity about the whole, rather than the part, is usually already present in the people who go on to produce well.

What the Job Actually Looks Like

I’ll describe what a production day looks like for me, with the caveat that every project has its own rhythm and no two days are identical.

The morning starts with standup, and with checking whatever has come in overnight. On multisite projects or anything with partners in different time zones, overnight can mean anything. I want to know before standup whether anything has changed that affects what I’m going to say, so I’m reading messages and build reports before I’m in the room.

Standup itself is a fifteen-minute read on the state of each department. The goal is the team hearing each other’s blockers and making decisions about them. My job in that room is to ask the questions that don’t get asked without prompting, and to take note of the things that need follow-up.

The mid-morning is usually where the deeper work happens, before the afternoon fills with calls. This is when I’m in conversations with art about where a batch of assets is relative to where it needs to be, or with design about whether a feature has drifted from the original specification in ways that will cause downstream problems. These conversations are often shorter than I expect, and more useful than any written update I could have asked for.

Lunch is not a productivity opportunity. It’s the time I’ve found most useful for understanding how the team is actually doing, which is different from how the project is doing. Those two pictures sometimes diverge, and you notice it earlier in an informal conversation than you do in any structured check-in.

The afternoon shifts toward the outward-facing side of the role. This is typically when I’m putting together updates for whoever the project is accountable to externally: the publisher, the platform partner, studio leadership if that’s a separate relationship. The discipline of preparing those updates is useful even on projects where nobody is watching closely, because it forces me to know whether the picture I’m presenting is the one I actually believe.

Late in the day is when I’m catching things that have slipped through the rest of it: tasks that have stalled without explanation, dependencies that have shifted, anything that looks like it needs to be in the plan but isn’t yet. I do most of my documentation at this point too, because the decisions made during the day need a record, and that record rarely exists without someone deliberately creating it.

“The decisions made during the day need a record, and that record rarely exists without someone deliberately creating it.”

The end of the day is preparation for the next one. Not the next week, not the next milestone. The next day.

How Studio Size Changes the Role

One thing the job title doesn’t tell you is how much the role varies depending on where you’re doing it.

At a small studio, the internal producer is effectively covering all of production. You’re planning the schedule, managing the budget, running standups, coordinating with any external partners, handling stakeholder communication, and doing the administrative work that keeps the project moving. There may be no one else in the production function. You are it.

At a large studio, the same title describes something much more specific. You might own the schedule for one content track, or be the production lead for a single feature team, with other producers covering adjacent areas. The depth is greater and the scope is narrower. You’re a specialist, and the studio expects you to be.

Neither version of the role is better than the other. They develop different skills. The small studio producer develops range: the ability to pick up any production problem and address it. The large studio producer develops depth: a detailed understanding of how one part of the production machine works.

If you’re at the start of your career and trying to decide which environment to aim for, the honest answer is that both will teach you things the other won’t. What matters is being clear about which version of the job you’re actually taking on, because the gap between what the title implies and what the role requires is sometimes significant. A producer hired for a large studio’s specialist track who expects the breadth of a small studio producer will be frustrated. The reverse is equally true.

The other variable is methodology. Some studios are committed to Scrum. Some run Kanban. Most all use hybrid approaches that have developed over years to fit specific production contexts. The internal producer needs to be fluent enough in the underlying principles that they can work in any of these environments, because the studio’s process is a given by the time you arrive.

Part 2 of this post covers the tools of the trade, how the internal producer works with each department, why communication is where most production problems start, and the longer-term challenges and rewards of the role. Production 101 #3: Part 2 - The Tools, Relationships, and Daily Trade-offs picks it up from there.

Read the first few chapters. No strings.

On 30 October 2025, Rockstar Games fired 34 employees across its UK and Canadian offices. The reason given: gross misconduct, specifically the sharing of confidential information in what Rockstar characterised as a public forum. The IWGB, which had been quietly organising inside Rockstar for months, characterised it differently. Their workers had just reached the 10% membership threshold required under UK law to formally seek union recognition. The firings came two days later.

The union’s response, delivered on 28 May 2026, was a video timed to look exactly like a GTA 6 trailer drop.

It was not a trailer.

What happened, in sequence

The timeline documented by GameDev.net and confirmed across multiple sources runs like this:

Workers at Rockstar’s UK studios began organising in early-to-mid 2025, using a private Discord channel set up by the IWGB. In October, they crossed the 10% density threshold. On 30 and 31 October, Rockstar dismissed 31 UK employees and 3 in Canada. All 31 UK workers fired were union members.

Rockstar’s stated position, per a spokesperson quoted by Bloomberg: the workers had been “discussing confidential information in a public forum,” which constituted gross misconduct. The forum in question was the private union Discord. Rockstar also alleged, per TechRadar, that a union staff member may have been impersonated to gain access to the channel.

The IWGB filed unfair dismissal claims immediately. A preliminary tribunal in Glasgow on 5 January 2026 considered a request for interim relief, which would have reinstated the fired workers to Rockstar’s payroll while the full case proceeded. The tribunal declined to grant it. Interim relief carries a high legal bar. The IWGB’s position, per president Alex Marshall: “We’ve come out of last week’s hearing more confident than ever that a full and substantive tribunal will find Rockstar’s calculated attempt to crush a union to be not only unjust but unlawful.”

Meanwhile, 220 current Rockstar employees signed a letter demanding the immediate reinstatement of their colleagues. Three Scottish Labour MPs, Chris Murray, Tracy Gilbert, and Dr Scott Arthur, publicly accused the company of stonewalling legal proceedings. UK Prime Minister Keir Starmer called the case “deeply concerning” at Prime Minister’s Questions and committed ministers to investigate. Protests ran in London, Edinburgh, Paris, and New York.

Union membership, briefly dropped below 10% by the firings, climbed back above the threshold. Then kept climbing.

On 28 May 2026, the Rockstar Game Workers Union publicly launched under the IWGB, covering all five UK studios: Edinburgh, London, Leeds, Lincoln, and Dundee. The launch video hijacked the expectation of a GTA trailer by opening with the exact tone and pacing the community was waiting for, then pivoting to a seven-month account of firings, protests, and legal proceedings.

It has been watched by rather a lot of people.

This is a production story, not an HR story

The game industry and its press have mostly covered this as a labour rights story. It is that. It is also a live production risk on the most expensive game ever made, and almost nobody is framing it that way.

GTA 6 is scheduled for November 19, 2026. The union launched on May 28. That is less than five months from public launch to ship date. In production terms, that is the period when crunch is at its peak, when milestone pressure is at its highest, when the team is most stretched and most dependent on institutional knowledge.

“Behind every success story are tragedies such as layoffs, burnout, and broken promises. The industry must change, and together we will make it happen.” — Rockstar Game Workers Union launch statement, May 2026

That statement was made by people currently building GTA 6. During crunch. While an employment tribunal is confirmed. While their colleagues are running a public fundraiser for the legal defense. While management has, per PC Gamer’s reporting, not publicly responded to the union’s formation in any form.

The three demands are straightforward: pay transparency, flexible working, and an end to crunch. The flexible working demand connects directly to Rockstar’s 2024 return-to-office mandate, which per Spilled.gg required staff in five days a week, citing productivity and security concerns following the major GTA 6 leak. The crunch demand is the direct subject of this series.

None of these demands have been recognised by Rockstar or Take-Two. The union is not yet formally recognised. What it has is a confirmed full tribunal hearing, granted this week, public political support in the UK, and a membership that grew after the company tried to eliminate it.

The suppression playbook failed

From a purely strategic standpoint, what Rockstar did in October 2025 was the standard union-suppression move: identify the organising cohort, find a legally defensible reason to terminate, act before the recognition threshold is formally crossed.

It did not work.

The reason it did not work, in the UK specifically, is that the legal environment is less forgiving than in the US. The Employment Rights Act gives workers meaningful protections. Unfair dismissal claims are relatively accessible. The burden of proving the dismissals were for genuine misconduct rather than union activity will fall on Rockstar in a full tribunal, and their barrister was already characterised as presenting a “smokescreen” during the interim hearing.

More practically: firing 34 people who are organising turns 34 private organisers into 34 public martyrs. The story that was previously invisible inside a private Discord became a parliamentary issue, a protest in four cities, and a globally covered launch video timed to the most anticipated game announcement window of 2026.

As GTA Boom noted, every action Rockstar took to suppress the organising produced the opposite of its intended effect. This is not a novel outcome. It is the documented pattern every time suppression tactics are applied to a workforce that has already committed to organising.

The full tribunal ruling, confirmed this week by The Register, goes further than unfair dismissal. The IWGB will now argue that Rockstar compiled a blacklist, a physical or mental record of workers engaged in union activity, used to identify and target those dismissed. Blacklisting carries specific legal weight in the UK under the Employment Relations Act. Rockstar declined to comment on ongoing legal matters.

One more thing worth noting. Around the time the union launched, Take-Two CEO Strauss Zelnick told Fortune that Rockstar “doesn’t participate in crunch” and that the studio’s focus is “first and foremost on making a quality game.” The workers who just secured a full tribunal hearing on whether their colleagues were blacklisted for organising against crunch had no comment.

What this means for final production

I’m not going to speculate about whether GTA 6 ships on time. Rockstar has slipped schedules before and delivered eventually. What I will say is that the production conditions for this final push are unlike any AAA title in recent memory.

The team building GTA 6 is simultaneously in final crunch, navigating an active employment tribunal involving their former colleagues, working for management that has publicly declined to engage with their union, and operating under a return-to-office mandate that sits directly against one of the union’s three stated demands.

Crunch and contested labour relations in the same final sprint is not an abstract policy problem. It is a morale problem, a retention problem, and an institutional knowledge problem, all at once, in the window when a studio can least afford any of them.

The Naughty Dog model described in the second post in this series works partly because the contract between the studio and its workers is, however exploitative, clear. Stay, work hard, get a large bonus, leave when you’re done. Everyone understands the terms.

At Rockstar right now, the terms are contested. Management and workers are arguing, through lawyers and a tribunal, about what the terms even were. That is a fundamentally different production environment.

GTA V shipped in 2013 on a team that did not have a union, a tribunal, or 220 colleagues signing reinstatement letters. GTA 6 will ship on a team that has all three. Whether that produces a better or worse outcome for the game is genuinely unclear to me.

What is clear is that the crunch model described in Post 2 of this series, the bonus-incentivised voluntary overtime that Naughty Dog codified after The Last of Us, requires a workforce that has accepted the terms. When a meaningful portion of that workforce has formally and publicly refused them, the model stops being voluntary in any meaningful sense.

The next post looks at the mechanism behind Zelnick’s claim: how bonus-incentivised overtime at studios like Naughty Dog creates crunch without a single written policy requiring it.

This is Post 1 of 3 in The Crunch Files series. Post 2 covers how bonus-incentivised overtime creates crunch without mandating it. Post 3 covers the Game Workers’ Bill of Rights and what the proposals actually mean in production terms.

Game producers already have most of what AI collaboration requires. They have been managing context, decomposing work, and evaluating output for years. This book is the map from where they are to where the work is going.

Read the first few chapters. No strings.

The tools are moving faster than any book can track. That is not the problem this book solves.

The problem is the translation gap. Working game producers already have most of what effective AI collaboration requires. They have been managing context, decomposing work, and evaluating output from human collaborators for years. The distance between where producers are and where they need to be is shorter than the industry is making it sound.

What is missing is the map.

Outlast the Tools is that map. Across twelve chapters, it covers the five transferable producer skills, how to build an AI operational harness that runs at 98.4 per cent deterministic infrastructure, how to manage context so that work does not disappear between sessions, and how to apply constraint theory, forecasting discipline, and flow metrics to AI-integrated delivery. The final chapters cover reading AI output with the same investigative habit that experienced producers apply to status updates. Confident, fluent, and wrong is a failure mode that looks identical whether the source is a team member or a language model.

The book is deliberately tool-agnostic. No chapter is built around a named product. The field moves too fast for named recommendations to hold. Producers who build their AI workflows around a framework will outlast every model release. Producers who build around a specific tool will be rebuilding every eighteen months.

The authority here comes from the seat, not the whiteboard. Thirty years shipping games. The argument is not that AI will change everything. The argument is that the producers best positioned to lead that change are already in the building, and they are closer to ready than anyone has told them.

Table of Contents

• Introduction: Thirty Years and One Honest Admission

• The Thing AI Cannot Do

• Chapter 1: Your Expertise Is Invisible. AI Just Made It Visible.

• Chapter 2: Engineers Had to Invent What You Already Do

• Chapter 3: The System Is the Work

• Chapter 4: The Model Will Change. Build Accordingly.

• Chapter 5: Before the Idea Hardens

• Chapter 6: Requirements Are Hypotheses

• Chapter 7: The Constraint Is Not Where You Think It Is

• Chapter 8: Design the Environment, Not the People

• Chapter 9: Quote a Probability, Not a Promise

• Chapter 10: Assume Nothing

• Chapter 11: Make Competence Legible

• Chapter 12: The Loop With a Human in It

• Closing Bookend: Is It Actually Better?

• About the Author

Read the first few chapters. No strings.

• Little’s Law says lead time equals WIP divided by throughput. Studios treat a full pipeline as good news.

• Goldratt says every system has one constraint. Optimising everything else is wasted effort.

• Conway’s Law says your pipeline looks like your org chart. Reorganising teams without changing communication changes nothing.

• The three laws compound. That’s why fixing one thing rarely fixes the problem.

There’s a pattern I’ve seen enough times that it no longer surprises me. A studio with no shortage of work, no shortage of people, and no shortage of slipping dates. Everyone is busy. Nothing is shipping on time. Ask why, and you get a different answer depending on who you ask: scope, resourcing, communication, dependencies, leadership. Everyone is right about a symptom. Nobody is right about the cause.

Subscribe now

The cause, in most cases, is that three well-understood laws are being broken simultaneously. The laws aren’t obscure. They predate the game industry by decades. Two come from hard science, one from observation, and none of them care whether you’re aware of them. You don’t need to believe in them for them to operate on your project.

I’m going to describe each one and what it looks like when a studio breaks it. Then I want to explain why they compound, because that’s where the diagnostic value sits. Individual symptoms point to individual laws. When a project is genuinely in trouble, you’re usually dealing with all three at once.

Little’s Law and the full-pipeline trap

Little’s Law comes from queuing theory. The equation is: lead time equals work in progress divided by throughput. If you want things to move faster through your pipeline, you either increase throughput or reduce what’s in the pipeline. There is no third option.

The studios I’ve seen struggle with this treat a full pipeline as a sign of health. A backlog stretching five cycles deep reads as security: work lined up, team occupied, no gaps. What it actually signals is slower delivery per item, because every new thing you start competes with everything already in flight for attention, handoffs, and reviews. You’re not preventing gaps. You’re lengthening the queue.

An empirical study of over 8,000 work items across five software teams confirmed what the equation already predicts: lower WIP correlates directly with shorter lead times. This is not a management theory. It’s arithmetic.

I watched one studio respond to slipping dates by adding people. It’s the intuitive move. More hands, more output, faster delivery. Except their WIP didn’t shrink, it grew. New team members meant new work started, new dependencies created, more items entering the pipeline simultaneously. Lead times continued climbing. They’d addressed capacity without addressing flow. Two different problems, easily confused.

The backlog isn’t a list of priorities. It’s an active liability if it’s too long. Every item sitting in it is lead time waiting to accumulate. The length of your backlog predicts your delivery pace as directly as the WIP equation does, because a bloated backlog is just upstream WIP with better formatting.

The fix feels wrong. Stopping new work from starting, pushing back on scope, enforcing WIP limits all look like slowdowns. The board moves faster when there’s less on it. Studios that accept this take a short-term hit to utilisation and a significant long-term gain in throughput. Most studios accept neither, so they add people and watch the dates slip.

Goldratt’s constraint and the optimisation trap

Eliyahu Goldratt’s observation, which he formalised into the Theory of Constraints, is that every system has exactly one element limiting its throughput at any given time. One constraint. Not several.

The implication is uncomfortable. If you accept it, everything you do to improve a non-constrained resource is theatre. You’re making a part of the system faster that isn’t the limiting factor. The system’s overall output stays the same. You just feel like you’re doing something.

“The constraints will determine the output of the system whether they are acknowledged and managed or not.”

I’ve seen this play out in a way that looked, at the time, like productive management. The studio had an obvious constraint: review and approval. The board made it visible. Work stacked up waiting for sign-off at a rate that had been consistent for months. The response was to hire more artists. The logic seemed sound: output was too low, add capacity. Except output wasn’t the constraint. Reviews were. More artists meant more work completed per cycle, which meant more items entering the review queue, which meant the queue grew faster, which meant lead times kept climbing despite the additional headcount.

The constraint was optimised around, not at. Nobody in a position to fix the review process owned the problem, and nobody who owned the problem had the authority to fix it. The constraint stayed. The payroll grew.

This is common because constraints are politically inconvenient. They tend to sit in approval paths, in senior decision-making, in resource handoffs that cross team boundaries. Fixing them requires authority that producers often don’t have and conversations that organisations often avoid. Hiring more people or switching tools are easier decisions with cleaner paper trails.

Goldratt’s prescription for non-constrained resources is to keep them deliberately underloaded, somewhere around 80-85% of capacity, so they don’t produce faster than the constraint can process. This sounds like waste to a studio that measures utilisation. It isn’t. Full utilisation upstream of a bottleneck is how you build a queue. A queue is stored lead time. You’re not saving time by keeping everyone busy; you’re borrowing against future delivery.

The goal isn’t to find the constraint and then optimise everything around it. The goal is to find it, protect it with buffer, fix it, and then find the next one. The constraint moves. The method doesn’t.

Conway’s Law and the reorganisation trap

Melvin Conway’s observation from 1968 has held up without much amendment: organisations design systems that mirror their own communication structures. In game development, that means your pipeline will look like your org chart. Your dependency map will follow your reporting lines. Your integration problems will appear precisely at the boundaries between your teams.

This isn’t a cultural observation. It’s a structural one. You can’t design a system that communicates differently from the organisation that built it, because the design decisions are made by people talking to each other, and their conversations are bounded by how the organisation allows them to talk. The system is a projection of those conversations.

I’ve seen this in two forms, which are instructive in different ways.

The first: a studio reorganised into cross-functional squads. The intention was faster feature delivery, fewer handoffs, more ownership per squad. In practice, the squads worked like squads in their daily check-ins and like siloed departments in every decision that required sign-off. The reporting lines didn’t change. The approval paths didn’t change. The communication structure didn’t change. At integration, the work looked exactly like work produced by siloed departments, because the squads were siloed departments with a different name on the org chart.

The second is stranger and, once you know the law, completely predictable. A shipped game whose architecture nobody deliberately designed. The rendering pipeline, the content pipeline, the live systems, all cleanly separated in ways that matched the team structure almost exactly. Art, engineering, and LiveOps had operated largely independently throughout production. The game reflected that. The seams in the product were at the same places as the seams in the team.

Conway’s Law doesn’t discriminate between good and bad outcomes. It maps communication structure to system design. If the communication pattern suits what you’re building, the system will suit it too. If the communication is fractured, siloed, or running along the wrong boundaries for the product, the system will be fractured in exactly the same places.

The inverse version of the law is the useful one for producers: if you want a particular system design, build the communication structure that would naturally produce it. Reorganising the boxes on a chart is not the same thing.

Why they compound

The reason fixing one thing rarely fixes the problem is that the three laws interact, and they interact in ways that accelerate each other.

High WIP starves the constraint. When everything is in flight simultaneously, the constraint receives an uneven stream of work: bursts followed by gaps, or more than it can process without the upstream teams noticing. Neither is good. Goldratt’s prescription of a buffer before the constraint only works if WIP is controlled enough for the buffer to be meaningful. If the whole system is overloaded, there’s no clean buffer, only a general backlog that hides where the real pressure is.

A mismanaged constraint accelerates WIP accumulation. Work completes upstream faster than it clears downstream. The queue grows. Lead times extend. Teams interpret the delays as a coordination problem rather than a throughput problem and respond by starting more work to demonstrate progress. Which grows the WIP. Which grows the lead times.

An org structure that fights the work pattern prevents either from being fixed. If the people who can see the constraint don’t own it, and the people who own it can’t see it, the diagnosis doesn’t happen. The squad reorganisation doesn’t help if the communication structure generating the bottleneck is left intact. The constraint is in the approval path. The approval path follows the reporting lines. The reporting lines survived the reorganisation unchanged.

The useful question when a project is in trouble is which law is primary. Is this a WIP problem, a constraint problem, or a communication structure problem? They’re usually all present. One is usually loudest. Identify which one is driving the others and start there. Treating a communication problem with WIP limits, or a constraint problem with team restructuring, is what produces the feeling that you’re doing everything right and nothing is improving.

That’s not a formula. It’s a way of looking. The looking is the skill.

Leave a comment

Once you can see through these three lenses, the problems stop looking like bad luck or individual failure. They become predictable consequences of decisions made months earlier: the planning session where everything was marked high priority, the hiring decision that added capacity to the wrong stage, the reorganisation that moved boxes on a chart without touching how decisions actually got made.

Uncomfortable if you made those decisions. Useful if you want to make better ones.

• Why most agentic workflows fail at the session boundary, not the prompt

• Context windows are RAM, not storage, and treating them otherwise quietly breaks everything

• The fix is structural: stateless processor, durable file-based memory, session-start protocol

• What this looks like in pre-production, and why producers are the right people to build it

Monday morning. I sit down. I open an agentic harness, like Codex or Claude Code. Before any actual work happens, I type a paragraph that goes something like “so where we are is, we resolved the weapon spec last week but the environment LODs are still open, the client hasn’t replied about the priority on...” and so on, for roughly two hundred words, before I can ask the first useful question of the week.

Subscribe now

That paragraph is a tax. It shouldn’t exist. The fact that I’ve quietly accepted paying it, and that most people I talk to building agentic workflows have also quietly accepted paying it, tells you something about how the field is designing these things.

The Monday brief is the symptom. The diagnosis is that we are building agentic workflows as if the AI is a colleague who went home for the weekend and forgot a bit. It isn’t. It went home and was destroyed. The thing on Monday morning has never existed before.

Context windows are RAM

The conceptual error is treating the context window as storage. It looks like storage from the inside. You scroll up and the conversation is still there. You add to it and it gets longer. So when an agentic workflow starts to misbehave, the instinct is to feed it more: a larger model, a fuller history, a more careful prompt.

The mem0.ai team wrote about this and the framing is the cleanest I’ve seen. The context window shares properties with RAM that distinguish it from persistent storage and make it unsuitable as a long-term data store. It is volatile, and everything in it disappears when the session ends, including preferences stated at turn 1, constraints set at turn 3, and decisions made at turn 7. Beam.ai has written about the same idea. The most common failure in production is an agent that remembers nothing between sessions. The context window resets. Every preference, every learned behaviour, every correction the user made in the last conversation is gone.

This is not a niche failure. Gartner found that 61% of organisations had begun their foray into agentic AI development, and predicts that 40% of agentic AI deployments will be cancelled by 2027 due to rising costs, unclear value, or poor risk controls. Other research is bleaker. Carnegie Mellon’s TheAgentCompany benchmark tested ten leading AI agent models across 175 real-world tasks. The best performer completed just 30.3% of tasks. RAND concluded that more than 80% of AI projects fail, twice the rate of non-AI IT projects. S&P Global found that 42% of companies abandoned most of their AI initiatives, up from 17% the prior year.

A lot of factors drive these numbers. State management is one of the load-bearing ones, and it’s the one producers run into first because we live by continuity. A producer who can’t remember what happened last week is not a producer. So when our tooling has no memory between sessions, we patch it ourselves. We type the brief. We re-explain. We feel productive because the response on Tuesday looks coherent.

A larger context window delays the problem. It does not fix it.

The fixes that the wider conversation gravitates to all address the symptom. Bigger windows. Better summaries. Compaction. Hybrid memory schemes. They share an assumption: that the right place for state is inside the model’s working memory, and the work is to keep that memory healthy. This is the same idea as managing a goldfish’s working life by getting it a bigger bowl. The goldfish still forgets the bowl every twelve seconds.

Worse, summary-based fixes degrade actively. Summaries summarise summaries. The history gets blurrier and the agent starts answering with confidence based on a compressed version of a compressed version of what you said three sessions ago. The brief gets longer, not shorter, because you’re now also correcting the agent’s distorted model of where things stand.

The Monday brief is your workflow telling you it doesn’t have a place to keep things.

State lives in files

The fix is structural. Stop trying to make the AI remember. Build a system where it doesn’t have to.

State lives in files. The AI is a stateless processor that reads from and writes to a shared file system. Memory is durable, external, and human-readable. Every open question, every assumption, every decision lives in a structured file with an ID, an owner, and a timestamp. Nothing lives only in chat. When a question gets raised during a design session, it gets written to the tracker immediately. When a decision gets made, it gets written to the decision log with rationale.

At the start of every session, the AI reads the files. That’s the briefing. Not me typing two hundred words on a Monday morning. The system already knows where things are because the files already know where things are. The AI just reads them.

Context window resets become a non-event.

This is the move that breaks the whole class of problem. Every horror story about agentic AI losing context, dropping decisions, or contradicting itself across sessions, almost all of it dissolves the moment state stops living in conversation history.

The mechanics are straightforward. You need a small set of structured files: an open questions tracker, a decision log, an assumptions ledger, an inbox for things that come in between sessions. Each entry has a stable ID. Each ID links to context. The AI’s first action in any session is to read these and report what is unresolved, what is blocked, and what needs a call. The AI’s last action is to update them.

A developer would recognise this as a database with no DBMS. It is. The thing that makes it work for a producer rather than a developer is that the files are human-readable. I can open a markdown file at 11pm and see exactly what’s open. No query. No tooling. The files are the system of record and they’re also the briefing document and they’re also the audit trail.

The session-start protocol is the second half of the move. The AI doesn’t decide to read the files because I asked nicely. It reads them because that’s the first thing it does, defined in a skill or a CLAUDE.md or whatever your tooling calls it. The skill says: at session start, read these files, summarise their current state, flag anything blocking, surface anything that needs a decision today. Then we work.

What this gives you is something that survives context window resets, model upgrades, app crashes, and the gap between Friday night and Monday morning. The state is in the files. The AI reads them fresh. There is no Monday brief because there is nothing to brief about.

The asymmetric collaboration

Where this lands in pre-production is worth dwelling on, because pre-production is where the cost of bad state management is highest and where the win is biggest.

Pre-production generates a specific kind of cognitive debt. Open questions that nobody answered. Assumptions that hardened into facts before anyone checked them. Decisions that were made in a Slack thread and never written down. By the time you hit production, that debt is invisible and expensive. Most projects take 25-30% longer than expected. A chunk of that overrun is debt being paid down by people who don’t know they’re paying it.

A human producer can track a sprint’s worth of this. Not a full pre-production cycle. The volume defeats us. The cross-domain spread defeats us. The lag between when a question is raised and when it gets resolved defeats us. So we drop things. Not because we’re bad at the job, but because the job at full volume is bigger than what one head can hold.

This is where the agentic system earns its place. The AI tracks everything. It captures questions as they surface. It assigns IDs and links them to the relevant spec area. It flags when an unresolved assumption is blocking other work. It routes questions to the right specialist for a draft answer. It updates status when something resolves. None of this needs my judgement. All of it needs to happen.

The human decides everything. Scope calls. Risk acceptance. Trade-offs between competing answers to the same open question. Anything that touches shared systems or external stakeholders. The decisions get made by the person whose job it is to make them. The bookkeeping gets done by the thing whose job it is to do bookkeeping.

The AI handles the volume. The human handles the judgement.

This split is the actual wedge for producers in agentic work. Most of the conversation about AI in production is framed as the AI doing the producer’s job. That framing is wrong twice. It overestimates what the AI can decide, and it underestimates what the producer’s job actually is. A producer’s job is the queue of open questions, the integrity of the decision log, the visibility of dependencies, and the deliberate spending of a small attention budget on the right calls. The AI can absorb the first three. It can’t do the fourth. So the producer does more of the fourth. Better.

The skill of being a producer transfers cleanly into the skill of running an agentic workflow because the discipline of tracking is the discipline we already practise. We were already trying to do this manually and failing because the volume was too high. The AI makes the volume tractable. We get an instrument that lets us play the craft we already know.

The AI in this system doesn’t make product decisions. Its job is to make sure nothing falls through the cracks and that the human has everything they need to make good calls fast. The value is in the tracking fidelity and the structured surfacing of what’s open. The AI has no opinion about what to build. Its opinion is about what’s been left undecided. Those are different things.

Leave a comment

Pre-production is full of irreversible decisions made under uncertainty. The system doesn’t reduce the uncertainty. It makes sure the decisions get made deliberately, with full visibility into what is open and what depends on what, rather than quietly becoming assumptions that nobody remembers making.

If you sit down on Monday and have to tell the AI where you left off, you haven’t built an agentic workflow. You’ve built a chat tool with extra steps.

• Why thirty years of unified planning-and-tracking tools have produced consistently weak results

• The structural reason a single tool cannot do both jobs well

• What production teams have actually been doing in the gap, and why it isn’t clerical

• Why an agentic workflow between two specialist tools beats any promised unified one

The first project management tool I ever used was Microsoft Project. Before getting into the game industry, I had exposure to the tool for planning construction projects. I didn’t know what lead or lag me” meant. Critical path was a phrase I’d encountered in a textbook and dismissed. Task relationships looked like spaghetti. The plan I built was beautiful in the way a child’s drawing of a house is beautiful, and about as accurate when held up to the real building.

Subscribe now

It worked for planning. It fell apart for tracking. I spent most Friday afternoons guessing what percentage complete each task was. Sixty-five? Seventy? The number didn’t mean anything except that I had typed it into a cell, and then the Gantt would update, and the report would go out, and the project would carry on bearing no obvious relationship to the chart.

That was the start of a thirty-year search for one tool that could do both jobs. I want to write down, before I forget, that I think the search was a mistake.

The tour

Before Jira, the best bug database I ever built was in FileMaker Pro. This will sound mad to anyone under forty. FileMaker was the GOAT of QA tracking in the late nineties because you could hand-roll a relational database with a layout designer in an afternoon, give the QA team a form, and have ticket fields that actually fit your studio’s workflow. Custom statuses, custom severity, custom triage paths, custom resolution workflows. The bespoke nature was the point. We tracked thousands of bugs through ship windows and the producers who maintained those databases were treated with the kind of respect normally reserved for tools that work.

What FileMaker couldn’t do was plan. There was no Gantt, no dependency, no critical path. You had a tracker. You had nothing to track against. So you ran two systems anyway.

Jira arrived and I assumed the search was over. It wasn’t. I have spent more than half my career looking for the perfect Jira plugin, the next major release that would finally make roadmaps fit my use case, the marketplace add-on that would close the planned-versus-actual gap. Tempo. Structure. BigPicture. Advanced Roadmaps, then Jira Plans, then whatever Atlassian is calling it this quarter. Plugin trials, evaluations, pilots, budget justifications. I have written more business cases for project management tooling than I have for actual projects.

Then came the Jira replacements. We had a serious bake-off between ClickUp and Monday.com in one studio, which generated more political heat than the actual game we were trying to ship. After that I went down the premium roadmap tool route, accepted that two systems was the price of admission, and let the production team pick up the manual plan-and-actual reconciliation. Which they did. Friday after Friday, spreadsheet open on one monitor, Jira open on the other, producing a status report that looked at the world both ways.

I never let go of the idea that the right tool would arrive. It always seemed close. The next version, the next plugin, the next migration.

Planning is a story about the future. Tracking is a record of the present. The two have never agreed and they never will.

Why no tool can be both

The reason no unified tool works well is structural. Planning and tracking want opposite things from a data model.

Planning wants estimates. It wants capacity, milestones, lead and lag, what-if scenarios, dependency graphs, the ability to drag a bar across a calendar and have the consequences ripple through. The data is editable, opinionated, and forward-looking. A good plan is a thing you argue about with stakeholders.

Tracking wants ground truth. It wants the current state of a ticket, the actual time logged, the actual blockers, the actual transitions. The data is append-only and backward-looking. A good tracker is a thing you do not argue with, because it just reports what happened.

These are different shapes of information. The buying committee keeps asking for them in one tool because the diagram is simple and the demo is impressive. The vendors keep promising it because the diagram is simple and the demo is impressive. The result is always weak at both jobs. Jira Plans is fine for a roadmap and weak for a planned-versus-actual report. Smartsheet is a good planning canvas and a poor home for engineering workflow. Monday and ClickUp try to do both and end up doing neither with conviction. The Atlassian Marketplace has hundreds of add-ons partly because the base product cannot resolve this tension.

The market data confirms the pattern from a different angle. The average organisation runs eleven project management tools and ten team collaboration apps, and 79 percent have taken no steps to consolidate. Workers lose roughly 9.3 hours a week to searching for information across these systems. The tools are not delivering the unified picture they were sold on. They are producing more places for the picture to live.

The honest read is that planning tools and tracking tools are different categories of software pretending to be one. The unified tool is a marketing position.

What producers have actually been doing

The reconciliation work has been done all along. By producers, on Friday afternoons, in spreadsheets, by hand.

I want to be careful about how I describe this work, because it has been routinely underestimated by everyone who has not done it. It is not data entry. It is judgement. It is knowing that Ahmed’s tickets are always two days behind reality because he updates them in batches on Friday morning. It is knowing that the Environment lead is honest to a fault about percentages and will report sixty when most people would report eighty. And it is recognising which “in progress” is real work and which is a ticket that got dragged across the board after a stand-up because someone felt guilty.

A good production status report is not a screen-grab of Jira against a Gantt. It is a synthesis of the plan, the tracker, and the producer’s working model of which humans report which way. Tools have tried to automate this for two decades and have not succeeded because the inputs are dirty and the rules are situational and the judgement is local.

The reconciliation work isn’t clerical. It’s a judgement about which gap is a signal and which is a person who forgot to update a ticket.

This is the work that gets squeezed when a project is busy and the producer has eight other things to deliver. So it gets a quick pass, or a delegated pass, or no pass at all. The report goes out late, or wrong, or as a bare reflection of the tracker with no producer interpretation laid over the top.

The example

Last week I ran one of these reports for a project I’m producing. I pulled a Smartsheet export of the plan as of that morning. I pulled the current Jira state. I gave both to a workflow I’ve been building, told it the format I wanted, and let it produce the synthesis.

The output read like a status report a competent producer would write. Section by section: art tracks against plan, RAG-coded, with the cascade risks called out. It picked up that one track had not been activated in Jira at all, despite the plan saying several stages should already be complete. It connected that to a downstream gate that was due to start two days ago. It identified three open plan risks I had previously flagged in a briefing document and noted that none were blocking today but each could re-sequence mid-sprint. It recommended I check the track directly with the lead, because the gap between plan and Jira state could mean either work happening off-ticket or work that genuinely hasn’t started.

That is the report I would have written. It took fifteen minutes instead of two hours. The agent did not fix the underlying data problem, which is that ticket discipline is uneven, but it did the synthesis I would have done with the data as it stood. I will run it again this evening against fresh Jira state. The plan is to wire it directly to the Smartsheet API so I do not have to download a snapshot to drive it.

The piece that matters: I used the time I saved to validate, not to compile. The output of the workflow is a draft I review and edit, and the editing is the producer work I should have been doing all along.

This is different from the single source of truth

Every project management vendor for the last fifteen years has sold some version of the single source of truth. The pitch is always the same: bring planning and tracking into one tool and you will have one place to look. It has never landed. The two jobs cannot share a schema without one of them being deformed to fit the other.

The agentic approach starts from the opposite premise. Keep the two tools. Let planning be planning, let tracking be tracking, let each be best in its category. Compute the bridge on demand.

The bridge is not stored. It is recomputed every time you need it, which means it is always current as of the last data pull. There is no reconciled artefact that sits in a third system and immediately goes stale. There is no nightly job that produces a report that is wrong by lunchtime. You ask the agent for the picture, the agent walks the two sources, the picture comes out.

This is a different shape of solution. It does not depend on the two underlying tools agreeing about anything except their respective domains. It does not require a migration. It does not require everyone to abandon the planning tool they like or the tracker they have invested in. It treats the two systems as facts of life and adds a layer on top that does the work a person was doing anyway.

What changes for producers

The reconciliation has been an invisible cost for as long as I have been doing this work. Producers do it, leadership rarely sees it, and the time it takes is loaded onto the producer’s other work without being booked anywhere. Removing it changes the shape of the producer’s week.

The first change is obvious. Less time compiling, more time validating. I still read the output. I still push back on the agent’s conclusions where they look wrong. I still talk to the leads about what the report is missing. The work is now editing rather than typing.

The second change is sharper than I expected. The “people are not updating their tickets” problem does not go away, but it stops being invisible. When the agent surfaces a track with no activated tickets against a plan that says work should be three stages in, the next conversation is unavoidable. Either the work is happening and not being captured, or it is not happening. Both answers are useful. Neither was reliably surfaced before, because the producer compiling the report was tired and Friday was nearly over.

The third change is about scale. One producer running these workflows against a portfolio of projects can cover more ground than the same producer compiling reports by hand. The judgement is still the constraint. The compilation is no longer the constraint. That ratio matters when studios are running lean.

Stop looking

I have spent thirty years looking for the tool that doesn’t exist. The honest answer is that the tool I was looking for cannot be built, because the requirements contradict each other.

Leave a comment

Pick the best planning tool you can find. Pick the best tracking tool you can find. Let them be different. Wire an agent between them. The bridge will be computed, current, and good enough to act on, and the producer will get the Friday afternoon back.

The single most stressful thing about being a game producer is committing to a delivery date. I have done it for thirty years and it never got easier until I changed the method.

You sit in a room. Someone senior asks when it will ship. You give a number. You then spend the next eighteen months defending that number to people who weren’t in the room. The number is almost always wrong. Everyone knows it’s almost always wrong. The pretence that it isn’t is the part that breaks you.

Subscribe now

Why the estimate is broken before you start

In 1979 two psychologists, Daniel Kahneman and Amos Tversky, published a paper that quietly described the producer’s entire problem. They called it the planning fallacy. People underestimate the time, cost, and risk of future tasks, and they do so even when they have a long history of being wrong about the same kind of task.

Kahneman later argued that the cause is something he called the inside view. When we plan a project we tell ourselves a coherent story about how it will go. The story is plausible. It does not include the things we don’t yet know. The outside view, by contrast, asks what happened the last time we did something like this. The outside view is duller and almost always more accurate. Almost nobody uses it.

The Decision Lab summarises decades of follow-up research in plain terms: the planning fallacy describes our tendency to underestimate the amount of time it will take to complete a task, as well as the costs and risks associated with that task, even if it contradicts our experiences. The word that matters is “even.” We know we’re wrong. We do it anyway.

For a producer the bias is doubled. You are estimating other people’s work, not your own. You are estimating it under pressure. You are estimating it while someone in finance is asking whether you can pull a quarter forward.

The toolkit I used to reach for

Every estimation method I learned in the first half of my career was a different way of structuring the same wishful thinking.

Parametric estimation was the first. Take the size of the thing, multiply by a coefficient drawn from history, and produce a number. It works for buildings. It works less well for software, and it works worst of all for games, where the scope is unstable until late in production.

Top-down came next. Senior people decide what the thing should cost, and the team is asked to make it fit. Bottom-up was the inverse. Add up every task and produce a total. Both produce numbers. Neither produces forecasts you can trust, because the inputs at every level are guesses dressed up as data.

Three-point PERT was the one I held onto longest. You ask each lead for an optimistic, pessimistic, and most-likely estimate, then weight them. The weighting felt like rigour. It wasn’t. It was three guesses instead of one. The biases I was trying to remove sat inside each guess.

Averaging biased numbers produces a biased average.

These techniques have their place. They will give you a directionally useful figure for a pitch deck. What they will not give you is a forecast you can defend at month nine of an eighteen-month project, when reality has diverged and someone in the C-suite wants to know why.

The first probabilistic approach I trusted, and what was wrong with it

When I first read the PMBOK section on Monte Carlo simulation I thought it was the answer.

The idea is simple. You take your estimates, attach a probability distribution to each one, then run the model ten thousand times. The output is a distribution of possible completion dates. You can read off a confidence level: 50%, 80%, 95%. You can size your reserves against the tail. The maths is sound. The software is cheap. I used it for years to calculate slack and contingency.

The problem was upstream. Every input to the simulation was a biased estimate. I was running the simulation on numbers I already knew were wrong. The probability curve was elegant. The baseline it was built on was not.

This is the failure mode that does not get discussed enough. A probabilistic technique applied to a biased baseline gives you a probabilistic estimate of a biased baseline. The maths is still right. The conclusion is still wrong.

You have dressed up the planning fallacy in a normal distribution and a confidence interval.

The other half of the problem nobody talks about

There is a second pressure that runs underneath all of this, and it changes the maths in a way most estimation books do not address.

Producers are often not asked when something will ship. They are told. The ship date is set by a marketing window, a fiscal calendar, a co-development agreement, or a publisher’s slate plan. The budget is set the same way. You are then handed a piece of work and asked to produce a plan that arrives on the date and lands within the budget.

In that situation the estimate becomes a reverse-engineering exercise. You start with the answer and work backwards. The pretence of an objective forecast is dropped. What you are doing is constructing a plausible-looking justification for a commitment that has already been made.

The estimate becomes a reverse-engineering exercise. You start with the answer and work backwards.

The reason this matters for the conversation about Monte Carlo is that the upstream methods I described above are all inputs to a process that begins with the answer. PERT does not save you if the answer is fixed. Parametric does not save you. PMBOK Monte Carlo does not save you, because the simulation runs on baselines you reverse-engineered to fit.

The shift that actually helped

The thing that changed for me wasn’t a better estimation technique. It was a different input.

I had been reading Eli Goldratt on the Theory of Constraints and trying to understand how work actually moves through a development system. From there I came to David Anderson’s Kanban method, and then to Don Reinertsen’s Principles of Product Development Flow. Reinertsen opens by arguing that the conventional approach to product development is fundamentally broken, then spends the rest of the book explaining why. His central claim is that invisible queues are the underlying cause of slow product development, and that batch size, work in progress, and variability matter more than the schedule on the wall.

What this body of work pointed me towards was a different kind of data. Instead of estimating how long a piece of work would take, I could measure how quickly the team was actually finishing work. Cycle time. Throughput. Work in progress. The metrics already existed in the ticketing system. I had simply not been treating them as the basis for a forecast.

Daniel Vacanti’s two books, Actionable Agile Metrics for Predictability and When Will It Be Done?, made the connection explicit. You can run a Monte Carlo simulation against historical throughput data instead of against estimates. The simulation samples the team’s past performance, randomising the order, and produces a forecast distribution for the work remaining. Most implementations run ten thousand iterations and take a few seconds to complete.

The baseline is no longer a guess. It is what the team has actually done, last month, last quarter. It updates every week you run it. The longer the project runs, the more reliable the forecast becomes, because the data informing it is the data the team is generating.

Vacanti has a line on this. “No WIP limit = no flow, which means no predictability.” It captures the discipline this method requires, and it is the part that gets cut from most adoption stories.

What changes in the C-suite

The thing producers do not always get to talk about is the meeting. The MBA in the corner office wants a date. They have been asked the same thing by their board. The conversation is short, the room is hostile, and you have one chance to defend your position before next quarter’s planning cycle re-opens it.

With PERT and a Gantt chart you have an opinion. With flow-based Monte Carlo you have a probability curve generated from the team’s measured performance. You can say: at the team’s current throughput, simulated across ten thousand iterations, there is an 85% probability the work completes by date X, a 50% probability by date Y. If you want to land closer to Y, here are the constraints I need lifted. Here is what changes about scope, headcount, or work in progress.

This is a different conversation, with a different artefact on the table. The MBA can argue with the data, the inputs, the model, the assumptions. They cannot easily argue with a curve built from their own team’s last six months of work.

You will still lose some of those arguments. The commitment will get fixed for reasons that have nothing to do with your forecast. The difference is that you have shown your working. When the project goes sideways at month nine, you can pull out the forecast from month one and the forecast from month nine, and the trajectory tells the story. The conversation moves from blame to what changed.

What this asks of you

I want to be honest about what flow-based forecasting requires, because the adoption is harder than the maths.

It needs WIP limits that are actually enforced. Work in progress is the enemy of throughput in any queueing system, and the moment you allow unlimited parallel work, your cycle time data becomes meaningless. Reinertsen spends a chapter on this. Vacanti opens with it.

It needs a stable process. If the team is reorganising every six weeks, the throughput data from the last quarter does not apply to the next quarter. The forecast assumes the system you measured is the system you are forecasting about.

It needs the data to be collected honestly. Started dates and finished dates on tickets, with no fudging when the sprint review approaches. If your team’s Jira hygiene is poor, your Monte Carlo is poor. The software cannot rescue the data.

It needs the producer to have read enough of Vacanti, Reinertsen, and Anderson to defend the model when challenged. The MBA in the C-suite has likely done a quantitative MBA. They will ask questions. You need to be able to answer them without flinching.

None of this is exotic. Around twenty to thirty completed cycle times in the historical sample is the rough threshold before the forecast stabilises. The tools are mature. The books are short. The technique is available to anyone running a board in Jira, Linear, or Azure DevOps.

What changed for me

I stopped defending dates I did not believe in.

That is the smallest possible version of what changed, and it is also the whole thing. When the conversation moved to a probability curve I could rebuild every fortnight, the arguments got shorter. The forecasts got better. The relationship with the C-suite changed from quarterly confrontation to ongoing recalibration. Dates still slipped. The slippage was visible earlier, and the conversation about what to do about it was no longer a fight about whose gut was more credible.

Leave a comment

Thirty years in, I wish I had found this fifteen years sooner. That is the only part I would take back.

• 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

• elysi trimmed Claude Code Game Studios to 49% of its original size, wrote 15 bash helpers, capped tech-debt at 50 items, and built a 1,081-test suite, none of which shipped with the framework

• The LinearB 2026 Software Engineering Benchmarks Report finds AI-assisted teams see technical debt increase 30-41% after adoption; the top 20% impose quality gates and governance constraints before the debt compounds

• The Toyota Production System calls it jidoka: detect the problem, stop the process, fix the immediate condition, prevent recurrence. elysi did all four, on day 19, with a migration script and a new constraint set

• The framework is the substrate. The harness is the production system. One can be downloaded. The other can’t

19 days into a run of Claude Code Game Studios, a community user named elysi stopped.

The agents were arguing. The tech-debt register was bloating. The studio was generating output, but the quality of that output was degrading with each sprint. At this point, most users do one of two things: they prompt harder, or they blame the framework. elysi did something else. They treated the degradation as diagnostic data, and they stopped the line.

Subscribe now

Their account of the decision, posted in GitHub Issue #46, is the most instructive production sequence in the CCGS community data, and it has very little to do with the framework itself.

What the data says about this moment

The degradation elysi experienced is the predictable second act of AI-assisted development, and the research describes it consistently.

The LinearB 2026 Software Engineering Benchmarks Report, drawing on analysis of 8.1 million pull requests from 4,800 teams, found that technical debt increases 30-41% after AI coding tool adoption. AI-generated code contains 1.7 times more issues than human-written code. Developers working with AI tools report feeling 25% more productive while being 19% slower on end-to-end tasks. The Stack Overflow Developer Survey 2025 (n=49,000+) found that 66% of developers are spending more time fixing “almost-right” AI code. Forrester projects that 75% of technology decision-makers will face technical debt at a severe level by 2026.

The pattern is consistent: AI generates volume. Debt accumulates invisibly. By the time it’s visible, it’s compound and structural.

The CCGS version of this is the deferred items register. CCGS ships with a tech-debt tracking mechanism, but it has no cap on that register by default. As a 49-agent studio produces across multiple sprints, the register grows. Agents read it to understand project context. The larger it grows, the more tokens every read operation consumes, and the more likely agents are to work from an incomplete picture of the project’s actual state. Issue #64 documents what happens when architecture decision records exceed 25k tokens: the Read tool triggers offset-and-limit retries, doubling the token cost of a single read operation. The defect propagates downstream before anyone names it.

The IBM Institute for Business Value 2025 study put numbers on the consequence: teams that ignored technical debt saw project returns drop 18-29% and timelines expand by as much as 22%. That is the cost of not stopping.

The four steps

The Toyota Production System has a principle for exactly this situation. Jidoka, sometimes translated as “automation with a human touch,” is the right to stop the line. When a worker detects a defect or an abnormality in output quality, they stop the production line immediately. Not at the end of the sprint. Not at the next retrospective. Immediately. Then: fix the immediate condition, investigate the root cause, and install a countermeasure to prevent recurrence.

The principle originated in Sakichi Toyoda’s automatic loom, which was designed to stop the moment a thread broke rather than continuing to produce defective cloth. The insight was that defects cost less to fix at the point of production than after they have been woven into the fabric of the finished product. Stopping the line always feels expensive. Continuing with known defects is always more expensive.

elysi followed these four steps without knowing they were following them.

Detect. “Agents were arguing, tech-debt kept creeping, it wasn’t iterating.” That is the signal. Not frustration, not a hunch. A specific observation about system behaviour. Output volume was maintained while output quality declined. That gap is the defect.

Stop. elysi told Claude the run was not working and initiated the restart decision. This is the move most users don’t make. The sunk cost of 19 days, the token spend, the design documents and sprint artefacts: all of it creates pressure to keep prompting. elysi discarded that pressure and pulled the cord.

Fix. Rather than scrapping the entire run, elysi had Opus write a migration script. Not to preserve everything, but to extract what had worked and move it to a clean folder. A migration is not a copy. It is a curation decision: what from this system is worth carrying forward, and what should stay behind?

Prevent recurrence. This is the part that separates a restart from a reset. elysi trimmed CCGS to 49% of its original size. They imposed a 50-item cap on the deferred items register, with a standing rule to run a mid-sprint polish pass when the count reached 40. They wrote 15 bash helper scripts to manage context consumption, including partial-read-helper.sh, which prevented the framework from loading 40k tokens of context before any actual work began. They built a 1,081-test suite running via Godot Unit Testing at every subsequent code iteration.

“I got Opus to write a migration script to a new folder, copy what worked, and trimmed CCGS down to 49% of the repository. We have a written memory, no more than 50 open deferred items, and when we get to 40 we do a mid-sprint story to polish and fix.” — elysi, GitHub Issue #46

None of that came from the repository.

The constraint is the product

I’ve run into the same pattern from a different direction. Early in a complex UI project, the instinct is to solve the whole thing at once: one Miro board, one comprehensive design, everything visible and connected. It feels like progress. What it actually produces is a tangle of assumptions, interdependencies, and hidden constraints that only become visible when you try to build from the design.

Breaking it down changes the result. Personas first. Low-fidelity wireframes. Black and white mockups before any colour decisions. UX flow charts before any visual treatment. Each stage is a constraint: a deliberate reduction of scope that forces the work to surface what it actually requires. The hidden constraints don’t disappear. They appear early, where they are cheap to address, rather than late, where they are expensive.

The constraint is the instrument that makes the actual shape of the work visible.

elysi’s 50-item tech-debt cap works the same way. The number is somewhat arbitrary; 49 or 51 would also function. But the cap forces a reckoning. When the register hits 40, the team stops and resolves debt before adding more. The constraint makes the accumulation visible at a point where it is still manageable. Without the cap, the register grows until it is structural: until the defects are baked into the architecture and addressing them costs a restart.

The partial-read-helper.sh script is a constraint of a different kind. It prevents the framework from performing full-context reads when partial reads would serve the same purpose at a fraction of the token cost. The script does not change what CCGS can do. It changes how much of the budget gets spent on infrastructure overhead before any production work begins. elysi open-sourced it in Issue #46 because other users were burning 30-40% of their weekly token quota on context reads before the first line of game code was produced.

“I trimmed CCGS down to 49% of the repository. No more than 50 open deferred items, and when we get to 40 we do a mid-sprint story to polish and fix.” — elysi, GitHub Issue #46

The LinearB research identifies the top 20% of AI-assisted teams, the ones that avoid the technical debt crisis. They share three practices: tracking AI-generated code separately with specialised quality gates, measuring quality alongside output speed rather than treating them as a trade-off, and enforcing governance standards that catch AI’s predictable failure modes before they merge. These are production decisions, made in response to specific failure modes encountered on a specific project. They cannot be packaged. They have to be earned.

What frameworks can and can’t ship

McKinsey’s 2026 data finds that 62% of organisations experiment with AI agents while fewer than 25% scale to production. Gartner projects that by end of 2027, more than 40% of agentic AI projects will be put on hold, citing unclear business value and insufficient risk controls. The common thread is frameworks being used as shipped, without the constraint layer that makes production at scale viable.

CCGS at full capacity (49 agents, 73 skills, 41 templates, 12 hooks) is a starting position. It is well-engineered and thoughtfully structured for a broad range of users across Godot, Unity, and Unreal, across novice and experienced developers, across casual prototypes and serious production runs. A generic framework cannot anticipate the specific failure modes of a specific project. It can only give you the surface to work from.

Subscribe now

What elysi built (the trimmed hierarchy, the bash tooling, the test suite, the capped register) is the production system. It is specific to their project, their failure modes, their context budget, their engine, their codebase. It emerged from 19 days of running the official framework until the official framework broke. The restart was the method. The constraint set that came out of the restart is the product.

You can download CCGS in seconds. You can’t download the 19 days that taught elysi what to cut.

• 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.

• A ten-person standup that runs fifteen minutes costs two and a half hours of aggregate team time, every day.

• Any information that can travel in writing should travel in writing. What remains is a much shorter meeting list.

• No agenda means no meeting: a useful agenda is a list of questions needing answers, not topics to discuss.

• Lean Coffee is a structured format for discussions where the agenda itself is uncertain, and it works.

This is part of the Production 101 series.

A ten-person standup that runs fifteen minutes costs two and a half hours of aggregate team time. Every day. Run five days a week, that’s twelve and a half person-hours a week spent on a meeting whose entire purpose is to share information that, on a sufficiently mature team, travels faster in writing. Most producers inherit the standup cadence from whoever set up the project before them and never question it. That’s a reasonable description of how most meeting cultures form: through inheritance and inertia, with no one deciding.

Subscribe now

I’ve done this. Early in my career I ran standups daily because that’s what you did. I ran them because the Scrum Guide said so, because the previous producer had run them, because stopping felt like admitting you didn’t care about communication. None of those are reasons. They’re habits dressed up as reasoning.

The cost calculation no one does

Standups are the most expensive meeting format in your weekly schedule, measured by aggregate cost. The formula is simple: headcount multiplied by duration multiplied by frequency. On a twenty-person team, a fifteen-minute daily standup is twenty-five person-hours a week. That’s more than half a person-week, every week, before the iteration planning, the milestone reviews, the one-on-ones, and the assorted other gatherings have been counted.

The uncomfortable question that formula raises is: what is that time buying you? On a team that is new to each other, building complicated dependencies, or working through something genuinely uncertain, a daily standup is probably worth the cost. Blockers surface fast. People know what others are doing. The meeting pays for itself. On a team that has worked together for two years, that documents properly and communicates well asynchronously, that same standup is often a recital of things everyone already knows, punctuated by the occasional “no blockers for me.”

Team maturity should determine standup frequency, not process habit. The team that needs daily synchronisation is the team that doesn’t yet have the discipline or the tooling to communicate without it. As that discipline develops, the frequency should come down. Three times a week. Twice. Once. The standup that stays daily indefinitely isn’t a sign of good communication. It’s a sign that nobody reviewed whether it was still needed.

The standup that stays daily indefinitely isn’t a sign of good communication. It’s a sign that nobody reviewed whether it was still needed.

The producers I’ve seen who never audit this tend to have the same explanation when you ask them: “the team likes the standup.” Sometimes that’s true. More often, the team has simply adapted to the standup the way you adapt to any recurring overhead. It’s just part of the day. If you removed it, you’d find out whether they actually wanted it or just got used to it. Run that experiment.

Async first

The principle is simple: any information that can travel in writing, should. The meetings that survive this filter are considerably fewer than the ones you currently have.

Status updates belong in writing. Progress reporting belongs in writing. Non-urgent questions belong in writing. Decisions with clear owners and well-understood options belong in writing. If you’ve read Production 101 #9 on status reports, you have the format for the written version. A well-maintained status report eliminates a significant portion of your recurring meeting load, because the meetings those reports replace were mostly people asking each other what was happening.

I’ve worked at studios where the weekly status report went out on Friday afternoon, and by the time Monday’s first conversation started, the project’s state was already documented and shared. People came in with context rather than questions. The synchronous time that followed was for work that actually needed live presence, not for getting everyone up to speed.

What actually requires real-time presence? Decisions that need live debate, where the outcome depends on people building on each other’s thinking in real time. Situations that need emotional attunement, where the written word is inadequate to the stakes of what’s being discussed. Problems that would take three long message threads to resolve and ten minutes in person. That’s not nothing. Those meetings matter enormously. But it’s a short list compared to the default.

The async-first producer doesn’t eliminate meetings. They eliminate the meetings that exist because nobody asked whether they needed to exist.

The agenda as the gate

I’ve operated a simple policy for years: no agenda, no meeting. Not as a preference. As a rule.

This does two things. First, it forces the person calling the meeting to be clear about what the meeting is for before anyone agrees to attend. Second, it makes it possible for attendees to prepare, which changes the quality of the conversation in the room.

A useful agenda is a list of questions that need answers. Not a list of topics to discuss. The distinction matters more than it sounds. “Art direction” is a topic. “Do we maintain the current visual reference or shift toward the concept work Yuki produced last week?” is a question. A topic can run indefinitely without resolution. A question has an answer, which means the meeting ends when you have it.

A useful agenda is a list of questions that need answers. Not a list of topics to discuss. Topics can run indefinitely without resolution.

Who owns the agenda? The person calling the meeting. When does it go out? At least twenty-four hours before the meeting, not five minutes before. The agenda that arrives the morning of tells attendees they’re expected to perform thinking they haven’t had time to do. The agenda that arrives a day before gives people the chance to come in with a position, which is what you need when you want a decision, not a discussion.

The producer’s job here extends to meetings they don’t run. If a meeting lands in your calendar with no agenda, you ask for one. Not aggressively, not as an accusation. You ask because you need to prepare. “What are the questions we’re trying to answer?” is a reasonable thing to ask of anyone who wants an hour of your team’s time.

Enforcing agenda discipline consistently trains the people around you over time. They stop scheduling vague meetings because they’ve learned you’ll ask what the questions are. That’s not a small thing. It changes the meeting culture of the whole team, one agenda request at a time.

Lean Coffee

Not every meeting has a clear agenda before it starts. Sometimes the question is “what do we need to talk about?” and you have a room full of people with different answers. The default response to this situation is an open discussion that runs long and ends inconclusively. There’s a better format.

Lean Coffee was created by Jim Benson and Jeremy Lightsmith in Seattle in 2009. It’s a structured format for discussions where the agenda itself is uncertain, and it’s one of the more practically useful things I’ve adopted across a long production career.

Here’s how it works. At the start of the session, each participant writes their discussion topics on individual cards or sticky notes, one topic per card. Once everyone has written theirs, you spend a few minutes dot-voting: each person gets a small number of votes (typically three) and places them on the topics they most want to discuss. The cards are ranked by votes and become the agenda.

You then work through the ranked topics in timeboxed segments, typically five to eight minutes each. At the end of each timebox, you take a quick vote: thumbs up to continue discussing this topic, thumbs sideways to wrap it up quickly, thumbs down to move on to the next one. Majority decides. The discussion continues until the time runs out or the topic list is exhausted.

What you get is a conversation shaped by the team’s actual priorities rather than whoever called the meeting. The loudest person in the room doesn’t determine the agenda. The person most senior in the hierarchy doesn’t determine it. The collective does, anonymously, by voting. That’s a meaningful difference.

I’ve used it most regularly in weekly team meetings. The prior week’s board acts as a shared record, so people arrive with topics already in mind. What the format changes is whose topics get discussed: the voting step means the person with the most to say doesn’t control what the group spends its time on. The collective need surfaces, rather than the need of whoever has the loudest voice in the room.

When should you reach for it? Any time you’re looking at a long and open-ended discussion that has historically run over time and ended without clear decisions. Any time you’re facilitating a group whose priorities you’re not certain about. Early-project alignment. Team health check-ins. Priority debates where multiple stakeholders have different views. The format doesn’t resolve disagreements, but it makes sure the important ones get airtime.

Facilitation as a distinct skill

There’s a version of running a meeting where the producer is a participant, like everyone else in the room, contributing opinions and building positions alongside the rest of the team. That’s sometimes the right mode. For most production meetings, it’s not.

The producer as facilitator is a different job. You’re the host. You hold the agenda’s questions and bring the group back to them when the conversation drifts. You manage time. You notice when a discussion has reached a decision but nobody has said the decision out loud, and you say it. You close the meeting with explicit decisions and named owners, not a general sense that something was discussed.

The specific skill that takes practice is managing the person who wants to workshop everything out loud. Every team has at least one: someone for whom thinking is a social activity, who processes by talking, and who will run a twenty-minute tangent if you let them. You’re not trying to shut them down. You’re redirecting. “That’s worth exploring. Let’s put it in the parking lot and come back to it if we have time.” The parking lot is real: write it down visibly, and either return to it at the end or make sure it gets a home elsewhere. The redirection only works if people trust you’ll follow through.

The producer as facilitator closes the meeting with explicit decisions and named owners, not a general sense that something was discussed.

The meeting that ended and the meeting that concluded are different things. A meeting ends when the time runs out or everyone leaves the room. A meeting concludes when every agenda question has an answer, every decision has an owner, and the next action is clear. Most meetings end. Fewer conclude. The producer’s job is to make sure they conclude.

The audit

If you’ve never done a full audit of your recurring meeting schedule, the exercise is uncomfortable and worth doing.

Go through every recurring meeting on your calendar. For each one, ask two questions. What decision does this produce? Who couldn’t get that information another way? The meetings that survive both questions are probably earning their place. The ones that don’t are candidates for conversion or elimination.

The meetings that typically survive: milestone reviews, where multiple stakeholders need to collectively assess whether delivery targets are still on track. Decisions requiring input from people who don’t have a shared written channel. Any situation requiring the kind of attunement you can only achieve in real-time conversation.

The meetings that typically don’t survive: status updates that could be a written report, which Production 101 #9 covers in detail. Recurring syncs where the conversation loops without producing decisions. Check-ins that exist because someone is anxious about visibility and prefers a meeting to a document. That last one is worth being honest about. If a meeting exists to manage someone’s anxiety rather than to produce information, the meeting is the wrong solution to that problem.

When a meeting fails the audit, converting it is usually straightforward. Status syncs become status reports. Recurring information-sharing meetings become a standing document that people comment on asynchronously. Meetings that existed for visibility become a dashboard or a brief weekly write-up. Some meetings simply stop, and nobody misses them, which tells you something about why they existed.

The producers I know who have done this exercise report the same finding: they typically recover two to four hours of team time per person per week. Not from eliminating meetings that felt important, but from eliminating meetings that nobody would have defended if asked to defend them directly. The audit asks the question. The meeting cadence never does.

None of this is a case for eliminating synchronous communication. Some things need a room. The judgment required is knowing which things those are, and having the production discipline to reserve the room for them. A well-facilitated milestone review is worth every minute it costs. A status standup on a team that already writes things down is a cost with no return.

Leave a comment

The meeting culture on your project is a product of decisions, whether you made those decisions consciously or not. Most producers inherit it. The good ones eventually look at what they inherited and ask: does this reflect what this team actually needs, or is this what someone else needed I’ve done this. Early in my career I ran standups daily because that’s what you did. I ran them because the Scrum Guide said so, because the previous producer had run them, because stopping felt like admitting you didn’t care about communication. None of those are reasons. They’re habits dressed up as reasoning.

The cost calculation no one does

Standups are the most expensive meeting format in your weekly schedule, measured by aggregate cost. The formula is simple: headcount multiplied by duration multiplied by frequency. On a twenty-person team, a fifteen-minute daily standup is twenty-five person-hours a week. That’s more than half a person-week, every week, before the iteration planning, the milestone reviews, the one-on-ones, and the assorted other gatherings have been counted.

The uncomfortable question that formula raises is: what is that time buying you? On a team that is new to each other, building complicated dependencies, or working through something genuinely uncertain, a daily standup is probably worth the cost. Blockers surface fast. People know what others are doing. The meeting pays for itself. On a team that has worked together for two years, that documents properly and communicates well asynchronously, that same standup is often a recital of things everyone already knows, punctuated by the occasional “no blockers for me.”

Team maturity should determine standup frequency, not process habit. The team that needs daily synchronisation is the team that doesn’t yet have the discipline or the tooling to communicate without it. As that discipline develops, the frequency should come down. Three times a week. Twice. Once. The standup that stays daily indefinitely isn’t a sign of good communication. It’s a sign that nobody reviewed whether it was still needed.

The standup that stays daily indefinitely isn’t a sign of good communication. It’s a sign that nobody reviewed whether it was still needed.

The producers I’ve seen who never audit this tend to have the same explanation when you ask them: “the team likes the standup.” Sometimes that’s true. More often, the team has simply adapted to the standup the way you adapt to any recurring overhead. It’s just part of the day. If you removed it, you’d find out whether they actually wanted it or just got used to it. Run that experiment.

Async first

The principle is simple: any information that can travel in writing, should. The meetings that survive this filter are considerably fewer than the ones you currently have.

Status updates belong in writing. Progress reporting belongs in writing. Non-urgent questions belong in writing. Decisions with clear owners and well-understood options belong in writing. If you’ve read Production 101 #9 on status reports, you have the format for the written version. A well-maintained status report eliminates a significant portion of your recurring meeting load, because the meetings those reports replace were mostly people asking each other what was happening.

I’ve worked at studios where the weekly status report went out on Friday afternoon, and by the time Monday’s first conversation started, the project’s state was already documented and shared. People came in with context rather than questions. The synchronous time that followed was for work that actually needed live presence, not for getting everyone up to speed.

What actually requires real-time presence? Decisions that need live debate, where the outcome depends on people building on each other’s thinking in real time. Situations that need emotional attunement, where the written word is inadequate to the stakes of what’s being discussed. Problems that would take three long message threads to resolve and ten minutes in person. That’s not nothing. Those meetings matter enormously. But it’s a short list compared to the default.

The async-first producer doesn’t eliminate meetings. They eliminate the meetings that exist because nobody asked whether they needed to exist.

The agenda as the gate

I’ve operated a simple policy for years: no agenda, no meeting. Not as a preference. As a rule.

This does two things. First, it forces the person calling the meeting to be clear about what the meeting is for before anyone agrees to attend. Second, it makes it possible for attendees to prepare, which changes the quality of the conversation in the room.

A useful agenda is a list of questions that need answers. Not a list of topics to discuss. The distinction matters more than it sounds. “Art direction” is a topic. “Do we maintain the current visual reference or shift toward the concept work Yuki produced last week?” is a question. A topic can run indefinitely without resolution. A question has an answer, which means the meeting ends when you have it.

A useful agenda is a list of questions that need answers. Not a list of topics to discuss. Topics can run indefinitely without resolution.

Who owns the agenda? The person calling the meeting. When does it go out? At least twenty-four hours before the meeting, not five minutes before. The agenda that arrives the morning of tells attendees they’re expected to perform thinking they haven’t had time to do. The agenda that arrives a day before gives people the chance to come in with a position, which is what you need when you want a decision, not a discussion.

The producer’s job here extends to meetings they don’t run. If a meeting lands in your calendar with no agenda, you ask for one. Not aggressively, not as an accusation. You ask because you need to prepare. “What are the questions we’re trying to answer?” is a reasonable thing to ask of anyone who wants an hour of your team’s time.

Enforcing agenda discipline consistently trains the people around you over time. They stop scheduling vague meetings because they’ve learned you’ll ask what the questions are. That’s not a small thing. It changes the meeting culture of the whole team, one agenda request at a time.

Lean Coffee

Not every meeting has a clear agenda before it starts. Sometimes the question is “what do we need to talk about?” and you have a room full of people with different answers. The default response to this situation is an open discussion that runs long and ends inconclusively. There’s a better format.

Lean Coffee was created by Jim Benson and Jeremy Lightsmith in Seattle in 2009. It’s a structured format for discussions where the agenda itself is uncertain, and it’s one of the more practically useful things I’ve adopted across a long production career.

Here’s how it works. At the start of the session, each participant writes their discussion topics on individual cards or sticky notes, one topic per card. Once everyone has written theirs, you spend a few minutes dot-voting: each person gets a small number of votes (typically three) and places them on the topics they most want to discuss. The cards are ranked by votes and become the agenda.

You then work through the ranked topics in timeboxed segments, typically five to eight minutes each. At the end of each timebox, you take a quick vote: thumbs up to continue discussing this topic, thumbs sideways to wrap it up quickly, thumbs down to move on to the next one. Majority decides. The discussion continues until the time runs out or the topic list is exhausted.

What you get is a conversation shaped by the team’s actual priorities rather than whoever called the meeting. The loudest person in the room doesn’t determine the agenda. The person most senior in the hierarchy doesn’t determine it. The collective does, anonymously, by voting. That’s a meaningful difference.

I’ve used it most regularly in weekly team meetings. The prior week’s board acts as a shared record, so people arrive with topics already in mind. What the format changes is whose topics get discussed: the voting step means the person with the most to say doesn’t control what the group spends its time on. The collective need surfaces, rather than the need of whoever has the loudest voice in the room.

When should you reach for it? Any time you’re looking at a long and open-ended discussion that has historically run over time and ended without clear decisions. Any time you’re facilitating a group whose priorities you’re not certain about. Early-project alignment. Team health check-ins. Priority debates where multiple stakeholders have different views. The format doesn’t resolve disagreements, but it makes sure the important ones get airtime.

Facilitation as a distinct skill

There’s a version of running a meeting where the producer is a participant, like everyone else in the room, contributing opinions and building positions alongside the rest of the team. That’s sometimes the right mode. For most production meetings, it’s not.

The producer as facilitator is a different job. You’re the host. You hold the agenda’s questions and bring the group back to them when the conversation drifts. You manage time. You notice when a discussion has reached a decision but nobody has said the decision out loud, and you say it. You close the meeting with explicit decisions and named owners, not a general sense that something was discussed.

The specific skill that takes practice is managing the person who wants to workshop everything out loud. Every team has at least one: someone for whom thinking is a social activity, who processes by talking, and who will run a twenty-minute tangent if you let them. You’re not trying to shut them down. You’re redirecting. “That’s worth exploring. Let’s put it in the parking lot and come back to it if we have time.” The parking lot is real: write it down visibly, and either return to it at the end or make sure it gets a home elsewhere. The redirection only works if people trust you’ll follow through.

The producer as facilitator closes the meeting with explicit decisions and named owners, not a general sense that something was discussed.

The meeting that ended and the meeting that concluded are different things. A meeting ends when the time runs out or everyone leaves the room. A meeting concludes when every agenda question has an answer, every decision has an owner, and the next action is clear. Most meetings end. Fewer conclude. The producer’s job is to make sure they conclude.

The audit

If you’ve never done a full audit of your recurring meeting schedule, the exercise is uncomfortable and worth doing.

Go through every recurring meeting on your calendar. For each one, ask two questions. What decision does this produce? Who couldn’t get that information another way? The meetings that survive both questions are probably earning their place. The ones that don’t are candidates for conversion or elimination.

The meetings that typically survive: milestone reviews, where multiple stakeholders need to collectively assess whether delivery targets are still on track. Decisions requiring input from people who don’t have a shared written channel. Any situation requiring the kind of attunement you can only achieve in real-time conversation.

The meetings that typically don’t survive: status updates that could be a written report, which Production 101 #9 covers in detail. Recurring syncs where the conversation loops without producing decisions. Check-ins that exist because someone is anxious about visibility and prefers a meeting to a document. That last one is worth being honest about. If a meeting exists to manage someone’s anxiety rather than to produce information, the meeting is the wrong solution to that problem.

When a meeting fails the audit, converting it is usually straightforward. Status syncs become status reports. Recurring information-sharing meetings become a standing document that people comment on asynchronously. Meetings that existed for visibility become a dashboard or a brief weekly write-up. Some meetings simply stop, and nobody misses them, which tells you something about why they existed.

The producers I know who have done this exercise report the same finding: they typically recover two to four hours of team time per person per week. Not from eliminating meetings that felt important, but from eliminating meetings that nobody would have defended if asked to defend them directly. The audit asks the question. The meeting cadence never does.

None of this is a case for eliminating synchronous communication. Some things need a room. The judgment required is knowing which things those are, and having the production discipline to reserve the room for them. A well-facilitated milestone review is worth every minute it costs. A status standup on a team that already writes things down is a cost with no return.

The meeting culture on your project is a product of decisions, whether you made those decisions consciously or not. Most producers inherit it. The good ones eventually look at what they inherited and ask: does this reflect what this team actually needs, or is this what someone else needed before us? The answer, usually, is both. And the job is to keep the first kind and stop running the second.

For how Scrum ceremonies fit into sprint-based production specifically, Post #12 - Agile for Game Producers covers the full framework and where standups belong within it.

• Pre-production is where most games are won or lost, and where producers are most likely to be absent or ineffective.

• The producer’s job in pre-production is less about scheduling and more about tracking dependencies, asking hard questions, and recording decisions.

• Prototype choices commit technology paths. Producers need to know which questions a prototype actually answers.

• Entering full production with unresolved design ambiguity means resolving it in the middle of an iteration, which is the most expensive place to do it.

This is part of the Production 101 series.

Pre-production is where most games are won or lost. It’s also where producers are most likely to be absent, or present but ineffective, because the work is less legible than a task board. There’s no backlog to point at, no velocity to track, no milestone build to review. There’s just a set of questions the team needs to answer before real production starts, and a limited window in which to answer them properly.

Subscribe now

The challenge is that pre-production looks, from the outside, like not much is happening. The team is small. There are no builds shipping. The design is still in flux. A producer who measures their own value by the number of things moving through a pipeline will find pre-production uncomfortable. That discomfort is worth examining, because pre-production is where the decisions that govern everything else get made.

What pre-production is for

Pre-production exists to reduce uncertainty before commitments become expensive. The cost of a decision during pre-production is a conversation. The cost of the same decision in full production is weeks of rework, a reschedule, and a stakeholder conversation nobody wanted to have.

The cost of a decision in pre-production is a conversation. The cost of the same decision in full production is weeks of rework and a stakeholder conversation nobody wanted to have.

The questions that should be answered before production begins: what are we building, for whom, on which platforms, with what technology, with what team? Production can start before all of these are answered. It shouldn’t. Every unresolved question that enters full production is a decision that will be made reactively, under pressure, by whoever happens to be in the room when the problem becomes unavoidable.

The argument is for knowing which questions are genuinely open, owning them explicitly, and making sure the people with the authority to answer them are in the conversation before the schedule is committed.

[INTERNAL LINK: Post #13 — How to Build a Milestone Schedule]

Discovery and the producer’s role

The producer doesn’t write the game design document. But they’re responsible for the process that produces it.

That means identifying the dependencies that creative work creates as it develops. A design decision about progression systems has implications for data infrastructure, for the analytics pipeline, for localisation. A decision about open-world exploration has implications for content volume, for streaming architecture, for team size at peak production. The producer’s job during discovery is to keep the design grounded in what the team can actually build, while the design is still cheap to change.

[INTERNAL LINK: Post #12 — Agile for Game Producers]

The GDD question is worth addressing directly. In a traditional waterfall model, the GDD gets written in pre-production and then production executes against it. In Agile development, the GDD is often a living document, updated as the team learns. Neither approach eliminates the need for pre-production. Both require that certain foundational decisions be made before full production starts: what the game is, what the core loop is, what platforms it targets, what the technology stack is. The format of the design document matters less than whether those decisions exist and are recorded somewhere the full team can find them.

The other thing the producer does in discovery is make sure the decisions being made get written down. Discovery is full of conversations. A lot of those conversations produce real decisions. Those decisions get made once, in a room with the right people, and then never formally recorded. Six months later, when someone asks why the game has a particular feature or why a technical choice was made, nobody remembers the reasoning. The producer who’s present in discovery and keeps a record of those decisions is protecting the whole project from itself.

The most valuable habit I’ve developed in pre-production is running two documents in parallel: a decision log and an open questions list. The decision log records what was decided, when, who made the call, and the reasoning. The open questions list tracks unresolved questions by date, with a note on which decisions are being made against an assumed answer because the real answer isn’t available yet. Pre-production is full of those assumed answers. Recording them means that when the question eventually gets resolved, you can trace back to every decision that was built on the assumption and check whether it still holds.

Prototype decisions and what they commit to

A prototype answers questions. It also creates path dependencies that are expensive to undo later.

Technology choices made during prototyping have a way of becoming permanent. The engine integration that worked well enough to get the prototype running becomes the engine integration that the full team builds on. The rendering approach that made the demo look good becomes the rendering approach that the engine team has to support for the next three years. The producer’s job is to know which questions a prototype is actually answering, and which questions it’s accidentally foreclosing.

A prototype that proves the core loop works is valuable. A prototype that proves the core loop works while accidentally locking in an architecture decision nobody reviewed is a different kind of thing.

The questions worth asking before a prototype starts: what are we trying to learn from this? What decisions will we make based on the result? Are there assumptions baked into the prototype approach that we’re treating as settled when they aren’t? A team that can answer those questions cleanly before prototyping is likely to build a prototype that gives them genuinely useful information. A team that goes straight to building will get useful information and a lot of path dependencies, and won’t always be able to tell which is which.

The producer doesn’t need to understand the technical details of every architecture decision. They need to understand which decisions are being made, when, and whether anyone with commercial or scheduling authority has been included in the conversation.

Technical pre-production

Engine licence, platform decisions, pipeline setup, middleware selection. These all land on the producer’s list before a single feature is built.

They’re unsexy and easy to defer. A team that’s excited to start making the game wants to start making the game. Nobody is excited about reading licence agreements or evaluating middleware vendors. But these are also the decisions that create the most expensive problems when they’re wrong. An engine licence that turns out to be incompatible with your target platform. A middleware solution that works fine until you need to ship on a console and then suddenly doesn’t. A build pipeline that nobody set up properly in pre-production, so the first two months of full production are spent fighting the tools instead of building the game.

A producer who isn’t involved in technical pre-production will be managing the consequences of decisions made by engineers in isolation from commercial and scheduling reality. Technical decisions made without someone in the room whose job is to connect them to the project’s constraints tend to be technically sound and commercially blind.

The most expensive technical pre-production mistake I’ve seen, more than once, is deferred platform certification research. A team builds a game assuming a platform will behave a certain way, because that’s how it behaved two years ago, or because that’s how a similar platform works. Then the cert submission happens and something fundamental is wrong. Platform requirements change. They’re not always published clearly. Finding this out during production is recoverable. Finding it out during cert is a different kind of problem entirely.

Team structure and capacity planning

When to hire, when to use contractors, what disciplines are needed in what phase. These decisions are made in pre-production and lived with for the rest of the project.

Getting the discipline mix wrong in pre-production creates one of two problems. Hire too early and you have a team spending project money before there’s anything for them to build. The design is still in flux, the technology is still being decided, and a team of forty has nowhere productive to direct its energy. That’s expensive in cash and in morale.

Hire too late and you have a bottleneck you can’t resource your way out of. The production phase starts, scope is committed, the schedule is locked, and you’re three months from your first external milestone with half a team. You can hire into that situation. You can’t get time back.

The producer’s job in pre-production is to translate the project plan into a staffing model: what disciplines are needed, at what capacity, and when. That model then gets presented to whoever controls hiring and budget, clearly enough that they can make an informed decision. The staffing model is connected to the schedule [INTERNAL LINK: Post #13 — How to Build a Milestone Schedule], so when the schedule changes, the staffing model changes. They shouldn’t be maintained as separate documents that drift apart.

The contractor question deserves specific attention. Contractors are useful for filling short-term capacity gaps, for specialist skills the team doesn’t need full-time, and for scaling up during crunch periods with defined endpoints. They’re less useful as a strategy for avoiding permanent headcount decisions you should be making. If a discipline is needed for the life of the project, that’s a permanent hire. Using contractors as a substitute for permanent hires when you need permanent hires adds overhead, creates knowledge transfer problems, and generally costs more than making the hire directly.

When pre-production is over

The signals that mean the team is ready to commit to full production are: the core design is validated, the technology is proven, the team is in place, and the first milestone is defined with clear acceptance criteria.

Those criteria sound simple. They aren’t. “The core design is validated” means someone has built something that demonstrates the core loop works, that target players have responded to it in the ways the design intended, and that the team agrees the thing they’ve built is what they’re going to keep building. The design has enough of a foundation that production can build on it without the foundation changing. That’s the bar. The design document can still be incomplete.

“The technology is proven” means the key technical risks have been resolved in favour of something the team knows how to build and ship. Not all risks. The key ones. The ones that, if they went wrong, would invalidate the production plan.

The mistake is calling pre-production over because the calendar says it should be. Pre-production phases get compressed under schedule pressure constantly. A publisher wants to see production momentum. A studio head is watching headcount sitting in pre-production mode and wants them building features. An investor wants to see a vertical slice. All of these are real pressures and all of them can produce the same outcome: a team that enters full production with unresolved design ambiguity, because the pre-production phase was declared finished before the work was actually done.

A team that enters full production with unresolved design ambiguity will resolve that ambiguity in the middle of an iteration. That’s the most expensive place to do it.

A producer who knows the project is not ready for full production has an obligation to say so, clearly, with specifics. The specific questions that are unresolved. The specific risks that are unmitigated. The specific criteria that haven’t been met. That conversation is uncomfortable. It is substantially less uncomfortable than explaining, six months later, why full production is running two months behind schedule because the team spent the first quarter resolving design questions that should have been answered in pre-production.

Leave a comment

Pre-production done well produces four concrete things: a prototype that validates the core loop, a team capable of building the full game, a milestone structure agreed by both the team and the publisher, and a conscious decision to enter production. That last part matters more than it sounds. The alternative is sliding into full production without anyone explicitly confirming the conditions have been met, and that slide is common enough that most studios have at least one post-mortem that traces the root cause back to it.

• Most studios call their testers “QA” but run QC, and understanding the difference changes how you use the function.

• Involving QA leadership before development starts is more effective than involving them after the build arrives.

• Bug density, reopened bugs, and first-pass pass rates are signals about your project, not just your test coverage.

• QA leadership often has better real-time visibility into project health than anyone else on the team.

This is part of the Production 101 series.

QA finds bugs. Everyone knows that. What most producers don’t know is that QA also tells you the truth about your game at the point when everyone else has developed an interest in the answer being favourable. An honest QA report, read correctly, is one of the most useful documents on a project.

Subscribe now

QA vs. QC: the distinction that matters

These two terms get used interchangeably in almost every studio I’ve worked in, and the confusion causes real problems. So: QC is Quality Control. It’s the act of finding defects. A tester runs a build, finds bugs, files them. That’s QC. It’s valuable, it’s necessary, and it’s what most game studios are actually running when they say they have QA.

QA is Quality Assurance. It’s the broader discipline of building processes that prevent defects from reaching the build in the first place. That means reviewing requirements before development starts. It means writing acceptance criteria so the team agrees on what “done” looks like before anyone writes a line of code. It means defining test plans early, participating in iteration planning, flagging ambiguity in design documents when there’s still time to address it without cost. The invisible work in QA is what makes the visible work of QC easier.

The distinction matters because the timing is completely different. QC finds problems late, after they’ve been built. QA prevents some of them by catching the conditions that produce them before they’re built. Both happen in a well-run studio. Many studios have only QC and call it QA, which means they’re discovering late what they could have prevented early.

If you only have QC, you’re finding problems when they’re expensive. If you have QA, you’re preventing some of them when they’re cheap.

There’s a management habit that makes this worse: treating QA as a downstream service. Development builds something, then throws it over the wall to QA for testing. That model produces exactly what you’d expect from it. The QA team gets builds they haven’t seen specifications for, against requirements they weren’t part of writing, and they find the same kinds of problems at the same stage of every project. The producer wonders why testing always takes longer than planned. It takes longer because the process was designed to find problems late.

The studios I’ve seen run this well treat QA as a discipline that spans the full development cycle, with dedicated headcount that has time for both QC work in the build and the upstream process work that prevents some of it. That combination isn’t free. It requires the producer to protect QA’s time for non-testing work, which is harder to justify when there’s always a build that needs testing.

Shifting left

“Shift left” has become one of those phrases that gets repeated in planning meetings without anyone doing the thing it describes. So let me be specific about what it actually means and why it works.

Shifting left means moving testing activity earlier on the project timeline, closer to when decisions are made. A QA engineer involved in iteration planning reviews the acceptance criteria for the iteration’s work before development starts. They ask the question: how will we know this is done, and done correctly? That question, asked before development, exposes ambiguity that would otherwise surface as a bug after development. The design decision that seemed clear to the developer and the designer doesn’t look the same from the QA perspective, and that gap is exactly where defects live.

The practical implication for a producer is this: QA leadership should be in iteration planning. They should be reviewing acceptance criteria before the iteration begins. They should have a seat at the table when requirements are written, not a folder of requirements handed to them after the fact.

This is a specific operational choice that costs something. QA engineers in planning meetings are not testing the current build during that time. The payoff is a build with fewer ambiguity-driven defects in it, which means QC work goes faster, which more than covers the time spent. In my experience, the studios that resist this do so because they’re measuring QA by test execution metrics and those metrics look worse when testers are in planning meetings rather than executing test cases. The wrong measurement produces the wrong behaviour.

I’ve pushed for QA involvement at planning on several projects where the resistance was real. The most common objection is “QA is already stretched.” That’s usually true. And it’s usually true because QC is running at full capacity catching problems that earlier involvement would have prevented. Breaking that cycle requires trusting the investment before you can measure the return.

QA as a production signal

The data QA generates is a map of where your project’s risks are materialising. Most producers read bug reports as a testing problem. I read them as a production signal.

Bug density by area tells you where the team is struggling. If QA is consistently finding more bugs in one system, in one level, in one feature area, that’s telling you something about that part of the codebase or design. It might be that the area is technically complex. It might be that the requirements were unclear. It might be that a specific developer is under pressure and cutting corners, or that a handoff between two teams isn’t working. The bugs are the symptom. Your job is to read the pattern.

Reopened bugs tell you where estimation went wrong or where fixes were rushed. When a bug gets fixed, verified, and then reopens because the fix introduced a new problem, you’re looking at one of two things: the fix was incomplete because the developer didn’t understand the root cause, or the fix was done too quickly because the schedule didn’t leave time to do it properly. Either is worth understanding.

First-pass pass rates tell you about build quality. If your QA team consistently finds that a high proportion of new features fail their initial testing, that’s a signal about the quality of what’s coming out of development, and that’s a conversation to have before the next iteration.

The bugs are the symptom. The production question is what the pattern tells you about how the team is working.

None of this replaces reading the actual bug report. It means you’re reading it differently. The question to ask is what the distribution tells you, and where the project needs attention.

Test plans and milestone acceptance

This is where QA connects directly to the legal and commercial structure of the project. Production 101 #8 covers the milestone structure in contracts. The short version: milestones in a development agreement carry acceptance criteria, and those criteria determine whether the milestone gets paid. The question of who writes those criteria, and what they actually test, is where test plans become contractually significant.

The acceptance criteria problem is this: “done” means different things to the development team, QA, and the publisher, and the place these three definitions have to match is in the test plan. The development team thinks done means the feature is implemented. QA thinks done means the feature passes the test cases. The publisher thinks done means the feature meets the specification they signed off. Those are often different things. The producer’s job is to find out they’re different before the milestone submission, not after.

This is why QA involvement in milestone planning matters, not just milestone testing. If the QA team isn’t part of defining the acceptance criteria for a milestone, you’ll have a test plan that tests the wrong things, and a milestone review where the publisher’s criteria and your test plan don’t match. That’s a slow, expensive conversation to have at the wrong moment.

The test plan is also your record. In a milestone dispute, the test plan is the document that says what was tested, how, and with what outcome. A well-structured test plan that maps directly to the milestone acceptance criteria is evidence. A set of bug reports with no structure is noise.

The QA/producer relationship

QA leadership often has better real-time visibility into project health than anyone else on the team. Think about what they see: every feature at the point of completion, every bug through its full lifecycle, every area of the game that’s being tested and retested. They see the fragile systems before they become critical. They see the features that are repeatedly failing verification before that becomes a milestone problem. They have a picture of the project that no one else has, and they have it before anyone else.

Building a genuine working relationship with QA leadership means getting that picture early. That requires two things. First, the QA lead needs to trust that honest reporting will be used to solve problems, not to assign blame. If the first time a QA lead tells a producer “this area is fragile and we’re worried about it” the producer responds by escalating to leadership and making it a crisis, the QA lead will learn not to tell the producer that in advance. The honest reporting that makes early warning possible depends on the producer responding to it well.

Second, it means the producer has to actually ask. A QA lead who isn’t being asked will tend to report what’s in the system: bug counts, coverage percentages, test execution status. Those metrics are accurate and not very useful. The useful information is the qualitative read: which areas feel stable, which feel fragile, where are the testers finding unexpected behaviour that doesn’t have a bug filed for it yet. That information requires a conversation, not a dashboard.

I’ve had QA leads who’ve become the most reliable early warning system on a project, and I’ve had QA leads I barely spoke to because I was managing them as a service function. The difference in what I knew about my projects in those two situations was significant.

Live service QA specifics

Regression testing on a live game is a different problem from certification testing on a boxed product, and the difference goes beyond scale.

On a boxed product, you’re testing toward a fixed release. The risk is a defect in the shipped build. On a live game, you’re testing toward a continuous stream of updates against an existing player base. A broken feature on a live game affects your current players immediately, and the moment the update is live, you can’t take it back without a hotfix. That changes the risk calculation completely.

The regression scope question is one of the harder ongoing decisions in live service production. You can’t regression-test everything every time you ship, because the cadence of a live game doesn’t give you the time. What you can do is maintain a regression suite that covers the highest-risk areas: systems that have broken before, systems that many players interact with, monetisation flows. The question of what’s in that suite and when it gets updated is a joint decision between QA and production.

Hotfix protocols matter more in live service than anywhere else. When something breaks in production, the pressure to fix it quickly is intense. The risk is that a rushed hotfix introduces new problems. The discipline of having a fast-track process that still includes a meaningful QA pass, even if compressed, is what prevents one bad deploy from turning into two. That process needs to be designed before something goes wrong. Designing it during the incident is too late.

The “good enough to ship” question gets asked constantly in live service. The answer requires both QA data and production context, and the producer has to own the call.

The judgement call of when a risk is acceptable and when it isn’t is one of the hardest things about live service production. QA can tell you what’s broken and how severe it is. They can tell you what the workaround is, if one exists, and what the likelihood is of the bug being encountered in normal play. The producer has to add the context: how many players are affected, what’s the competitive window, what’s the cost of delay. That combined assessment is the decision. Neither side can make it alone.

Leave a comment

If you want context on how milestone structures connect to the contractual picture, Production 101 #8 on legal documents covers the framework. For how the producer’s reporting picture relates to what QA is generating, Production 101 #9 on status reports is the relevant entry.

• Every major platform has a certification framework, a submission portal, and a store CMS. The producer is usually the person navigating all three.

• Sony’s TRC and Nintendo’s Lotcheck have specific timelines that will rearrange your launch window if you discover them too late.

• IARC makes age rating compliance straightforward for digital releases. Physical ratings are a different, more expensive matter.

• Platform documentation changes with each platform update. The producer’s job is knowing where to find the current spec, not memorising the last one.

The first time you submit a build to cert, the surprise is the realisation that almost everything you needed was public documentation the whole time. Every platform has a framework. Every framework has timelines. Every timeline has a way of colliding with your ship date if you discovered it too late. In smaller studios, the producer is typically the person who finds this out.

Subscribe now

Why platform knowledge sits with the producer

In a large studio, platform relations is its own discipline. There are people whose entire job is managing the publisher relationship and navigating cert. In a smaller studio, the producer is that person. You’re the primary contact for the platform’s partner team, the one who manages the developer portal access, the one who reads the cert report and decides what the team needs to fix first.

Understanding the framework is the difference between a launch window you planned for and one you scrambled through.

This post covers the six platforms I’ve shipped on directly: iOS, Android, PlayStation, Xbox, Nintendo, and Steam. It doesn’t attempt a deep treatment of cert failure types, rejection reasons, or escalation paths. The goal is narrower: name the framework, explain the timeline, point to the portal. That’s enough to plan well.

What every platform has in common

Platform by platform, the differences are real, but the structure is the same. Every platform has a technical compliance framework, a submission process, a review timeline, a store or CMS where your product lives, and an age rating requirement.

Every producer shipping on a new platform for the first time should ask the same five questions. What is the certification framework called? How long does cert take? When does the store page need to be ready relative to launch? What age ratings are required for my target markets? Who is my primary contact in the platform’s partner team?

The answers vary. The questions don’t.

The platforms

PlayStation

Sony’s technical compliance framework is the TRC, the Technical Requirements Checklist. It covers DualSense features, trophy implementation, system integrations, error handling, and a range of other platform-specific requirements. The full TRC is available to authorised developers through the PlayStation Partners portal at partner.playstation.com, behind NDA.

One missed TRC can cost you weeks. Start validating against it during alpha. Not during submission.

After cert passes, Sony’s marketing and store team requires approximately four weeks to set up your store page from the assets you provide. That four-week window starts after cert passes, so treat the cert pass as the midpoint of your launch process. Factor those four weeks into your launch window from the beginning.

Xbox

Microsoft’s framework is the Xbox Requirements, abbreviated XRs. Cert typically takes four to seven business days. After cert, Microsoft’s Biz Ops team needs approximately two weeks to build out the store page from your submitted metadata, similar to the Sony store setup lag.

Microsoft offers an optional paid Certification service that provides early XR compliance feedback before formal submission. Worth considering if you’re uncertain about specific platform integrations. The developer portal is Xbox Partner Center at partner.microsoft.com/dashboard.

Nintendo

Nintendo calls their process Lotcheck. The name sometimes misleads producers who haven’t shipped on the platform before. Lotcheck checks platform compliance: Joy-Con behaviour, text handling, eShop integration, button art compliance, and rating compliance. Game bugs that fall outside those requirements are yours to find before submission. Expecting Lotcheck to catch them is a planning error.

Submit thirty days before your expected release date. Nintendo’s review timeline is longer than the console competition. The Nintendo Developer Portal at developer.nintendo.com holds the full guidelines once you’re authorised.

“Submit thirty days before your expected release date. Nintendo’s review timeline is longer than the console competition, and it will not flex to match your marketing window.”

iOS

Apple’s process is App Review. Ninety percent of reviews complete within 24 hours, but complex apps (those with in-app purchases, sensitive permissions, or account creation) can take three to seven days. Holiday periods extend timelines further.

Submitting Tuesday through Thursday during US business hours tends to produce faster turnaround than submissions near weekends or major holidays. This is anecdotal and not guaranteed, but it’s the pattern I’ve seen consistently across multiple submissions. The CMS is App Store Connect at appstoreconnect.apple.com.

Android / Google Play

Google Play Console at play.google.com/console is the submission and management interface. Google’s review process is generally faster than Apple’s. The Play Console also handles policy compliance, rating submissions via IARC, and staged rollout controls.

If you’re shipping simultaneously on iOS and Android, plan your submission windows so that iOS cert doesn’t create the bottleneck. Submit iOS first, or give yourself enough buffer that a slow App Review cycle doesn’t push the Android release date without reason.

Steam

Steam uses Steamworks for all developer and publishing functions. The partner portal is at partner.steamgames.com.

A few Steamworks-specific timelines that catch producers unprepared. New developers wait 30 days after paying the Steam Direct app fee (US$100 at time of writing) before they can publish. Your Coming Soon page needs to be live for at least 14 days before your release date. Store page review takes three to five business days. Build review takes one to five business days.

These timelines caught me off-guard on my first Steam release. The build review window felt obvious in hindsight, but the 14-day Coming Soon requirement and the 30-day new developer hold both required rescheduling. Factor all of them into your launch window, not just the build review.

Epic Games Store

The Epic Games Store serves a meaningful audience on PC. I haven’t shipped there directly, so this post doesn’t speak with authority on the cert framework or timelines. If you’re publishing on EGS, read the developer documentation directly rather than relying on secondhand accounts from developers on other storefronts.

Age ratings

Every major market has age rating requirements, and all the major platforms require valid ratings before approving your product for sale. You need them for every territory you’re selling into.

The International Age Rating Coalition, IARC, is the practical answer for digital games. It’s free and adopted by all the major digital storefronts: Xbox, Nintendo eShop, PlayStation Store, Google Play, and Steam. It works through a single questionnaire embedded in the storefront submission flow. That questionnaire generates ratings for multiple territories simultaneously: ESRB for North America, PEGI for Europe, USK for Germany, and others.

If you’re a digital-first studio, IARC is almost certainly your route. You go through the storefront submission flow and it’s already there.

“IARC is free, takes fifteen minutes, and handles multiple territory ratings from a single questionnaire. For digital releases, do it at the start of the submission process.”

Physical releases are a different matter. Traditional ESRB and PEGI certification for physical media is a paid process. PEGI certification for a physical release can run to several thousand euros, and the timeline is long. If you’re planning a physical SKU, factor both the cost and the submission lead time into your production budget and schedule from the start. Neither is trivial, and both are regularly underestimated by studios approaching their first physical release.

The physical rating cost surprises studios more than almost any other launch expense I’ve seen. It gets missed in early budgets because the team assumes digital ratings apply everywhere. Physical ratings require separate paid certification. Flag it early and put a number against it.

Store pages and CMS

Every platform has a content management interface where your store page lives: metadata, descriptions, screenshots, trailers, pricing, localisation. In smaller studios, the producer often owns this alongside cert submission.

App Store Connect’s review flow, the Xbox Partner Center store page builder, and Steamworks’ store page editor all have quirks that slow you down the first time you use them. Get into the interface before your launch window, not during it.

Cert passing and store going live are two separate events with their own timelines. The Sony four-week store setup and Nintendo’s thirty-day Lotcheck window are the two that most often catch producers out, because they sit on the far side of a cert pass that the team treated as the end of the line.

Building platform timelines into your schedule

Platform cert belongs in your milestone schedule as a fixed constraint with a buffer, anchored to your ship date and worked backward. Plan it at the start of production, with the same rigour as any other milestone.

For a simultaneous multi-platform launch: identify the longest cert window, which is usually Nintendo’s Lotcheck, set your first submission date from that, then verify the other platforms fit within the same window.

“The common planning error is setting a ship date, then calculating whether cert will fit. Set a cert date and let it drive the ship date.”

For each platform, you need three dates in your schedule. When the cert build needs to be ready. When store assets need to be submitted. When any platform-specific submissions (age ratings, store page review) need to happen. A platform cert calendar with those dates is a basic production artefact for any multi-platform release.

The producers who handle multi-platform launch well start the cert planning early, go back to the actual documentation each time, and treat the timelines as constraints rather than rough guides.

[INTERNAL LINK: Post #13 - How to Build a Milestone Schedule] [INTERNAL LINK: Post #14 - Scope Management and the Art of Cutting]

One more thing about documentation

Every platform updates its requirements periodically. The TRC changes. Lotcheck requirements change. App Review guidelines change. What was true on the last title may not be true on this one.

Leave a comment

The producer’s job is knowing where to find the current spec and checking it at the start of each new project. Read the actual documentation. Memory from the last title drifts. Platforms update their requirements, and a requirement that passed on your last game may fail on this one. That check takes fifteen minutes at the start of a project and can save several weeks at the end of one.