From zero to a chat-made spinning cube

The north star: why "a spinning cube"

Everything this day aimed at one acceptance point: on a clean machine, clone, drop in a key, run one command, then tell the agent in the interface "make a spinning cube" — it edits code, the engine hot-reloads, and a turning cube appears in the browser at once. The cube itself is unremarkable, but it's the minimal proof of the product's core bet — "you can build something genuinely runnable just by talking" — and if any link in that chain breaks, the platform doesn't hold. Collapsing the goal into one unambiguous acceptance point a single screenshot can prove means the team isn't "feeling progress" but chasing a hard pass/fail target. This day, it passed.

The end-to-end loop runs: say a sentence, the picture changes

This loop chains six links end to end: you state a requirement in the chat box → the agent writes the corresponding code into the game file → a file watcher notices the change → a real-time channel notifies the front end → the engine dynamically loads the new code → the picture updates instantly. This day connected those six links completely and stably for the first time, and an automated browser screenshot actually captured the cube mid-rotation at a tilt, with no errors the whole way except one harmless missing-icon notice. That means "what you see is what you get" is no longer a line in a vision deck but a real, repeatably-triggered pipeline. Every later experience of "build while chatting and see the result immediately" rests on this loop; with it working, the product truly came alive once.

The three layers land: clear roles, replaceable

To make this loop stand the long haul, the system was sliced into parts with clear, independently-replaceable responsibilities: a runtime kernel that actually drives the agent's thinking and acting (handling model calls, tools, sessions, memory); a pure orchestration-and-interface bridge (broadcasting file changes to the front end, never touching the large model itself); an engine (rendering game code into a picture); plus the three-column interface the user faces. This split was written into an internal interface contract and set as an iron rule not to be relitigated lightly — the kernel is the kernel, orchestration is orchestration, boundaries stay unambiguous. Its value: each layer can evolve and be swapped on its own, a problem in one layer doesn't drag down the whole, and "swap the engine, swap the interface" becomes possible later rather than a rewrite.

Replacing the "placeholder shell" with a real agent runtime

In the pre-dawn version of the loop, what drove the agent was still a temporary placeholder shell; this day, in some thirty-plus steps, it was replaced with a real "professional coding-assistant-class" agent runtime. This kernel has what a real agent needs: it can call the large model, use tools, maintain sessions and memory, and drive itself forward in a "think–act" loop. After the swap, the system received genuine model replies for the first time and ran a full "real model + real tools" loop. This step pushed the product from "looks like it can chat" to "can actually do the work" — earlier conversations were a performance; now behind them is an engine that can read, write and use tools to genuinely change your project.

Don't reinvent: reuse standards instead of copying thousands of lines

While filling in agent capability, two pieces could have been done by "copying a thousand lines from elsewhere": the protocol layer that brings tool capability in, and a standard conversation-event protocol. This day's judgment was clear — wherever a mature open standard already exists and can be installed and used directly, don't re-copy it by hand. So both were replaced with official standard implementations of the earlier hand-written versions: the tool-protocol code shrank from a hundred-odd lines to eighty and got more complete transports and capability-change notifications for free; the conversation-event protocol pulled in a standard library and re-exported thirty-plus standard events with almost no new code. Together the two steps added under two hundred net lines yet delivered enterprise-grade capability. Behind it is a discipline that recurs: spend effort on the hard problems no one solved for you, not on reinventing wheels already sitting in public standards.

Hundreds of chat-UI passes: from raw text to near desktop-grade

Once the loop truly worked, the interface's experience gaps became the sorest spot. This day, in tiny steps over a hundred iterations, polished the chat panel from "raw text and placeholder boxes" to something near a mature desktop assistant. It includes a whole hand-written Markdown renderer (code blocks, lists, tables, task lists all supported), a character-by-character streaming animation whose speed adapts to content length, tool calls condensed into a high-density "pill" tag that expands to the full result, the agent's "self-correction/reflection" set off visually, contrast between bubbles and background tuned to meet accessibility standards, and looping animations turned off for users who prefer reduced motion. Each pass touched one thing, self-tested, and logged a note. The point is plain: however strong the capability, if it reads laboriously or looks cheap users won't trust it; polishing the surface you stare at most into something pleasant is itself part of the core feature.

A flat restructure + zero-build, run-from-source dev

In the afternoon came a structural flattening: the once deeply-nested directories were laid flat so the parts sit side by side in a more direct way. Alongside it, a "zero-build" dev mode was established: after cloning, one command runs the source directly, with no long compile-and-bundle step first. For developers, that means changing a line and seeing the result in the browser almost immediately, stepping iteration speed up a level; for newcomers, the road "from clone to seeing the picture" is squeezed to its shortest. The structural simplification is intangible, yet it decides whether the coming weeks can keep a "a big step a day" cadence — the simpler and clearer the foundation, the faster and steadier you build on top.

The three-column Studio takes shape: files, preview, console, switchers

In the evening the three-column Studio was laid out, with a batch of genuinely usable panels at once: the files tree on the left wired to real project files, click a product to preview it; a live preview window in the center connected straight to the engine, with a frame-rate readout, pause, reload, fullscreen and desktop/mobile device modes; plus a panel that pipes in the engine's console output, a switcher that lists and replays past sessions, and entries to switch projects and games with a "new" menu. Notably, this day also followed an instinct and merged the two concepts "project" and "game" into one — the user said they were the same thing, so the interface shouldn't force them apart. With that, the "manage-left / preview-center / chat-right" layout settled, and the Studio began converging from a pile of capabilities into a usable product form.

What this day means

Seen together, the weight of this day is this: it wasn't a single feature shipping, but the product's core thesis being proven end to end for the first time. From a sentence to a moving cube, every link in between — rendering, runtime, orchestration, interface — genuinely ran, on a clean machine, evidenced by a screenshot. Everything complex after the cube — real games, complex scenes, a whole agent team — grows on this already-connected trunk. That's exactly why this day is worth recording as a model: connect the most critical, most falsifiable main chain first, then talk about the branches; running once is what gives you the confidence for the second time, and the hundredth.