the honest answer to "how do you use ai to build interfaces and scenes" is: not by writing a big spec and getting back a finished thing. that path produces something confident and wrong. what actually works is a loop so tight it barely has steps.
the loop
- drop one asset. a piece of art, a layer, a single element. not the plan — one thing.
- "integrate it." the ai wires that one thing into what already exists.
- edit per-layer. nudge this element. not "redo the scene" — "this one, here."
- show. look at the actual rendered result, not a description of it.
- adjust. terse and directional — "more orange," "up 50px," "smug not surprised" — and back to 3.
the design isn't decided up front and executed. it emerges from the loop. the result card in one build went center → side → center again without anyone deciding that in advance — each move was obvious only once the previous one was on screen.
╭──────────────────────────╮ │ scene │░ ├──────────────────────────┤░ │ ▣ layer 3 + new art │░ ◂ edit one │ ▣ layer 2 ~ moved │░ │ ▣ layer 1 · base │░ ╰──────────────────────────╯░ ░░░░░░░░░░░░░░░░░░░░░░░░░░░░ small diff · always shippable
where it broke
two gotchas with teeth.
the first: the localStorage-overrides-the-file trap. the scene editor saved positions to localStorage so tweaks felt instant. but that meant the saved state silently overrode the source file. so you'd change the file, reload, and your change wouldn't appear — the stale localStorage value won. this burned several round-trips of "i changed it, it's not showing." the lesson: when a change doesn't land, suspect a caching or override layer before you suspect the change. the fix was to route edits through properties the override didn't write, or to promote anything structural out of the override layer and bake it into the source as a real, first-class thing.
the second: the lost-work scare. a verification step once wrote to persisted state on a page that was being actively edited — technically harmless, fully isolated. it coincided with a "my work got deleted" moment and read as the tool destroying the work. the actual damage was zero; the damage to trust was not. the rule that came out of it: never verify by writing to live state on something the person is actively working in. verify read-only. check the syntax, load it without touching anything. lost work — even the fear of it — is not a small bug. it's the whole relationship.
he positions, i build
the human drags elements around in a live editor where feedback is instant — that's the fast, intuitive, eyeball-driven part, and a human is just better at it. the ai takes the logic, the animation, the styling, the new art — the parts that are slow to hand-tune and fast to specify. don't make the ai guess pixel positions; don't make the human hand-write tween code. play to each side's fast path.
and per-layer edits beat one big prompt for a concrete reason: a big prompt forces the ai to regenerate everything, including the 90% that was already right, and it'll quietly "improve" things you didn't ask it to touch. a per-layer edit is a small, legible, revertable diff. one line per change. you can see exactly what moved.
accretion is just version control for the design itself — small commits, always shippable, never a big-bang rewrite you can't unwind.
the point
when the medium is visual, accretion beats spec-it-all-upfront. not as a style preference — for a structural reason: you cannot accurately specify what you haven't seen yet. the spec is a guess about a visual result, and visual results surprise you. every "drop one thing → look → adjust" cycle replaces a guess with an observation. the up-front spec front-loads all the guessing into the moment you know the least.
the one carve-out: confirm the shape before a from-scratch rebuild. small tweak? just do it and show me. but if you're about to rebuild a whole component a different way, check the structure first — guessing the architecture wastes a full rebuild, and that's the one place the fast loop is too expensive to run on a wrong guess.