Epic Games is reportedly changing how it builds a major game: AI models would generate code and help guide the art, while human developers manage and steer what comes out. The shift is tied to the company's planned collaboration with Disney, on a Marvel- and Star Wars-themed shooter that was expected to launch in March 2027. A Bloomberg report says the project has since been delayed indefinitely amid the change, with development running slower than expected.
That's a big claim, and it needs tight framing. Bloomberg's details reportedly come from people familiar with the project and internal messages it reviewed. Epic, meanwhile, has described the effort more narrowly as AI-accelerated development led by its own developers. Those aren't the same thing: "AI-first" can sound like a complete production system, but using models to generate assets doesn't remove the need to make those assets actually work in the game.
Here's the real question: not whether AI can write code or make art - it can. The harder part is whether Epic can turn that capability into a dependable workflow without creating new bottlenecks in quality, integration, rights management, and accountability. This situation is a useful stress test for what "AI-first" might mean for studios - and what any business should check before copying the approach.
What has been reported about Epic's pivot
Epic and Disney announced a $1.5 billion collaboration in early 2024. The partnership was expected to support a new games and entertainment universe, including a shooter drawing on Marvel and Star Wars. The initial timeline pointed to a March 2027 release.
A Bloomberg report, summarized by Ars Technica, says Epic is moving toward an "AI first" development strategy. According to people familiar with the work and internal employee messages reviewed by Bloomberg, models such as Anthropic's Claude would generate code, while art assets would be produced using full AI workflows. Human developers would still manage and guide the output. The report frames the change as "no more hand-written code."
Epic's own statements are more careful. A spokesperson said the company is embracing AI-accelerated development, led by Epic developers who remain the visionaries and creative drivers. CEO Tim Sweeney has also described a shift toward "maximum AI acceleration," saying the point is to help teams build more and better - not just to do the same work with fewer people.
Still, those comments outline direction, not a full plan. They don't specify which models or tools would be used in production, how code and art would be reviewed, or how Epic would measure whether the approach improves delivery. They also don't answer what "AI first" means for every team and every stage.
One project-management detail matters too: Bloomberg reports the game has been delayed indefinitely during this change, citing understaffing and slower-than-expected development. That doesn't prove AI caused the delay. It does suggest a workflow shift is happening while the project is already under strain. In real production terms, that's when tool and process changes tend to hurt the most - especially when teams have a fixed scope, accumulated decisions, and a schedule that may already be stretched.
What "AI-first" development means in practice
"AI-first" can mean anything from using a coding assistant for routine tasks to treating generated code and content as the default starting point. Those are very different setups. Without more detail from Epic, it's too early to assume the reported workflow means every line of code or every asset is created and approved without human work.
A practical way to think about it is to split the pipeline into three steps: generation, integration, and acceptance.
- Generation: A model produces a code suggestion, image, texture, animation concept, or other asset from a prompt and whatever context it has.
- Integration: Developers and artists adapt the output to the game's architecture, art direction, performance needs, and production tools.
- Acceptance: The team tests and approves the result for use - covering behavior, quality, provenance, and fit with the rest of the project.
AI can speed up generation. It doesn't automatically speed up integration or acceptance. A model can crank out code quickly and still leave an engineer to chase edge cases, security issues, performance problems, or mismatches with existing systems. An image can look great on its own and still fail when it has to match character proportions, tile cleanly as a texture, or stay consistent with the game's visual language.
Games make this especially clear because everything is connected. A change to an asset can ripple into rigging, animation, lighting, memory use, and the player's experience. A code change can need to work across platforms, under different network conditions, and alongside a large set of existing systems. The output isn't valuable just because it was generated fast - it's valuable if it survives the rest of the pipeline.
So the human role doesn't disappear when models handle more of the first draft. It shifts. Developers may spend less time typing boilerplate and more time defining requirements, supplying context, reviewing results, and setting up automated checks. Artists may spend more time steering variations, selecting what's usable, and keeping everything consistent across a full world. Whether that's "better" depends on how the workflow is built - and how much extra review it creates.
The operational metric that matters isn't "how much was generated." It's the amount of accepted, production-ready output per unit of team effort. If a model produces ten options but only one survives without extensive rework, the generation rate doesn't tell you much. If it reliably handles a bounded task and frees experienced staff for higher-value work, then the case gets stronger.
The business case - and the delivery risk
Epic's stated goal is to help teams build more and better, and to extend those benefits to teams building on Unreal Engine. If Epic can make this workflow reliable, it could influence not just one game, but how internal teams and external developers think about AI-assisted production across the Unreal ecosystem.
There are real potential benefits. Models can help teams explore options, generate first drafts, handle repetitive tasks, and shorten the distance between an idea and something a developer can test. In a big production, reducing downtime between iteration cycles can matter more than cutting headcount. Faster experiments can also help teams spot weak design decisions earlier - when it's still cheap to change.
But output volume isn't the same thing as production capacity. If a team can generate more assets than it can review, validate, and integrate, the bottleneck just moves. The same applies to code: faster code generation can raise the volume of changes queued for review, testing, and long-term maintenance. If those checks don't scale up too, defects can pile up faster.
There's also the transition cost. Teams need new working conventions: which tools are approved, what information can be shared with them, how generated work is documented, who owns review, and what happens when an output is wrong. Existing pipelines may need changes. People need time to learn new habits, and leaders need to decide whether AI-generated work holds the same standard as everything else. Those costs are easy to gloss over because they show up across many teams, not as one neat line item in a schedule.
Bloomberg's reported indefinite delay makes sequencing more important. Changing production methods can pay off over the long run - but rolling it into a project that's already delayed adds uncertainty. A fair assessment should ask whether the AI workflow is being tested in a contained part of production, or whether a large share of the pipeline is changing before the new process has proven itself.
For a studio considering something similar, these questions beat the usual "AI or no AI" argument:
- Which production bottleneck is the tool meant to reduce?
- How will the team measure accepted output, not just generated output?
- What review and testing capacity is needed to handle the extra volume?
- Can the workflow be rolled back or limited if quality or delivery worsens?
- Does the project have time and staffing to absorb the transition?
The business case is strongest when the work is repeatable, the results can be evaluated cleanly, and a human can correct failures without blowing up costs. It's weaker when the work relies on subtle creative judgment, unclear ownership, or tight integration with systems the model can't reliably understand. None of that argues against experimenting - but it does argue for choosing the experiment carefully.
A practical test for responsible AI adoption
An "AI-first" label doesn't say much about whether the workflow is actually controlled. To get that, a team needs practical rules for quality, accountability, and rights. The point isn't to produce a document nobody follows. It's to make day-to-day decisions clear enough that developers and artists can move quickly without constantly guessing where the boundaries are.
A good place to start is a four-part test.
1. Define the task and its boundaries
Pick a specific job, not a vague goal like "make development faster." For example, test whether a model can draft an internal tool for review, or generate concept variations an art director can assess. Spell out what the model is allowed to do, what context it can access, and what must stay under human control.
That keeps the result measurable. A single bounded task can show whether the workflow saves time - or just pushes effort into review. A broad instruction to "use AI everywhere" doesn't answer that.
2. Set acceptance criteria before generation
Decide up front what "usable" means. For code, acceptance criteria might include passing tests, meeting performance limits, and meeting security and architecture requirements. For visual assets, it might include alignment with art direction, technical readiness, and documented provenance where it matters.
Without acceptance criteria, teams often treat plausible output as finished work. That leads to an informal quality standard where reviewers rely on personal judgment - and disagree about what's safe to ship.
3. Keep responsibility attached to people
A model can generate suggestions. It can't take responsibility for production decisions. Assign a person or role to review the output, record any material changes, and approve whether it can be used. The level of scrutiny should match the risk: a temporary mock-up doesn't need the same checks as a shipped gameplay system or a prominent character asset.
This is also where employee impact has to be handled honestly. Epic's CEO has said the goal isn't just to do the same work with fewer people. That's an intent statement, not a full description of how roles, workloads, or staffing will change. Any company rolling out AI at scale should explain what kinds of work will shift, what skills people will need, and how the transition will be supported.
4. Check rights, data handling and traceability
Teams need to know whether prompts or project materials get sent to third-party services, how those services handle data, and whether generated output can be used under the project's requirements. That depends on the tools and contracts involved, and you shouldn't assume a model can be used safely just because it works technically.
Keep records that let you trace important production outputs: which tool was used, what human review happened, and where the result entered the project. Traceability isn't busywork. It's what lets you investigate defects, answer provenance questions, and fix the workflow when something goes wrong.
The test is simple: can the team show that AI use improves a real production outcome while keeping clear human accountability? If yes, expanding the workflow might be reasonable. If not, more generation isn't evidence of a better production system yet.
Conclusion: Treat the pivot as a testable production strategy
Epic's reported move matters because it frames AI as a change to the production model, not just another tool in a developer's toolbox. The upside is real: quicker iteration, more options, and less time spent on repetitive tasks. The risks are just as practical: review bottlenecks, integration work, unclear accountability, and the cost of changing a live production process.
The lesson isn't that every studio should become AI-first. It's that a studio should be able to explain which bottleneck it's addressing, how it will verify output quality, and what it will do if delivery gets worse. Start small, measure the whole pipeline, and expand only when the workflow holds up under real production conditions.
For the latest details on Epic's project, read the Ars Technica report. If you're evaluating AI in your own workflow, start with one measurable use case - not a company-wide slogan.