codex builds the editor: walls, doors, windows

First slice of the actual editor — the 2D surface where rooms get drawn. Built with Codex (GPT-5.5) only. Claude’s run on the same surface comes later.

This time I changed the prompting style. Instead of “build login page” or “build dashboard” as one-shot briefs, I gave Codex full autonomy: pick the sequence, pick the depth, ship in increments. It would build something small, ask me to verify, then move to the next slice. The trade-off was visible immediately — same component, multiple round-trips.

What got built:

Three components, all working: walls, doors, windows. All draggable. All resizable. The basic editor primitives are in.

Where it stumbled:

Wall placement specifically. The intent is canonical — first click sets the start point, second click sets the end point, segment renders. Codex failed this five or six times in a row before it landed. Different failure modes each pass: sometimes the second click did nothing, sometimes both clicks collapsed into one point, sometimes the segment rendered but with wrong coordinates. Eventually it converged.

Drag and resize had similar arcs — initial implementations missing, added in follow-up prompts.

What I noticed:

The project bible says “home design app for non-designers.” That framing was apparently not enough context to derive obvious interaction details — that walls are placed with two clicks, that placed elements should be movable, that resize handles are standard. Each of these had to be prompted explicitly.

I’d assumed a model with strong design priors would infer the basics from domain framing alone. It didn’t. The bible sets the what; the how of every interaction still needs to be spelled out.

Open question:

Whether Claude shows the same pattern on this surface, or whether the divergence we saw on login and dashboard extends here too. Running that next.