I Asked AI to Build a Unity Scene Manager. Here Are 3 Reasons It Failed.

If you've ever typed "Unity additive scene manager" into an AI prompt, you've probably gotten back something that looks like it works. I did too. I asked an AI coding assistant to build an advanced additive scene management system for Unity. The code compiled. The structure made sense. But three fundamental problems made it dead on arrival in any real project.

Here's what went wrong and why your project needs more than an AI prompt.

1. The Manager and Reality Drifted Apart.

The problem

The AI built the system around additive loading. Load a scene, add it to a list. Unload a scene, remove it from the list. The list always matches what Unity has in memory. Simple.

But someone also asked for a single mode loader. And the AI added it. A small method that calls LoadSceneMode.Single, which tells Unity to destroy everything and start fresh.

public Task<bool> LoadSceneSingle(string sceneName)
{
    var request = new LoadSceneRequest(sceneName, LoadSceneMode.Single, priority, true);
    _loadQueue.Enqueue(request);
    return request.CompletionSource.Task;
}

The problem? The internal list was never told about this. When single mode runs, Unity destroys every scene. The list still holds all the old scene names. The manager now believes scenes are loaded when they are not.

From that point on, every decision is based on wrong information. The manager skips loading scenes it thinks already exist. It tries to unload scenes that are already gone. It reports wrong scene counts. The list and reality never sync back up.

The AI added a feature without updating the feature that tracks it. Two systems that disagree. And no one notices until the game starts behaving unpredictably.

What ASM does instead

Advanced Scene Manager is additive only. Always. There is no single mode to accidentally mix in. Every scene loads on top of what is already there. The internal state never drifts because there is no mode that bypasses it. The design is consistent from day one.

2. async Task. The WebGL Trap Door.

The problem

The AI wrote the loading logic using C# async Task:

public async Task<bool> LoadSceneAdditive(string sceneName)
{
    var operation = SceneManager.LoadSceneAsync(sceneName, LoadSceneMode.Additive);

    while (!operation.isDone)
        await Task.Yield();

    _loadedScenes.Add(sceneName);
    return true;
}

This pattern works beautifully on Windows, Mac, Linux, consoles, and mobile. It's modern C#. It's clean. It's readable.

Unity WebGL uses a single-threaded JavaScript execution model. There is no thread pool. There is no Task scheduler. async/await on WebGL falls back to the Unity player loop. But Task.Yield() and any operation that depends on multi-threading can deadlock, hang, or simply never complete.

That await Task.Yield() loop? On WebGL, it can lock the entire application. Your loading screen freezes. The scene never finishes loading. Users refresh the page. You lose players.

And because this works perfectly in the Editor and on desktop platforms, most developers don't discover it until they run their first WebGL build. By then, the entire loading system needs rewriting.

What ASM does instead

Advanced Scene Manager currently uses a mix of coroutines and awaitable patterns. The long term direction is to fully commit to awaitable, because it is the modern recommended approach in Unity. But the key difference is that ASM's awaitable implementation does not rely on raw Task.Yield() or anything that assumes a thread pool exists. It is built on AsyncOperation and yields correctly within Unity's single-threaded player loop. That means it works on WebGL today, not just on desktop platforms.

Platform portability isn't a feature request. It's a requirement.

3. Every Scene Is Equal. Until One Breaks Everything.

The problem

The AI tracks which scenes are loaded in a HashSet. Loading adds to it. Unloading removes from it. Simple.

private readonly HashSet<string> _loadedScenes = new();

public async Task UnloadAllAdditiveScenes()
{
    var scenesToUnload = _loadedScenes.ToList();
    var tasks = scenesToUnload.Select(UnloadScene);
    await Task.WhenAll(tasks);
}

Looks clean. But there is no concept of a persistent scene. No way to say "this scene should never be unloaded." Every scene is treated the same.

In a real project, you have core scenes that must always be present. Your UI canvas. Your audio manager. Your input system. Your netcode root. If any of those get unloaded by accident, the game breaks. Menus disappear. Sound stops. The player disconnects.

The AI does not know which scenes are core and which are content. It unloads everything you tell it to unload. One wrong call to UnloadSceneGroup or UnloadAllAdditiveScenes and your entire game falls apart.

What ASM does instead

Advanced Scene Manager has a built-in concept of persistent scenes. You mark scenes as persistent and they survive any unload operation. You can unload a group, unload all additive scenes, or reload the entire setup. Core scenes stay exactly where they are.

A scene manager needs to know what matters. If it treats everything as disposable, it is not ready for a real project.

Why AI Won't Replace a Proper Scene Manager

AI is great at generating code that compiles. It's terrible at generating code that survives cross-platform constraints, production edge cases, and long-term maintenance.

The three problems above aren't bugs in the AI's logic. They're architectural blind spots that only experience and platform-specific knowledge can catch. Scene management touches every part of your game. It's the foundation. And foundations need to be built by people (and tools) who know what can go wrong.

The Advanced Scene Manager didn't get to version 3 by accident. It got there because each of these problems was discovered, solved, and stress-tested across real Unity projects.

Want to see how a production-ready scene manager handles additive workflows, WebGL builds, and persistent core scenes? Check out Advanced Scene Manager 3.