A game can be built faster and still take longer to make good. Anyone who has watched a “quick” feature turn into three weeks of debugging, reworking, and asking “wait, why does it do that?” already knows the difference. That distinction matters in the news surrounding Epic Games’ upcoming Disney project. According to Game Developer’s report on Bloomberg’s reporting, the unannounced game has moved away from a planned March release target while its development shifts toward an “AI-first” approach. An internal message reportedly called for art to be made with full AI workflows and said there should be “no more hand-written code.” That’s a striking instruction. It also raises a bigger question than whether AI can produce an image or a working function: who understands the result well enough to turn it into a coherent game?
What The Report Actually Says
The project is reportedly a shooter connected to Epic’s Disney collaboration and involving Star Wars and Marvel properties. The reported production change and delay come from Bloomberg’s account of people familiar with the project and an internal message it reviewed. We haven’t seen the game, its development process, or the final policy in practice, so it would be a mistake to judge the finished experience now.
Epic CEO Tim Sweeney has publicly described a broader company pivot toward using AI to accelerate development. He said the goal is to make more and better things, rather than simply make the same things with fewer people. That statement explains Epic’s wider ambition, but it doesn’t independently confirm every reported instruction on the Disney project.
| What’s Been Reported | What We Still Don’t Know |
|---|---|
| The Disney project has shifted toward AI-first development. | How consistently that approach will be applied across teams. |
| An internal message reportedly discouraged hand-written code and called for AI-generated art workflows. | Whether developers can make exceptions when the work requires them. |
| The game has moved beyond its planned March target. | Whether the production shift caused the delay or is one response to it. |
Those unknowns matter. “AI-first” can mean anything from using tools to assist with repetitive tasks to making generated output the default for core creative and technical work. The consequences depend on which one Epic actually means.
Insider Tip: When you hear about a major production pivot, separate its stated goal from its working rules. “Make better games faster” is a goal. “No more hand-written code” is a rule. The rule is what changes a developer’s day.
Speed Doesn’t Tell You What To Build
Production tools are useful when they give a team more room to solve the right problem. If a tool helps someone prototype an idea, explore alternatives, or clear a tedious task, that time can go back into the experience. I’m all for making the boring parts less boring.
But generating more work isn’t the same as making more progress. Games depend on thousands of connected decisions: what a player notices, what they understand, what a system rewards, and how one action changes the next. If those decisions aren’t clear, producing assets and code faster can leave the team with more material to review, integrate, and eventually replace. Think about a combat ability. Getting a first implementation running might be quick. Making it readable during a crowded encounter is harder. The animation, timing, sound, enemy response, camera, and level layout all have to tell the player the same story. If the ability technically works but nobody can read its range, speed has delivered a feature, not a finished experience.
The useful question isn’t “How much did we generate this week?” It’s “What became clearer, stronger, or more playable?”
Insider Tip: Before accelerating a workflow, identify what’s actually slowing the team down. If the bottleneck is unclear direction or slow playtesting decisions, producing more assets won’t fix it. It may just give the team a bigger pile to sort through.
Code Still Needs Someone Who Understands It
The phrase “no more hand-written code” grabs attention because writing code isn’t just about typing instructions. Developers use implementation to test assumptions, expose edge cases, understand dependencies, and decide how a system should behave when the player does something unexpected. Players are exceptionally good at doing something unexpected.
AI-generated code can help with a prototype or a well-bounded task. It still needs people who can explain what it does, test its failure cases, and maintain it when the rest of the game changes. If the team can’t confidently modify a system six months later, the time saved at the beginning may come back as a much more expensive problem.
| A Feature Is “Done” When… | The Team Can Answer… |
|---|---|
| It runs | Does it behave as intended in the current build? |
| It connects | What happens when another system changes? |
| It’s readable | Can players understand its cause and effect? |
| It’s maintainable | Can developers diagnose and alter it later? |
None of these questions is answered by the origin of the first draft. Hand-written code can be a mess too. The point is that a production rule should leave room for whichever method gives the team the clearest, most dependable result. Turning “use AI where it helps” into “don’t write code yourself” risks confusing a tool preference with a quality standard.
Insider Tip: Ask the person reviewing an AI-assisted feature to explain its behaviour and change one meaningful condition without starting over. If they can’t, the feature isn’t ready to become part of a larger system, even if today’s build runs.
Art Direction Is More Than Making Images
The same issue applies to art. A good game doesn’t need every object to look realistic, and it doesn’t need every asset to be individually impressive. It needs a visual language the player can trust. Shapes, colours, motion, and contrast help players recognise what matters and predict what might happen next.
That becomes particularly important in a game bringing together familiar fictional worlds. A team has to decide what belongs in the same playable space, which visual rules carry across environments, and how much detail the player can process during action. Generating an appealing image is one step. Making every image support the same experience is the difficult part.
Imagine a room full of beautifully rendered objects where the interactive ones look exactly like the decoration. The art may be polished, but the player is left guessing. Now imagine a much simpler room where the important object has a consistent silhouette, position, and response. The second room may do a better job because its art is making a promise the game keeps.
Art direction is the set of decisions that makes those promises consistent. An AI workflow can produce options for artists to assess, but it can’t remove the need for a person to decide what the player should see, understand, and feel.
Insider Tip: Test visual work in motion and at gameplay distance, not just in a full-size still. If players can’t distinguish a hazard, objective, or interactive object when they need to, the asset isn’t doing its job yet.
The Team Needs Room To Question The Output
There’s also a human side to an AI-first mandate. Developers need the freedom to say, “This result doesn’t work,” “I don’t understand this implementation,” or “Making this ourselves would be better.” That isn’t resistance to efficiency. It’s how teams protect the game from a bad assumption becoming everybody’s problem.
I don’t know how Epic’s reported instruction will be interpreted internally, and we shouldn’t pretend to know what its developers are allowed to challenge. But any studio considering a similar shift should pay attention to the incentives it creates. If success is measured mainly by how much AI a team uses, people may feel pushed to use it even where it adds review work or weakens the result.
A healthy process makes the tool accountable to the team, not the other way around. Developers should be able to compare approaches, explain trade-offs, and choose the one that serves the experience. Otherwise, the workflow starts dictating the design.
Insider Tip: Give teams a clear way to record when AI-assisted work saves time and when it creates extra correction, integration, or testing. Both outcomes are useful evidence. Only counting the first one gives you a flattering production report and a much less flattering build.
Judge The Pivot By The Player Experience
Epic’s ambition to make more and better things is easy to understand. Every studio wants more room to experiment and less time spent wrestling with production friction. But “more” is straightforward to count. “Better” needs a harder test.
For this project, that test won’t be the number of generated assets or lines of code avoided. It’ll be whether the final game feels deliberate. Can players read its systems? Do its worlds hold together? Can the team respond when playtests reveal a problem? Are the decisions behind the experience understood well enough to improve it?
| Production Measure | Player-Facing Test |
|---|---|
| Faster implementation | Does the mechanic communicate clearly and hold up under pressure? |
| More art options | Do players recognise what matters without being told? |
| More content | Does each addition strengthen the experience? |
| Shorter initial tasks | Can the team still revise and maintain the work? |
If AI helps developers answer those questions more effectively, that’s worth learning from. If it mainly helps produce a larger volume of work before the difficult decisions are made, the apparent speed may disappear during integration and revision.
Insider Tip: Pair every production-speed measure with a quality measure. A faster first draft only counts as a win if the complete feature also reaches a playable, understandable state sooner.
Final Thoughts
We don’t yet know what Epic’s Disney game will become. The reported AI-first directive might change during development, be applied differently across disciplines, or result in a process more nuanced than those words suggest. The finished game deserves to be judged when people can play it.
The wider lesson is already useful, though. Tools can help a team make things. They can’t decide which things belong together, why a player should care, or whether a system makes sense once it leaves the editor. Those decisions need people who understand the work and have the authority to change it. Make the process faster if it helps. Just don’t mistake the speed of producing something for the craft of making it worth playing.
That’s it for this one! Subscribe to The Design Lab for more breakdowns and analysis. Please like, share, and comment if you found this article useful AND…
Need help applying these concepts to your game? Most games don’t fail because of bad ideas. They fail because the systems don’t work together to evoke immersion.
> Work with me:
https://thedesignlab.blog/services/
> Or go deeper into this framework:
Register for my upcoming book – Immersive Design Framework – below and get a second book, now, free!
Grab Myles’ FREE ebook now and find 15 indispensable design patterns that will equip you to craft exceptional Web3 gaming experiences. We’ll also notify you when his new book on immersive design is out!