Source-linked AI summary

Do Not Copy/Paste: Soft Barriers for Copying in AI-Assisted Programming

Iyiola E. Olatunji, Alberick Euraste Djire, Jacques Klein, Tegawendé F. Bissyandé

arXiv:2608.22638v1cs.SEcs.AI

TL;DR

AI coding tools leave the transition from generated code to executable software largely unmanaged. This paper probes output-level soft barriers and finds that copy-paste resistance varies by model and task, while an exploratory pilot suggests a shift toward editing and reconstruction.

  • Problem

    The transfer of generated code from chat into software is an unmanaged boundary, despite assistants commonly being evaluated on code generation.

    Source: §1 · p. 1, §7 · p. 4
  • Method

    The paper probes output-level soft barriers using Unicode perturbations and defines Copy-Paste Resistance to isolate handoff friction from generation failures.

    Source: §2 · p. 2, §3 · p. 3
  • Results

    Copy-paste resistance varied substantially by model and task; an exploratory pilot suggested participants shifted from direct transfer toward editing and reconstruction.

    Source: §4 · p. 3, §5 · p. 4
  • Takeaways & Limitations

    The findings motivate broader research on handoff-aware programming assistants that treat the boundary between generated text and executable software as a design surface.

    Source: §7 · p. 4

    Motivated users can bypass Unicode barriers by requesting clean output, normalizing text, or retyping code.

    Source: §6 · p. 4

Abstract

from arXiv · show

Copying a function from a chat window into an editor takes less than a second. For many uses of AI coding tools, that speed is the point; in settings such as programming education, code review, and security-sensitive development, it can also be the problem. This paper frames copy-paste as an \emph{AI code handoff problem}: the moment model-generated text crosses from a conversational context into executable or committed software is a design boundary that current tools leave largely unmanaged. We argue that AI coding assistants should not only be evaluated by the code they generate, but also by how they mediate the transfer of that code into software artifacts. We propose \emph{soft barriers} as one class of handoff-aware mechanisms. Soft barriers preserve access to AI assistance while making unexamined transfer less frictionless. As an initial technical probe, we instantiate this idea using Unicode output perturbations that preserve visual readability but disrupt naive copy-paste execution. We introduce Copy-Paste Resistance (CPR), the fraction of functionally correct clean solutions that become syntactically invalid after perturbation. Across HumanEval and MBPP with four LLMs and four perturbation families, we find that output-level barriers can achieve high copy-paste resistance, but their effectiveness is highly model- and task-dependent. An exploratory pilot with 18 participants provides early evidence that soft barriers can shift users from direct transfer toward editing and reconstruction. We do not present Unicode perturbations as a deployment-ready solution; rather, we use them as a minimal probe for a broader research agenda on practical, transparent, and policy-aware AI code handoff.

1 Introduction

The paper frames the transition from AI-generated code to executable or persistent software as an unmanaged handoff boundary. It argues that assistants should manage this design surface through context-sensitive handoff mechanisms, including soft barriers that preserve AI access while discouraging unexamined transfer.

The AI Code Handoff Problem

  • The AI code handoff problem is the unmanaged move from generated text into executable or persistent software, sometimes before it is understood, tested, reviewed, or attributed.Examples include transfer into an editor, notebook, or repository.Source: §1 · pp. 1–2
  • Education is an initial concern: a correct solution can precede learning, while cited research warns of weakened learning and independent problem-solving [11] [21].Bans can conflict with professional practice, and detection can be defeated by prompt variation, refactoring, or natural student writing [16] [23].Source: §1 · p. 1
  • Because AI-generated code can be complete enough to run with little adaptation, handoff-aware design also matters in professional settings where transfer may bypass review, security analysis, provenance, or license checks.The paper treats the handoff as a design surface rather than only an individual behavior problem.Source: §1 · pp. 1–2
  • Soft barriers preserve access to AI code while making unexamined transfer less frictionless, nudging users toward reading, editing, reconstruction, or review.The initial probe uses Unicode output perturbations that remain visually readable but disrupt naive copy-paste execution, requiring only a system prompt and no retraining or environment changes.Source: §1 · p. 2
  • The paper introduces Copy-Paste Resistance (CPR) to measure disrupted transfer of otherwise correct code and reports an exploratory pilot showing barriers can change execution behavior and user interaction.The introduction presents these as contributions, without reporting CPR values or pilot results.Source: §1 · p. 2
  • Handoff policies should vary by context, allowing direct transfer when appropriate or adding explanations, metadata, review, tests, or soft barriers.Education may favor reconstruction and comprehension; professional codebases may require provenance, review, testing, or security checks.Source: §1 · p. 2

2 Unicode Soft Barriers as a Probe

The section probes soft-barrier handoff by using Unicode perturbations to make unexamined transfer less frictionless while preserving visual readability. The approach operates at the output layer, and the paper cautions that deployment should be disclosed, institutionally approved, and accessibility-tested.

2 Unicode Soft Barriers as a Probe

  • Unicode perturbations can leave generated code visually readable while causing parsing or execution errors after copy-paste.The probe targets the gap between how code appears and how it is internally represented.Source: §2 · p. 2, Figure 1 · p. 2
  • A system prompt injects Unicode characters into user-defined identifiers while leaving keywords, operators, literals, and built-in names unchanged.This tests output-layer handoff shaping without retraining the model, changing its decoder, or modifying the execution environment.Source: §2 · p. 2
  • The four evaluated perturbation families are invisible characters, homoglyphs, reordering, and deletion.Table 2 describes the families; Figure 1 illustrates a homoglyph intervention.Source: §2 · p. 2, Table 2 · p. 2, Figure 1 · p. 2
  • The paper does not advocate covert deployment in general-purpose tools; real deployments should be institutionally approved, policy-level disclosed, and accessibility-tested.Source: §2 · p. 2

3 Evaluation

The evaluation tests whether output-level barriers disrupt naive transfer of correct generated code, whether the effect varies across models and tasks, and whether friction appears in user behavior. It evaluates two code benchmarks using Pass@1 and Copy-Paste Resistance (CPR).

3 Evaluation

  • The evaluation uses HumanEval’s 164 Python problems and MBPP’s 974 entry-level tasks, testing Claude Sonnet 4.5, DeepSeek-V3, GPT-5.2, and GPT-5.2 Codex.For each problem, the researchers generate a clean solution and a perturbed variant.Source: §3 · p. 2
  • Pass@1 measures whether the first solution passes all tests, and is reported for clean and perturbed code to characterize correctness degradation.The passage points to Figure 2 for Pass@1 on HumanEval and MBPP under each intervention and baseline; it provides no cell values.Source: §3 · p. 3, Figure 2 · p. 3
  • CPR isolates handoff-barrier effects by considering only problems whose clean solution passes, then measuring syntax errors in perturbed code.This distinguishes correct code disrupted by a barrier from logically incorrect generation.Source: §3 · p. 3
  • A CPR of 1.0 means every correct solution becomes syntactically unexecutable after intervention; 0.0 means executability is unaffected.Source: §3 · p. 3

4 Results

The results show that Pass@1 alone can misrepresent whether a soft barrier works, while CPR reveals that effectiveness varies substantially by model, benchmark, and perturbation. The findings favor calibrated handoff barriers rather than a universal intervention.

False Narrative of Pass@1 under Soft Barriers

  • Pass@1 can misread barriers: Claude's 0.997 CPR with invisible characters on MBPP accompanies very low Pass@1, while DeepSeek-V3's 0.064 CPR with reordering on HumanEval accompanies relatively high Pass@1.A Pass@1 drop can reflect either a correct solution made syntactically invalid by the barrier or a model failure; these have opposite meanings for barrier success.Source: §4 · p. 3

Analysis of Soft Barriers under CPR

  • CPR effectiveness varied by model and perturbation: Claude reached 0.997 on MBPP with invisible characters, while DeepSeek-V3 reached 0.640 on HumanEval with homoglyphs.Claude's MBPP CPRs were 0.997, 0.986, 0.982, and 0.975 for invisible characters, homoglyphs, deletions, and reorderings; on HumanEval, reorderings reached 0.943, deletions 0.846, invisible characters 0.766, and homoglyphs 0.008. DeepSeek-V3 stayed mostly below 0.25 for deletions, reorderings, and invisible characters, but homoglyphs reached 0.640 on HumanEval and 0.796 on MBPP.Source: §4 · p. 3
  • GPT-5.2's invisible-character CPR was 0.846 on HumanEval but 0.006 on MBPP, while GPT-5.2 Codex reached 0.773 and 0.771, respectively.The paper describes Codex's invisible-character results as one of the most promising configurations.Source: §4 · p. 3
  • The results support calibrating barriers: a useful intervention blocks naive transfer of otherwise correct code while preserving readability for inspection, reconstruction, or learning.Because a perturbation that works for one model may fail for another, the paper suggests combining Unicode soft barriers for deployment.Source: §4 · p. 3

5 Exploratory Behavioral Pilot

In an exploratory pilot, Unicode-based soft barriers were associated with less direct copying and more editing, alongside reported gains in code understanding and learning while participants completed tasks.

5 Exploratory Behavioral Pilot

  • Group A reported more code modification than Group B: 4.00 vs. 1.00 for Task 1 and 3.67 vs. 1.00 for Task 2.The pilot’s behavioral results are consistent with a shift toward editing and reconstruction.Source: Table 4 · p. 4, §5 · p. 4
  • Group A reported higher code understanding and learning benefit (4.00 vs. 2.83 and 5.00 vs. 3.50 across Tasks 1–2); frustration was 1.67 and 1.83.Participants completed the tasks, though Group A required more submission attempts on both, suggesting a more iterative inspect–modify–resubmit workflow.Source: Table 4 · p. 4, §5 · p. 4
  • The pilot involved 18 participants using GPT-5.2 in a browser-based tool for two Python tasks, with an invisible-character prompt intervention compared against no intervention.Researchers logged clipboard events and submissions and collected post-task Likert responses; participation was consented, clipboard logging disclosed, and not tied to grades.Source: §5 · p. 4
  • Open responses described the barrier as requiring participants to understand AI-generated code before modifying or executing it.The authors characterize the pilot as preliminary evidence that Unicode-based soft barriers can shift handoff from direct transfer toward active editing and productive friction.Source: §5 · p. 4

6 Discussion

The handoff problem extends beyond education, but Unicode barriers are bypassable and CPR does not establish learning benefits. Responsible deployment requires transparency and accessibility testing, while further human studies and cross-environment measurement remain needed.

Broader Implications Beyond Education

  • Soft barriers could serve as a policy layer between an LLM and an IDE, LMS, or repository, with defaults tailored to educational, production, security-sensitive, and boilerplate code.Campus-managed assistants could also offer explanation-first, test-gated, or soft-barrier modes; professional code may otherwise enter codebases without review, tests, or provenance tracking.Source: §6 · p. 4

Threats and Responsible Use

  • Unicode barriers are bypassable [14], and CPR measures proximate handoff behavior rather than learning outcomes, leaving effects on comprehension and retention unknown.Users can request clean output, normalize text, or retype code; the claim is that barriers change the ordinary default path, not that they are secure.Source: §6 · p. 4
  • Undisclosed Unicode barriers would be deceptive, so deployments require institutional approval, transparency, and accessibility testing because zero-width characters can affect screen readers..Source: §6 · p. 4

Research Agenda

  • Future work should test whether friction prompts engagement or workarounds, measure CPR across teaching environments, and extend soft barriers beyond language-specific identifier rules.A comprehensive human experiment could log every model interaction; systematic testing across online judges, Jupyter, VS Code, and CLI is needed because Unicode normalization varies by environment.Source: §6 · p. 4

7 Conclusion

The paper frames the transfer of AI-generated code into running software as an unmanaged handoff boundary and proposes soft barriers as a design approach. Its results motivate research on assistants that treat this boundary as a design surface.

7 Conclusion

  • The paper introduces the AI code handoff problem and proposes soft barriers, using Unicode perturbations as an initial output-level probe.The handoff boundary is the moment generated code enters a running program.Source: §7 · p. 4
  • Copy-Paste Resistance isolates handoff friction from code-generation quality.Source: §7 · p. 4
  • Automated results and an exploratory pilot suggest output-level barriers can shape the AI-code handoff, motivating broader research on handoff-aware assistants.The longer-term goal is to treat the boundary between generated text and executable software as a design surface worth optimizing.Source: §7 · p. 4
Loading 2608.22638v1…