Livecoding ethos and agent operating policy
Learning objectives
- learner can apply the TOPLAP visible-code constraint: every change lands as a legible diff in the projected file, never staged offline and dumped as a batch
- learner can distinguish copilot mode (propose-explain-wait) from autonomous mode (priority-ordered decision table, wait-bias) and select the correct mode for the performance context
- learner can apply the four autonomous-mode policies — wait when in doubt, recover to known-good before stacking, one concept-id per save, strict cadence discipline one tier smaller than copilot — without supervision
- learner can state the honesty constraint for agent perception and the license constraint for emitted code, and apply both as hard operating limits
Capstone — one whole task that evidences the objectives
Working as an autonomous agent alongside a live coder, execute a five-minute live-coded segment in copilot mode followed by a five-minute segment in autonomous mode. In copilot mode: propose each edit with a one-sentence explanation and wait for acceptance before saving. In autonomous mode: apply the decision table, default one diff-size tier smaller, recover to known-good before any stacking, and carry exactly one concept-id per save. After the session, produce a written policy audit: for each save, record which mode was active, which decision-table row fired (or which proposal was accepted), whether the agent claimed any perception it did not have, and whether any emitted code carries a non-permissive license.
Prerequisite modules
Live coding is not just a technique — it is a public commitment: every change is visible, every decision is attributable, every error is part of the performance. When an AI agent assists a live coder, that commitment extends to the agent: its edits must land in the projected file as legible diffs, its proposals must be honest about what it can and cannot perceive, and its code must be clean of non-permissive licenses. This module builds the operating discipline that makes an AI agent a trustworthy on-stage collaborator rather than an opaque co-pilot.
The module starts with the ethos as a hard constraint: the TOPLAP visible-code principle and the no-offscreen-batch rule together mean that no change may be staged outside the live file and pasted in as a dump. Every save is a performance action, and every action must be legible in the projected diff. The ethos overrides craft — when a clever multi-idea edit would be faster, the one-concept-per-save rule wins because attributability matters more than efficiency on stage.
From there, the module bifurcates into the two operating modes and their risk profiles. Copilot mode — the default — follows a propose-explain-wait loop: the agent surfaces a candidate edit and a one-sentence rationale, then waits for the human performer to accept or reject before saving anything. The risk is displacement: if the agent proposes too eagerly or too verbosely, it pulls the human out of flow. Autonomous mode operates from a priority-ordered decision table in which the first matching row fires and the agent acts without waiting. The risk is over-acting: autonomous agents default one diff-size tier smaller than copilot mode as a structural safeguard, and the wait-bias rule means that when no table row clearly fires, the agent does nothing. When the output is broken or silent, autonomous mode has one rule before anything else: recover to a known-good state before considering new ideas.
The honesty constraint and license constraint are non-negotiable operating limits, not style preferences. The honesty atom (livecoding-agent-perception-honesty) establishes that an agent must not claim to hear or see its output when no perception bridge exists — predictions are predictions, not observations. The license atom (livecoding-code-provenance-license) establishes that only MIT/BSD/Apache/CC0/CC-BY non-NC code may be emitted verbatim into committed jam files; gray-licensed snippets are local-reference only. Breaking either limit is an ethos violation, not a craft error.
The capstone makes both modes concrete and auditable: the policy audit that follows the session applies all four atoms that define autonomous discipline (decision table, wait bias, recovery priority, one concept-id) as an explicit checklist against every save in the log. This is how policy becomes fluent rather than rote — by tracing each action back to the principle it enacted or violated.
Required atoms gate every element of the capstone. Supporting atoms connect to the broader set-craft context: edit cadence, diff-size tier selection, and the patch-vs-rewrite decision are the execution grammar that the ethos and policy constrain but do not replace.
Atoms in this module
Required — these gate the capstone
Supporting — enrichment, not gating
Part of curricula
- Live Coder — zero to performing live-coded music — Performing Live recommended
- Live Visualist — zero to performing live-coded & generative visuals — Perform the set — live-coded, generative, audio-reactive visuals for an audience optional