One Prompt Generates a Hexapod Robot with 18 Joints Solved in Real Time—but the Really Useful Part Is That Red Line

Nyxera posted a video on X: a hexapod robot with 6 legs and 18 joints, all solved by real-time inverse kinematics, actually walking in a simulator. The starting point for generating it was a Claude Code prompt.

What it actually does:

Click a gait, and the legs retime themselves. Tripod lifts 3 legs at once, ripple lifts 2, wave lifts only 1.
Each planted foot pulls a red line out from the body, so you can directly see which legs are bearing weight at each step.
Drag the height slider, and the body rises from 26 cm to 34 cm without interrupting the gait.

The simulator is playable directly at visual-learning.app/hexapod. Use WASD QE to move, X to stop, 123 to switch gaits, space to pause, and drag to rotate the view.

Some commenters asked directly: Is one prompt enough? Who signs off that the robot will walk?

After reading through Elvar's full workflow, you realize the prompt is just the entry point; behind it is a structured set of steps. The skill is called anatomy, it's free, runs in Claude Code, and its core idea in one sentence: turn any problem into a machine you can click on. Not an animation, not a diagram, but an interactive page driven by a real model.

Elvar used it to make an espresso machine. You grind beans, tamp, lock in the portafilter, and pull the lever; in the window you can see the spring pushing water through the coffee grounds, with 9 bar of pressure gradually dropping. Every number comes from the same function model—18 g dose, 36 g yield, 27 seconds, 1.1 bar boiler, milk steamed from 4°C to 62°C. If the gauge on screen doesn't match the model, it's a bug.

A machine consists of six parts:

The machine itself: a recognizable real object, with bolts, gauges, and a drip tray.
Buttons: one step at a time, and only the next step can be clicked. Manual mode waits for you to press; auto mode loops.
Window: cuts into the part that actually does the work, letting you see cause and effect at the same time.
Numbers: gauges, on-screen readings, and small labels, all driven by a small model.
Text: one line of guidance at the top of each step, simple enough for a 7-year-old to understand; sound words drawn on actions—grrrr, tok, psssh.
Big idea: one sentence under the diagram. A spring creates pressure. If you can't say it in one sentence, you've drawn two things and explained neither.

The key steps are very specific: write the model first, then draw. The model is a pure function, and all numbers come from it. Then check readability, check visual style (hand-drawn children's book, deep navy linework, cream paper background, warm gray hard-edged shadows, no blue-purple shadows), and check like a critic—freeze a frame in the middle of each step and read it, count pixel changes frame by frame; slow motion must be continuous and must not skip beats. Elvar mentions the most serious bug he caught: in one frame the lever exploded into a huge black disk. Normal frames changed 900 to 1,400 pixels; that frame changed 95,245 pixels. After fixing it, he scanned all 612 frames to confirm there were no jumps.

After that comes video: add window.seek(t), capture frame-by-frame with headless Chrome, compress with ffmpeg to H.264, 60fps, 36 seconds, 4.5MB. Build more machines in parallel, one agent per machine. Finally deploy to a site and add a slider that lets people break the machine—dose from 9 g to 22 g, and watch whether the espresso flow speeds up or clogs.

Some commenters said the demo is cool, but the red load-bearing lines are the key to debugging. That judgment is right. Many AI-generated interactive demos look lively, but you can't verify whether they're just winging it. The anatomy workflow keeps verification costs very low: write the model first, and mismatched numbers are exposed immediately; screenshot checks at each step catch occlusion and overflow; frame-by-frame pixel checks make slow-motion jumps impossible to hide.

One prompt can generate a walking hexapod robot, but what really makes this useful is those boring-looking verification steps. The more specific the constraints, the more real the result looks.