Most debates about live coding collapse into one question: how fast is the feedback? But Joshua Horowitz's breakdown argues there are several independent dimensions worth caring about — and conflating them is why we keep talking past each other. Latency is just one axis. The others matter just as much, sometimes more.
Two dimensions that stuck with me: coverage (what percentage of your program's behavior does the feedback actually show you?) and locality (how close is the feedback to the code that caused it?). A tool can have near-zero latency but terrible coverage — you see output instantly, but only for one happy path. That's not great live feedback, it just feels fast.
There's also the question of whether feedback is continuous or triggered. Most REPLs are triggered — you ask, they answer. True live environments like Hazel or certain Bret Victor demos push toward continuous. The difference sounds philosophical but it changes how you think while coding. Continuous feedback lets you treat the environment like a scratchpad; triggered feedback keeps you in a request-response mindset.
What I find useful here is that this framework gives you a vocabulary to evaluate tools without getting sucked into vibes. Next time someone says "just use a REPL" or "hot reload is enough," you can ask: what's the coverage? What's the locality? Is it really live, or just fast?
If you build dev tools or think about programming environments, this is the kind of precise framing that actually moves the conversation forward — bookmark it.
