What happened
AI coding tools have made it easy to build a working copy of someone else's game in an afternoon. Over the past few months, independent studios have grown worried about fast AI-made clones. Game Developer reports that at least one studio delayed a public playtest for fear its demo would be copied.
In late October, users spotted a new rule in Anthropic's Claude Code: build original games, genre games, or games from the user's own designs, but don't recreate a specific existing game, even under a new name. Anthropic confirmed the change. A member of its technical staff said it was added to steer Claude Code away from “recreating someone else's specific game” because using it to infringe IP breaks Anthropic's usage policy. He added that the company would keep adjusting the balance, and asked people to report it when the tool turns down something that is genuinely theirs.
Not everyone is happy. Some users say they're now being blocked on other tasks, and critics point out that a determined copier can reword the request or switch to an open model with no such rule.
That tension is exactly what makes it a good product case.
The case
You're the product manager for an AI coding tool. Some users are using it to build copies of other studios' games, and those studios are complaining. Should you add a limit? If you do, how will you know it's working?
1Clarify
- How big is the problem? What share of game-building requests are copies of a specific existing game?
- What's the legal and policy position? Does copying already break our usage terms, and what's our exposure if we do nothing?
- Who builds games with us? Hobbyists, indie developers, students, or people cloning games to sell?
- What does success mean? Fewer clones, fewer complaints from studios, or both, without losing honest users?
2Structure
Split it by who is affected. Four groups cover the decision without overlapping:
- Honest users building their own games, who must keep getting a great tool.
- The studios being copied, whose work and income are at stake.
- The business: revenue, legal risk, and reputation with developers and enterprise customers.
- Alternatives: other tools, including open models, that users can switch to.
3Analyse
Any rule like this makes two kinds of mistake. Lay them out side by side:
| It's the user's own game | It's a copy of someone else's | |
|---|---|---|
| Tool builds it | Correct | Mistake: the clone gets through |
| Tool declines | Mistake: an honest user is blocked | Correct |
The two mistakes hurt different people. A clone getting through hurts a studio. An honest user being blocked hurts your paying customer, and they may leave. A good answer says which mistake you'd rather make, and why.
The metrics you'd watch:
- Wrong refusals: the share of original-game requests that get declined. This should stay close to zero.
- Reports and appeals: how many users say “this was mine”, and how many of them were right.
- Retention of users who build games, compared with before the change.
- Complaints from studios, which should fall over the following months.
4Recommend
I'd add the limit, but keep it narrow: decline recreations of a specific existing game, and keep original games, genre games and the user's own designs working.
Copying someone's game already breaks our terms, and letting it run unchecked puts our reputation with developers at risk. A narrow rule protects studios without punishing the much larger group of honest users.
The risk is wrongly blocking real users. I'd give them an easy way to report a wrong refusal, track the wrong-refusal rate every week, and loosen the rule wherever it's catching honest work.
There's no single right answer here. Interviewers want to see you name the trade-off, pick a side, and say how you'd find out if you were wrong.