Livecoding requires changes to happen live in the running file, not staged offline and dumped in as a batch

The TOPLAP/LLM debate warns that LLMs risk a ‘regression to mainframe batch processing’: delayed offscreen results that conflict with live coding’s need for speed and brevity. This rig’s constraint is that changes happen live, in real time, in the running file — the rig supports exactly this with gapless hot-swap. Staging large compositions offline and dumping them in, or introducing latency that breaks the improvisational loop, violates liveness. Edits must be small enough to reason about at performance speed.

Examples

Writing a complete 200-line Tidal set offline and pasting it in at performance time is batch processing. Writing one .every(4, ...) transform live and evaluating it immediately is liveness.

Assessment

Explain the distinction between live in-file editing and offscreen batch generation in the context of livecoding performance, and state why the latter is considered a regression.