Epic Confirms Claude and Codex Write Unreal Engine Code: Ten-Year Bug Class Wiped Out in Months

Epic comes clean: Claude and Codex are writing UE6 code, and a ten-year bug has been swept away by AI.

One class of defect haunted Epic's engineers for ten years, and they never got rid of it. Once AI tools were brought in, it took months to clear.

This is not marketing talk. Epic's VP of Development Marcus Wassmer confirmed in response to media inquiries that AI coding tools like Claude and Codex have cleared a persistent class of defects in Unreal Engine known as non-deterministic cooking defects. This defect category had been on Epic's books for a decade, and manual troubleshooting had never cured it.

A company that has been making engines for over thirty years has handed its most core codebase to AI. It's worth examining carefully, both what it actually accomplished and what it didn't say.

From a post to official confirmation

The starting point was mid-October. On October 13, BBC reported that Epic CEO Tim Sweeney had announced a major pivot on social platform X, using the exact phrase "huge pivot." He asked developers to completely retool, in his words "retool for maximum AI acceleration," meaning rebuild the toolchain for maximum AI acceleration.

Later, a netizen pressed on X whether Epic was really using AI to write Unreal Engine code. Sweeney didn't skirt the issue, directly replying with the now widely quoted phrase: "Yes, we are currently using AI tools to develop code for Unreal Engine." PC Gamer then published a report with a hint of disbelief in the headline, saying Epic confirms they are vibe-coding things.

On October 28, GameDeveloper published a more solid official account. When responding to inquiries, Wassmer said that they had actually already talked about this on the Unreal Fest stage in Chicago and in later interviews: Epic is indeed using AI to develop code and features for Unreal Engine. At this point, rumor became confirmation, coming from the highest level in charge of development operations.

What exactly is AI writing at Epic

Wassmer gave quite specific scope. Almost all of Epic's current development is attached to three development streams: Fortnite itself, the UEFN editor, and the next-generation UE6. UEFN is an Unreal editor for the Fortnite creator ecosystem, where Epic has piled substantial resources in the past two years. He also revealed that they don't rule out releasing a UE 5.9; if it happens, it would be a small update targeted at specific systems, and it would include changes developed with AI's help.

A more aggressive case is Epic's own game launcher. Epic previously claimed that the launcher was rebuilt through vibe coding, and after the rebuild its operating speed increased noticeably. Wassmer confirmed that this practice is not limited to the launcher and game store; it is spreading to more products.

Here we need to explain some background. The term "vibe coding" has been frequently cited this year; it refers to developers using natural language to describe intent and letting AI directly produce runnable code, with humans retreating to the position of specifying requirements and accepting results. Many companies treat it as an experiment. Epic used it on a launcher serving hundreds of millions of players and publicly admitted it. Engine companies are usually conservative about their own toolchains, because if the toolchain breaks, all downstream teams suffer. For Epic to dare this, either internal validation was already sufficient, or competitive pressure had grown so great that conservatism was no longer an option. More likely, both.

There is one sentence worth pulling out. Wassmer said that engineers no longer write most of the code by hand, but Epic controls the scope of AI usage. The first half makes many people nervous; the second half is the key to the whole thing, which we'll get to later.

Why did non-deterministic cooking defects fall first

Cooking is jargon in the engine world; it refers to the process of converting art and level source assets into formats that each platform can run directly. A large game cooking run processes hundreds of thousands of assets through dozens of pipelines. Non-deterministic cooking defects mean that the same input can produce different results from one cooking run to the next. This kind of problem usually involves multithreading timing, cache state, and file system differences. Reproducing relies on luck, locating relies on brute force.

Unreal Engine's codebase is large and old; many modules are older than the careers of the engineers who maintain them. Manually hunting such defects is like looking for a needle that randomly appears in millions of lines of code. Epic chased it for ten years and never cleaned it up. That's not because the engineers were incompetent; it's because this class of problem naturally resists human troubleshooting methods.

AI tools happen to be good at this kind of work. It can do exhaustive pattern matching across a huge codebase, list out suspicious patterns scattered around all at once, and then reverse-engineer possible timing windows based on symptoms. Humans rely on experience and inspiration; AI relies on coverage, and coverage is exactly what non-deterministic defects fear most.

Here's a more concrete picture. A typical cooking pipeline scenario: the same batch of texture and model assets, on different machines and under different thread scheduling, gets packaged into files with slightly different order and content. Most of the time this difference is harmless, but certain assets are sensitive to loading order. When the differences accumulate to a threshold, it shows up on the player side as occasional crashes or texture glitches. The report submitted to engineers for such a defect is just one line: "player crashed in a certain scene," with no stable reproduction path and no definite trigger condition. What AI tools do after stepping in is essentially correlating the cooking pipeline logs, asset hashes, and code change history together, comparing every difference at a density that humans could never manage.

AI also has a less prominent but very practical use at Epic: automatically monitoring Fortnite's stability on PC, proactively identifying the driver and hardware combinations causing problems, and warning in advance. Previously this kind of investigation entirely required humans to compare massive reported data, which was time-consuming and labor-intensive. Wassmer's exact words were that these tools helped Epic do things that were previously impossible in streamlining and modernizing the engine, because of the size, complexity, and age of the code.

Direct comparison between manual investigation and AI assistance

Dimension	Past manual path	Epic's current AI-assisted path
Non-deterministic cooking defects	Chased for ten years, never cleaned	Swept away after Claude and Codex participated
PC stability issues	Manual comparison of drivers and hardware combos	AI automatically monitors and proactively warns
Game launcher	Old version was beyond repair	Rebuilt via vibe coding, noticeably faster
Engine modernization	Constrained by code size and age	Streamlining while developing, achieving what was previously impossible

Every row in this table comes from Epic's own disclosures; not a single row is external speculation. This is also the biggest difference between this event and previous vendor sloganeering: Epic explained the use, scope, and results clearly, including which tool wrote which part of the code.

The other side of the controversy

The story isn't all rosy. BBC's report pulled the timeline back a bit. About six months ago, Epic had just confirmed layoffs of more than a thousand people, and at that time Sweeney attributed the reason to declining Fortnite popularity, not AI.

Bloomberg's report disclosed that a collaboration with Disney involving Star Wars and Marvel characters had been delayed, and developers were asked to use AI tools to rush the project. The report quoted claims that supervisors told teams to stop writing code by hand, and the project's art would also be generated entirely through AI workflows.

Reactions on X were fierce. A comment accusing Sweeney of failing to read the room received 14,000 likes. Sweeney's response was harsh: "Many people in the room want to go back to 2016, but it's not 2016 anymore." He also emphasized that the purpose is not to do the same work with fewer people, but to let developers produce more and better things; he called it empowering creators. On the motivation for this big pivot, his statement was: an unambitious goal, to survive the AI revolution.

BBC's interview also included the voice of Lisha Howen, a 23-year-old full-time game designer. She said she wasn't completely against AI; some friends in game development already use AI to assist with coding, but friends in art basically don't, because game industry art is particularly resistant to this, and what people see is jobs disappearing. She also had a direct judgment: players can actually tell whether something is AI-generated. These words have no stance packaging, and they are closer to frontline sentiment than vendor statements.

Wassmer's attitude toward controversy is more direct: compared to skepticism about AI, they worry more about the risk of moving too slowly. He believes that in no time, using AI in development will become the norm for almost all software, because software built properly with AI will simply be better and respond faster.

Three pieces of homework ordinary teams can copy

Among Epic's practices, the most worth copying is not which tool to buy, but the three boundaries Epic draws around AI.

The first is limiting scope. AI-written code is constrained to clear development streams and systems, not random changes across the entire codebase. The second is keeping human review. Engineers don't write most of the code, but they control scope; the review responsibility actually becomes heavier, because they need to understand more changes in less time. The third is observable safety nets: use automated monitoring to keep an eye on stability, so problems in AI-written code can be quickly detected and rolled back.

In engineering practice, you can solidify these three boundaries into hard gates in your pipeline. Here is a CI gate configuration that can be directly adapted:

# ai-gate.yml: Hard gate for pipeline when AI participates in changes
name: ai-change-gate
on:
  pull_request:

jobs:
  gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Change size gate
        run: python tools/diff_guard.py --base origin/main --max-files 20 --max-lines 800
      - name: Deterministic build and test
        run: python -m pytest tests -x -q
      - name: Human review gate
        run: python tools/review_guard.py --require-approvals 1

The logic of the size guard script is simple: changes exceeding the threshold get rejected, forcing the submitter to break large changes into smaller ones:

import subprocess
import sys

def main():
    base = sys.argv[sys.argv.index("--base") + 1]
    max_files = int(sys.argv[sys.argv.index("--max-files") + 1])
    max_lines = int(sys.argv[sys.argv.index("--max-lines") + 1])
    out = subprocess.run(
        ["git", "diff", "--numstat", base],
        capture_output=True, text=True, check=True,
    ).stdout
    files, lines = 0, 0
    for row in out.strip().splitlines():
        add, delete, _name = row.split("\t", 2)
        if add.isdigit():
            files += 1
            lines += int(add) + int(delete)
    print("changed files:", files, "changed lines:", lines)
    if files > max_files or lines > max_lines:
        print("Change too large, please split before submitting")
        sys.exit(1)

main()

The thinking behind this gate is: the faster AI writes, the smaller each individual change must be when it's absorbed. Small changes are easier to review, easier to locate problems, and easier to roll back. What Epic calls "controlling scope" becomes, on the ground, executable and measurable gates rather than a slogan.

The review guard command corresponds to a script that is also not complex; its core is to check that at least one real human approval record exists on the merge request, and block the merge if not. Thresholds can be adjusted according to team circumstances, but two principles are best kept fixed. One: thresholds should be stricter rather than looser; once AI's output speed rises, human review bandwidth becomes the most expensive and scarcest resource in the entire system. Two: gates must be placed before the merge; if problems are discovered after merging, the cost is many times greater than before merging.

The wind vane has turned

Over the past few years, industry debate about AI programming has focused on whether it can go into production. Epic has essentially publicly declared that the debate is over, at least for them. Engine vendors are among the companies most sensitive to code quality; if the engine crashes, thousands of downstream game teams suffer. When such a company puts AI into its core pipeline and is willing to name tools and use cases, the signal couldn't be clearer.

For ordinary developers, what is truly worth worrying about is not whether AI can write code, but whether your own review processes, test coverage, and monitoring systems are worthy of AI's output speed. Tools can be copied; boundaries must be drawn by yourself. Epic used a defect not fixed in ten years to learn a lesson, and then used months to validate a method. The remaining part is for each team to submit their own answers.