When Code Needs a Human Signature: Evaluating Asciinema Recordings as Proof of Authorship

Thesis

When a maintainer receives a patch from an unknown contributor, the question of who actually wrote the code has become increasingly salient. Large language models (LLMs) can now produce syntactically correct, stylistically consistent patches with minimal prompting, blurring the line between human and machine authorship. One pragmatic response is to ask contributors to submit a terminal session recording—most commonly generated with the lightweight CLI tool asciinema—as a form of "human proof." The core argument of this piece is that while such recordings capture a genuine slice of the author’s workflow, they are neither a fool‑proof gate nor a universally acceptable solution; rather, they constitute a partial safeguard that must be weighed against privacy, accessibility, and the inevitable arms race with ever‑more capable LLMs.

Key Arguments

1. The recording captures the process rather than the product

A traditional code review evaluates the final diff. An asciinema file, by contrast, preserves the sequence of keystrokes, cursor movements, and terminal output that led to that diff. This includes the inevitable mis‑typed characters, backspaces, and exploratory git grep commands that betray a human’s iterative reasoning. In practice, a typical 5‑minute editing session for a modest patch may result in a compressed .cast file of only a few hundred kilobytes, making storage and transmission inexpensive.

2. Low friction for terminal‑centric developers

The barrier to adoption is modest: a contributor simply runs asciinema rec patch.cast, performs the edit in a terminal editor (vim, nano, emacs in terminal mode), and stops the recording. No additional software, screen‑capture permissions, or heavyweight video pipelines are required. This simplicity is a decisive advantage over full‑desktop screen recording, which would demand more CPU, generate larger files, and raise platform‑specific compatibility issues.

3. Privacy and selective disclosure

A recording inevitably reveals more than the final patch: search history, personal configuration files, or even incidental personal messages typed in the same terminal. To mitigate exposure, contributors could encrypt the .cast file and share it only with trusted reviewers via a private email or a repository‑restricted issue. The community would need to establish clear policies about what constitutes acceptable redaction and how long the recordings are retained.

4. The asymmetry of training data

LLMs excel because they have been trained on massive corpora of source code and natural‑language explanations. The corpus of human editing sessions—especially those involving mistakes, pauses, and back‑and‑forth debugging—is orders of magnitude smaller. Consequently, generating a convincing asciinema stream that mimics a specific developer’s idiosyncrasies remains a non‑trivial challenge for current models. Early experiments, such as prompting GPT‑4 to emit a plausible keystroke log, typically produce overly smooth, error‑free sequences that betray their synthetic origin.

5. The inevitability of an arms race

Even if today’s LLMs struggle to fabricate realistic terminal sessions, the incentive to improve will be strong. Future models could be fine‑tuned on publicly available asciinema archives, learning typical pause lengths, typo frequencies, and command‑line ergonomics. Once a model can synthesize a plausible session, the recording loses its evidentiary value, and the community would need to evolve the proof mechanism—perhaps by integrating hardware‑based attestation or cryptographic timestamps.

6. Accessibility concerns

Requiring a terminal‑only workflow excludes contributors who prefer graphical IDEs (VS Code, JetBrains, etc.) or who operate on platforms where installing asciinema is cumbersome. Mandating a specific tool could inadvertently narrow the pool of contributors, counter to the inclusive ethos of most open‑source projects. A flexible policy might accept alternative provenance mechanisms, such as signed Git commits combined with a short, manually‑recorded terminal snippet.

Implications for Open‑Source Governance

1. Policy Formalization – Projects that adopt this approach must codify the requirement in their contribution guidelines, specifying acceptable recording formats, encryption practices, and retention periods.
2. Tooling Integration – Continuous‑integration pipelines could automatically verify the presence of a matching .cast file, extract timestamps, and optionally replay the session in a sandbox for audit purposes.
3. Community Trust – By providing a transparent, reproducible artifact of the editing process, maintainers may feel less compelled to rely solely on the contributor’s word, reducing friction in reviewing one‑off patches.
4. Educational Side‑Effect – Publicly shared recordings can serve as learning material, exposing newcomers to real‑world debugging tactics and idiomatic command‑line workflows.
5. Data‑Privacy Trade‑offs – Projects must balance the benefit of provenance against the risk that recordings become a new source of sensitive information that could be harvested by malicious actors or, paradoxically, by the very LLMs they aim to deter.

Counter‑Perspectives

• Skepticism about Efficacy – Critics argue that any deterministic proof can be forged given enough computational resources, and that the effort spent on recording and reviewing sessions could be better allocated to improving code‑review practices and automated static analysis.
• Potential for Exclusion – Enforcing a terminal‑only proof may alienate contributors who lack the technical proficiency to use asciinema or who rely on accessibility tools that are incompatible with terminal recording.
• Legal and Ethical Concerns – Recording a developer’s session may inadvertently capture copyrighted material or personal data, raising compliance questions under GDPR or similar regulations.

Conclusion

Asciinema recordings offer a tangible, low‑cost method to demonstrate that a patch emerged from a human’s hands, capturing the messy, iterative nature of real programming. For now, the asymmetry between the abundance of code‑level training data and the scarcity of authentic editing sessions gives the approach a practical edge. Nevertheless, it is not a permanent solution; the very existence of a verification mechanism will spur LLM developers to emulate human keystroke patterns, and privacy considerations will limit universal adoption. Projects that choose to experiment with this method should do so with clear, opt‑in policies, robust encryption practices, and an eye toward evolving the proof‑of‑authorship landscape as the technology matures.

If you are curious to see a concrete example, the author’s own editing session for this article is available as a compressed cast file. Download, decompress, and replay with asciinema play --speed 16 proof.cast to observe the human imperfections that the proposal seeks to preserve.