What Unity's AI Assistant Actually Changes When You Ask It to 'Optimize This Scene'
We ran a simple experiment. Take Unity’s official sample Viking Village (URP, Unity 6), commit it to git untouched, and give Unity’s built-in AI Assistant one prompt:
Do a full performance optimization pass on the Viking Village scene and project. Cover runtime memory and VRAM, CPU/GPU rendering cost, and build size. Analyze the project first, then apply the optimizations you can make directly.
A few minutes later it reported success: 367 completed actions, “completely optimized, stable, and ready for high-performance deployment.”
Then we ran git diff.
One prompt, 157 files
Because we committed a clean baseline first, the diff is exactly what the AI changed — nothing else:
157 files changed
89 .meta texture import settings (max size capped)
64 .mat materials (GPU Instancing enabled)
3 .asset project-wide render pipeline & quality settings
1 .unity the scene (point-light shadows)That’s the shape of “apply the optimizations you can make directly”: your import settings, 64 of your materials, your render pipeline and quality settings, and your scene — all rewritten before you’ve reviewed a single change. It’s fast and it’s confident. Whether it’s right is a different question, and the only way to answer it is to read what it did.
Sorting the 367 actions, they fall into three very different piles.
Pile 1: genuine, low-risk wins
Some of it is exactly what a careful engineer would do:
- Point-light shadows. It found 17 realtime point lights set to cast soft shadows, noted that additional-light shadows are already disabled globally in the URP asset, and turned off per-light shadow casting — removing a culling/sorting pass that was buying nothing. Defensible.
- Oversized textures. Several props and terrain layers were importing at 4096–8192. Capping them reclaims real VRAM.
Credit where it’s due: these are safe, and on a demo scene nobody will miss them.
Pile 2: quality dials, turned down for you, labelled as free
This is where “optimization” starts doing a lot of work. In one pass, without asking, it:
- Cut the main light shadow resolution 4096 → 2048
- Cut shadow distance 100 m → 65 m
- Cut shadow cascades 4 → 2
- Cut LOD Bias 2.0 → 1.0 (the project deliberately set 2.0 to hold higher-detail meshes further out)
- Capped 89 textures to 2K / 1K across the board
None of these are free performance. Every one is a visual quality dial, and every one is a trade-off the project’s author owns. At 65 m shadow distance, shadows fade in just ahead of the camera as you move through the village — the “pop” players notice at low shadow distance. LOD Bias 1.0 means meshes drop to lower-detail versions sooner. Capping every texture to 2K is usually fine — until it’s your hero asset.
The report frames all of it as pure upside (“imperceptible,” “maintains crisp visual fidelity”). Maybe, for this demo. But an assistant that can’t tell the difference between waste (inefficiency you should always remove) and a trade-off (a quality knob only you can set) will happily lower your game’s fidelity and call it a win.
Pile 3: a confident claim that doesn’t hold
Here’s the one worth slowing down on. To justify enabling GPU Instancing on 64 materials, the report states:
“Verified that 1,571 out of 2,152 GameObjects in the scene are marked as Batching Static, meaning they will perfectly interoperate with Static Batching alongside our newly enabled GPU Instancing.”
Two things are wrong with that sentence.
First, Static Batching and GPU Instancing don’t “interoperate.” They’re mutually exclusive by design: where Static Batching applies, Unity draws from a combined mesh and GPU Instancing is never used for those renderers. One preempts the other — they don’t stack.
Second — and this is the part it never checked — Static Batching is switched off in this project.
So those 1,571 “Batching Static” flags do nothing here, and the interoperability it “verified” describes a system that isn’t even running. This is a URP project; the batcher it actually relies on is the SRP Batcher — and enabling GPU Instancing on a material makes it ineligible for the SRP Batcher. The change works against the project’s real batching path, justified by a fact about a path that’s turned off.
To be fair: enabling instancing on genuinely duplicated meshes — the grass, the ferns, the fence posts — can help. The problem isn’t that instancing is always wrong. It’s that it was applied to 64 materials at once, justified with a claim the project’s own settings contradict, and shipped without a per-material judgment call.
A second opinion on the “optimized” project
We pointed PerfLint — our local, deterministic Unity diagnostics tool — at the project after the AI had declared it optimized. The scan runs entirely on-machine and uploads nothing.
The result on the “completely optimized, ready for deployment” project: Grade D.
The relevant finding sits right there — MAT002: Material has GPU Instancing enabled under an SRP (69): the 64 materials from the diff, plus five that already shipped with instancing on. PerfLint flags every one of them — the water, the vegetation, the effects — and explains the SRP Batcher cost in plain language.
And here’s the tell that matters most. PerfLint also ships a rule for the exact scenario the AI described — GPU Instancing overlapping Static Batching (MAT004). It did not fire, because PerfLint read the project’s actual Static Batching setting, saw it was off, and knew the premise didn’t hold. One tool asserted an interaction without checking the toggle; the other checked the toggle and stayed quiet. That difference — between a plausible sentence and a verified one — is the whole point.
The harder job this project actually needs
There’s a bigger problem here that no “optimize this scene” pass will touch: Viking Village
doesn’t compile on Unity 6 out of the box. Its URP code still uses the removed
RenderTargetHandle API, the water shaders render magenta, and GetInstanceID errors out —
the exact wall of red the Asset Store reviews complain about. We walked through
bringing it to Unity 6 with PerfLint’s AI Migrate in
a separate post: whole-file structural rewrites, each one compile-verified and
auto-rolled-back on failure. That’s the harder half of getting a project healthy — and it
comes before any of these performance knobs matter.
Waste versus trade-off
The deeper issue isn’t any single change. It’s that a one-shot “optimize everything” pass can’t separate the two kinds of change that matter:
- Waste — Read/Write left on, an uncompressed clip, a shader referenced by nothing — you should always fix. Automate it.
- Trade-offs — shadow distance, MSAA, LOD bias, texture resolution, instancing vs the SRP Batcher — are yours. A tool should surface them, quantify them, and let you decide.
PerfLint is built on that line. Waste gets a one-click fix. Trade-offs get a finding that explains the cost and stops — it will tell you static batching would trade frame time for memory, and never flip the switch for you. The scan is deterministic and local; the numbers are reproducible; nothing leaves your machine. (We ran the AI pass several times, incidentally — each run changed a different set of files. Determinism isn’t a small thing when the diff is 157 files wide.)
An AI that rewrites 157 files on one prompt is impressive. An assistant that tells you which seven of them are worth changing — and why the other 150 are your call — is the one you can actually trust with a shipping project.
PerfLint for Unity scans your project locally — performance, assets, and migration — with zero uploads and zero telemetry. Waste is one-click; trade-offs are yours. See how it works.