Claude Code for 3D Modeling: What Actually Transfers
A terminal coding agent that builds 3D locations: how the connection works, the prompt that holds up, the verification loop, and where it fails.
Claude Code is a terminal agent built for codebases: it reads files, plans, edits, runs the tests, reads the failures and goes back in. Connect it to a 3D editor over MCP and something mildly surprising happens — it is good at it. Not because it understands architecture, but because building a location has the same shape as a large refactor: hundreds of small tool calls, each one checkable, most of them boring.
What a coding agent already knows how to do
The useful part of a coding agent is not its knowledge of JavaScript. It is the loop: gather state, choose an action, call a tool, read the result, notice the mismatch, correct. Anthropic describes Claude Code in exactly those terms — the model acts, observes, decides, repeats, sometimes for hundreds of iterations. Everything else is a tool schema.
A location is a long tool-driven task
Watch a person block out a village and you see the same loop. Draw the road. Stand in it. Notice it is too wide. Narrow it. Cut plots off it. Place a house. Check it faces the right way. Repeat thirty times.
A thirty-building village is a few hundred tool calls, and almost none of them are interesting. That is the profile a coding agent suits unusually well: long, structured, verifiable, dull. It does not get bored on building nineteen and it does not start rounding coordinates at building twenty-four. Only the tool names change. Instead of "read this file" it is "list what is in this region"; instead of "run the tests" it is "give me the bounding box of what you just placed".
What does not transfer
- Taste. It will not tell you the square is dead, the roofline is monotonous, or that the village reads as a row of houses rather than a place someone lives. It acts on those judgements the moment you make one, and volunteers none.
- Spatial intuition without feedback. Reasoning about a 40 by 60 metre plot from coordinates is dead reckoning. The arithmetic is reliable; "does that gap read as a street" is not a question numbers answer.
- Anything it cannot observe. A chimney sunk into a roof, a lamp post inside a tree canopy, two coplanar walls fighting over the same pixels — if no tool reports it, it does not exist for the agent. You are the sensor for everything the tools do not measure, which is why you keep the viewport in front of you.
- Knowing when it is finished. The standard failure of autonomous loops is premature confidence: the agent that made the thing is biased towards accepting it. It reports the village complete while two roads end in mid-air.
Getting Claude Code connected to the editor
The connection is the least interesting part, which is how it should be. Cuberta exposes a Model Context Protocol server from inside the editor. Press Copy connect command in the app, paste it into a terminal, and the agent has the editor's tools. Inside a Claude Code session, /mcp lists the servers it sees and their status; if the editor is there and connected, setup is over.
Claude Code is the common starting point because it is a terminal, not because it is required — any MCP client drives the same tools, and MCP servers for 3D and game dev covers the protocol side properly.
The first prompt
The first prompt sets the shape of everything after it, and the two failure modes are not the ones people expect. Too vague is one. Too atmospheric is the other, and it is far more common.
A prompt that wastes ten minutes
Build a beautiful abandoned fishing village. Really atmospheric, kind of haunting. Make it detailed and realistic, add lots of nice touches, take your time, I want it to look amazing.
Every clause is a mood and none of it is checkable. The agent will build something, because it always builds something, and when you dislike the result there is no sentence to point at. "Detailed" gave it permission to place four hundred objects. "Take your time" removed the stopping condition. "Atmospheric" it cannot see, so it approximates with fog and dead trees — what the word means statistically, not what you meant.
A prompt that gives you something to correct
A fishing village of about 30 buildings on flat ground. Work in passes and stop between them. Pass 1: one road along the shoreline, roughly 400 m, plus two short inland roads ending in dead ends. Pass 2: plots off those roads, none crossing the shoreline. Pass 3: single-storey timber houses, 6 to 8 m of frontage, pitched roofs, each facing the road its plot is on. Pass 4: a stone quay at the south end with three jetties, then fences and boats. Pass 5: late afternoon light, sun low from the west. Do not build inside the region I marked. After each pass, report what you created, how many, and the bounding box.
Length is not the point. Counts, dimensions, road topology, an ordering, an exclusion, a read-back and a stopping rule — every clause is either a number or an instruction about process. When something comes out wrong you can name the clause that was ignored, which is a two-line correction instead of a rewrite. The principle that scenes reward structure where single objects reward adjectives is worked through in text to 3D scene generation.
The verification loop is the whole trick
An agent that fires and forgets emits its plan as one burst of tool calls and never looks at the result. It is fast, and it is why people conclude that AI cannot build levels. The failure is not that a single call is wrong; it is that errors compound downstream. If the shoreline road comes out 40 m longer than planned, every plot cut from it is off, every house on those plots is off, and the quay lands in the water.
An agent that reads the scene back after each action catches that at the road, before anything inherits it. Same discipline as running the tests between edits rather than at the end, same cost — extra round trips, extra tokens, a slower run. Worth it for the same reason.
You get it by asking for it. Put the read-back in the prompt and it becomes the habit of the session. Better, write it once into CLAUDE.md, the project file Claude Code loads at the start of every session, alongside the conventions you are tired of repeating: floor height, road width, the material palette, and the rule that no pass begins before the previous one is confirmed.
Working in passes
Do not ask for the village. Ask for the road network, look at it, then ask for the plots. Each pass is the input to the next, so the earlier a pass sits, the more expensive its mistakes are.
| Pass | What it decides | Check before moving on |
|---|---|---|
| Roads | the skeleton every later pass inherits | junctions meet; total length matches the plan |
| Plots | what is buildable and what is not | nothing straddles a road or sits outside the site |
| Buildings | mass, silhouette, frontage | one floor-height convention; facades face their road |
| Dressing | pavements, lamps, trees, fences, signage | nothing intersecting or floating; spacing regular |
| Light | time of day, sun angle, sky | shadows agree; nothing important left in the dark |
Passes also solve the context problem. A long build fills the model's context window with tool results — every read-back you asked for is text it now carries. /context shows what is occupying the window; /compact summarises the conversation to free space. Between passes is the safe moment for either, because the scene lives in the editor rather than the transcript, and the transcript is the disposable half.
When it goes wrong
Mark the ground instead of arguing
When the agent keeps putting a house where the plaza should be, the fix is not a third rewording. In Cuberta you can mark where to build and where not to before saying anything, and a no-build region is a constraint rather than a request. Thirty seconds of dragging a boundary beats three rounds of "no, not there".
Undo the step, not the session
The instinct after a bad pass is to clear the scene and start over with a better prompt. That throws away four correct passes to fix the fifth, and the new run makes different mistakes rather than fewer. Undo the last step, say in one sentence what was wrong — "the houses face the water, they should face the road their plot is on" — and have it redo that pass only. Restart the conversation when context runs out; almost never restart the scene.
When it says it is finished
Ask for numbers, not a summary. How many buildings. What are the overall bounds. How many sit more than 5 m from a road centreline. Are there objects below ground. An agent that actually checked answers from the scene in two tool calls; one that is guessing produces a confident paragraph with no numbers in it, and that is the tell.
Cost, time, and what it does not replace
Time is minutes, not seconds — and not the afternoon a manual blockout takes. Expect to spend those minutes steering rather than walking away, since supervision is what makes the output usable.
Tokens are the real price. Every tool call costs them in both directions, and the verification defended above is the expensive half, because a read-back only helps if the result returns to the model's context. The editor's tool definitions occupy part of that window before you type anything. None of it is hidden: Cuberta is free and its bundled content works offline, but you bring your own model access, so the token bill is yours and /context shows the window filling.
The honest limit is the last one. This does not replace a level designer; it replaces the first two days of one — the blockout, the three hundred placements nobody wants to do by hand, the pass where lamps go every 25 m down both sides of a street. What it does not replace is the judgement about what the place is for: where the eye should land, which street should feel narrower than it needs to be, what ought to be missing. A designer with an agent reaches the version worth criticising in an hour instead of a week. Without one you get a village that is technically correct and has nothing to say.
That is a fair summary of the transfer. Claude Code brings patience, a willingness to make four hundred small correct decisions, and the habit of checking its own work. It does not bring an opinion. That part is still the job.
