Code that moves: notes from the intersection of AI, perception and light

I danced competitively for two years, and I draw. This is not a footnote to my engineering — it's the reason for how I build.

What dance teaches you is that an audience doesn't parse a performance; it feels weight, timing, hesitation. When I started building visual work in code — Three.js compositions, sketches for light-driven installations — I recognized the same grammar. A transition that's 80 milliseconds too slow reads as doubt. Light that breathes at the right rhythm reads as alive.

AI is now entering that grammar, and I find the possibilities more interesting than the discourse. Generative systems are very good at producing endless variation, and mostly bad at intention — at weight and gesture. That gap is exactly where designers and engineers who understand embodiment get to work. The studios I admire — the ones composing light, sound and architecture into single scores — are essentially choreographing perception, and code is just their notation system.

So my lab work sits deliberately in that gap: micro-interactions that behave like gestures rather than transitions, 3D experiments where a model's output is a raw material to be composed — never the final product. And one question underneath all of it: what does it mean for software to move well? I don't have a full answer. That's why it's a practice.