Most arguments about this compare the wrong artefact. They put a generated game next to a crafted one, play both for ten minutes, and declare a winner.
A shipped game is not an artefact. It is a commitment. It gets patched when an exploit appears, rebalanced when players find the dominant strategy, ported when a platform changes its rules, and defended when something breaks on a Friday night. Generation produces the first version. Everything expensive happens afterwards, and that is where the honest comparison lives.
The clearest place to see the distinction is in categories where a game is a regulated financial product as well as a piece of software. International crypto-gambling platforms build their own titles alongside licensed ones, and an operator serving markets outside the United States, the kind found under crypto casino Canada searches, has to keep every game demonstrably matching the mathematics it was certified against, for years. A model can produce something that looks like that game in an afternoon. It cannot hold the certification.
What generation is genuinely good at
Considerable, and it is worth being specific rather than dismissive.
The rules layer is close to solved. State machines, win conditions, scoring, input handling, collision, restart flow: a model writes these quickly and correctly, and where it fails it usually fails visibly, which makes the failures cheap. Work that used to consume a weekend now costs a prompt and a follow-up.
Content volume is the second win. Variation on a theme, level layouts within defined constraints, dialogue that has to exist without having to be memorable. These are tasks where quantity has real value and the quality bar is competence rather than distinction.
Anyone who claims a model cannot build a working game has not tried recently. That argument is finished.
The cost curve is not what people assume
There is a widespread belief that this is getting cheaper every quarter. Half true, and the misunderstanding matters for anyone budgeting.
Per-token prices have fallen sharply. Published API pricing shows frontier models at around two dollars per million input tokens and eight per million output, with cached input at a quarter of that. Reasoning models saw a reported cut of roughly 80% during 2025, down from something near ten and forty dollars.
The catch is that reasoning models produce intermediate steps before answering, and those steps are billed output whether or not anyone sees them. A task that consumed two thousand output tokens under the old approach can consume many times that under the new one.
So unit price falls and units per task rise. For simple, bounded work the price cut wins and generation is genuinely cheaper than it was. For open-ended design work, where the model is asked to weigh options rather than execute a specification, consumption wins and the same task costs more than it used to. Budget on cost per completed task, never on the rate card.
The part that does not transfer
Here is the distinction that survives contact with a real project.
A model can produce a difficulty curve. It cannot notice that players are quitting at the fourth level, form a theory about why, test the theory against a build, and be wrong twice before getting it right. That loop is not a text-generation problem. It is a judgment problem carried out against evidence from real people, and it is most of what separates a game that works from a game that runs.
The discipline behind it is ordinary product practice rather than anything exotic. Watching someone use the thing, noticing where they hesitate, changing one variable, watching again. Droven’s write-up of how award-winning design teams approach usability testing and iteration describes the same loop for applications, and games are the harder case because the target is a feeling rather than a completion rate.
Ownership is the real answer
Ask who is responsible when it breaks.
A studio that generated its codebase still has to read it, because on the night something fails, somebody must understand the system well enough to fix it under pressure. Code nobody has internalised is a liability that grows quietly, and it grows fastest in exactly the projects where generation saved the most time up front.
In regulated categories the point is sharper still. Someone has to sign a certification, argue with a compliance officer about what a jurisdiction permits, and carry liability for a feedback loop that a regulator might read as manipulative. None of that is generatable, and none of it is a coding task.
So, can they be as good?
For a small self-contained game with a fixed scope and no obligation to anyone, yes, already, and the gap is closing fast enough that arguing about it is a poor use of time.
For a game that has to be maintained, balanced against a live audience, certified, and defended for years, the question is malformed. It is not asking whether a model can write better code. It is asking whether a model can hold a commitment, and it cannot, because holding a commitment is a thing only a party with responsibility can do.
The teams doing well with this understand the split. They generate the parts that are specifications and reserve their people for the parts that are judgment. The teams doing badly generated everything, shipped fast, and are now maintaining a system nobody in the building fully understands.
Gambling involves risk and the house edge is built into every game by design. 18+. Play responsibly.
