Game developer and designer — tasks, one by one
The unit of analysis is the task, not the job title. Each one below carries its direction, whether the judgement rests on evidence or on platform inference, the reasoning, and what it does not establish.
Every task on this page#
Designing mechanics, missions and puzzles
Still human-led≈ Platform inferenceInventing the rules, systems, missions, challenges and puzzles players meet, and deciding how they fit together.
Language models can list mechanics and puzzle ideas on request, but the ideas come from recombining games that already exist, and the hard part is not producing an idea: it is knowing whether it is fun, which only shows when people play it. A design also has to fit the team's budget, the engine and the game's identity, and someone has to answer for it to the creative lead and the publisher. Studios have little reason to hand that judgement to a tool, so the tool feeds the brainstorm and the designer still chooses.
This says who decides, not how many designers a studio needs: if tools let each designer explore ideas faster, a team can stay the same size and make more, or shrink. Evidence that would move it: a released commercial game whose core mechanics were chosen by a generative system with designers only reviewing, or studios cutting design roles and naming such tools as the reason.
Balancing and playtesting
Being augmented≈ Platform inferenceTuning numbers, difficulty and in-game economies, writing playtest plans, running tests with internal and outside players and reading the results.
Parts of this were automated long before language models: telemetry dashboards show where players quit, and scripts simulate fights and economies. Agents trained to play a game can now run many matches and explore levels faster than human testers, which surfaces broken balance and exploits early. What they cannot report is how the game feels — whether a difficulty spike is frustrating or satisfying — so the designer still watches real players, decides what to change and answers for it when the game ships.
Faster tuning shortens the work without saying who loses the hours: outside test groups and junior tuning roles are likelier to feel it than the lead designer. The judgement would move if studios shipped balance changes decided by automated agents without a designer's sign-off, or replaced sessions with real players by simulated ones.
Prototypes and mock-ups
Being augmented≈ Platform inferenceBuilding playable prototypes and gameplay code, and 2D layouts or 3D blockouts, to show creative and technical staff and management.
This is where the technology reaches daily work hardest. Code assistants write engine scripts, interface glue and common game logic from a description, and image and 3D generators produce placeholder art and rough environments quickly, so a prototype that once needed a small team can often be built by one person. A prototype still has to run in real time on the target hardware, generated code fails in ways only someone who understands the engine can find, and what the prototype is meant to prove is still decided by the person building it.
Augmenting can still mean fewer people: if one developer can prototype what used to take several, entry-level programming and greyboxing jobs are the first to thin out. Generated assets here are mostly placeholders; this does not say they reach a finished game. A dated case of a studio releasing a game whose code or levels were mostly generated, or cutting prototyping staff because of these tools, would move this towards automating.
Design documents and test specifications
Being augmented≈ Platform inferenceWriting and maintaining design documents — mechanics, guidelines, mission outlines, flowcharts, menu layouts — and the specifications handed to QA and production.
Once the decisions are made, turning them into a structured document is the kind of writing language models already do well: they draft specifications from notes, keep sections consistent, turn a design into test cases and produce flowcharts from a description. Studios can adopt this cheaply inside tools they already use, and a wrong document is caught in review rather than by players. What the tool takes over is the writing, not the decisions the document records, and someone still has to check that the document matches what was built.
This removes hours, not a role: few people are hired only to write design documents, so the effect shows as designers spending less time on paperwork, or as fewer junior designers whose first job was keeping documents current. It would move back if studios found generated documents drifting from what was actually built often enough to stop using them.
Story, characters and game text
Being augmented≈ Platform inferenceCreating storylines and character biographies, and writing or supervising dialogue, item descriptions, quest text and menus.
Language models write fluent text in any register, which makes the bulk of game text — item descriptions, incidental lines, variants of the same remark — cheap to draft. The story and characters are different: they carry the game's identity, players notice a weak line, and many players react badly to text they believe was generated. Writers' contracts, and rules on whether machine-generated text can be owned, also slow its use in shipped games, so the writer edits drafts rather than handing the voice over.
There is a split inside this task: bulk text may move to automating while the main story stays with people, and this judgement covers both. It does not say how many writing jobs remain. A dated release in which most of the text was generated at scale and players accepted it, or a change in the rules on owning generated text, would move this.
Design reviews and leading the team
Still human-led≈ Platform inferencePresenting concepts to management and colleagues, running design reviews, guiding discussions between teams, and working with artists on visual style and with production on schedules.
This work is persuasion and arbitration between people who want different things: artists, programmers, producers and the publisher. Tools summarise meetings and track tasks, but the value lies in deciding which feature is cut, holding a team to one vision and being trusted to make that call, and that comes from a person's standing in the team. Nothing in current technology gives a studio a reason to let a machine settle those arguments.
Human-led says the coordinating role survives, not how many coordinators: if teams shrink because building is faster, fewer people are needed to lead them. It would change if studios began running production with automated planning tools that make scheduling and cut decisions which leads only approve.
Setting the rules for generated content
New task≈ Platform inferenceDeciding where generated content may appear in a game, checking where it came from, and designing the limits for characters or systems that generate text or behaviour while the game runs.
Once generated assets and characters enter a pipeline, someone has to decide what is allowed: which art is placeholder and which may ship, what a character that improvises dialogue must never say, and how to keep a record of where each asset came from for platform holders and publishers. This is design work with legal and reputational edges, and it lands on designers and technical leads because they know the systems.
A new task is not a new job: in most studios it is part of an existing designer's or lead's week, and it grows only as far as generated content actually ships. It would grow into roles of its own if platform holders or rules began requiring games to disclose generated content and keep provenance records.