Source-linked AI summary
It Is Not My Code Anymore
Augusto Camargo
TL;DR
AI-assisted programming raises separate questions about who produces code, who feels ownership, and who is responsible when it fails. This note uses a hypothetical enrollment failure and literature distinctions to examine those questions, then proposes evaluating generated implementations and their production processes against demand-based service criteria. It concludes that changing the means of delivery does not remove the obligation to provide a functioning enrollment service.
Problem
AI-assisted programming complicates distinctions among production, ownership, and responsibility, while identifying a producer does not determine duties after service failure.
Source: Authorship: who produced the code? · p. 2, Responsibility after failure · pp. 2–3Method
The note analyzes a hypothetical enrollment failure, selectively reads relevant literature, and compares artifact, process, service, and alternative-delivery evaluation questions.
Source: Responsibility after failure · p. 3, Evaluating the service and its… · p. 3, Does the task need a separate program? · p. 6Results
The note distinguishes producing an expression from directing or reviewing it, separates authorship from responsibility, and grounds acceptance in the required service outcome rather than generated implementation alone.
Source: Authorship: who produced the code? · p. 2, Responsibility after failure · p. 2, Evaluating the service and its… · p. 3Takeaways & Limitations
Whether code is called ours or replaced by another delivery means, evaluation must still establish that the student can enroll.
Source: Limitations and conclusion · p. 6The proving ground covers selected use conditions and may miss relevant ones, requiring post-deployment observation to detect omissions and revise tests.
Source: Limitations and conclusion · p. 6
Abstract
from arXiv · showhide
AI-assisted programming raises distinct questions about who produces code, who feels ownership of it, and who is responsible when it fails. This research note examines these distinctions through a hypothetical enrollment failure and a selective reading of the literature. Identifying the producer of a defective expression does not, by itself, determine the duties of reviewers, release decision-makers, or service operators. Collective ownership likewise leaves those duties to be specified. The discussion then considers how quality engineering can evaluate both generated implementations and the processes that produce them. Acceptance criteria should be justified by the required service outcome, with component checks contributing evidence toward that outcome. This perspective also permits comparison with systems that perform a task without generating a separate program for it. Such substitution would change the object of authorship while leaving the service obligation intact. The note reports no new empirical results; it proposes distinctions and evaluation questions for AI-assisted software production.
Authorship: who produced the code?
AI-assisted programming separates producing an expression from directing, reviewing, maintaining, or feeling ownership of code. A reviewer can affect release without becoming the producer, and responsibility remains distinct from authorship.
- “My code” can mean code someone wrote, inherited, maintains, or is expected to repair, so possession alone does not identify authorship.Source: Authorship: who produced the code? · p. 2
- Higher AI contribution can reduce perceived possession and shift attribution toward AI while willingness to accept accountability remains comparatively stable.Source: Authorship: who produced the code? · p. 2
- Directing an implementation and producing its expressions are distinguishable contributions: the developer may guide the work while the model supplies the expression.Source: Authorship: who produced the code? · p. 2
- Reviewing a diff can support a release decision without changing who produced an expression already present in it.Source: Authorship: who produced the code? · p. 2
- A generated defect can be fully reproducible, so investigation should trace how the expression entered the program and why the failure reached the student.Source: Authorship: who produced the code? · p. 2
Responsibility after failure
Production history, collective ownership, and co-creation do not by themselves assign post-failure responsibilities. Investigation must connect contributions and duties to controls, service obligations, and repair actions.
- Co-constituted programming can involve several contributors while a particular defective expression remains traceable to a particular source.Source: Responsibility after failure · p. 2
- Reconstructing who contributed to a program does not by itself determine who has which responsibilities after failure.Source: Responsibility after failure · p. 2
- Different production histories can yield the same program, and recorded history may be incomplete.Source: Responsibility after failure · p. 2
- Failure investigation must identify who introduced the expression, which controls should have detected or contained it, and who owed and must restore the service.Source: Responsibility after failure · p. 2
- Assigning responsibility requires a relevant contribution, an applicable duty, and evidence connecting the two.Source: Responsibility after failure · p. 2
- Shared ownership leaves operational duties unresolved, including who can stop releases, question acceptance evidence, investigate, repair, and explain failures.Source: Responsibility after failure · pp. 2–3
- The note asks whether people attribute code differently after successful delivery and after failure.Source: Responsibility after failure · p. 3
We put the machine in the loop
Generative models add another producer to an existing machine-in-the-loop software process. Quality engineering therefore must examine the production setup and outputs while reorganizing controls around process variability and explicit evidence.
- Generative models join software production as producers of implementations rather than replacing the existing human-and-machine process.Source: We put the machine in the loop · p. 3
- Dividing work differently historically changed inspection and shifted quality attention toward process variability.Source: We put the machine in the loop · p. 3
- Evaluating generated software requires considering the model, configuration, context, harness, tools, dependencies, and human interventions together.Source: We put the machine in the loop · p. 3
- Quality engineering should define acceptance evidence, question the process, track failures, and support release decisions with explicit criteria and authority.Source: We put the machine in the loop · p. 3
- Inspection and testing alone cannot assure quality, so evaluation should cover both the generating process and its outputs.Source: We put the machine in the loop · p. 3
Evaluating the service and its production
Service acceptance must be anchored in the required demand rather than derived solely from generated implementation behavior. Component checks remain useful evidence, while artifact and process evaluation extend toward realistic service outcomes.
- A process can repeatedly pass local checks while leaving the student unable to enroll, so repeatability alone does not establish service success.Source: Evaluating the service and its… · p. 3
- Outside-in evaluation starts with required outcomes and use conditions, then identifies evidence needed from each contributing system.Source: Evaluating the service and its… · p. 3
- For enrollment, demand determines what component evidence must establish, while quality organizes assurance across engineering and operation.Source: Evaluating the service and its… · p. 3
- The central acceptance comparison is whether the incumbent code or the demand supplies the oracle.Source: Evaluating the service and its… · pp. 3–4
- Enrollment crosses software boundaries involving records, payment, access rights, recovery, and administrative action.Source: Evaluating the service and its… · pp. 3, 5
- Component operations can pass while the enrollment journey fails or reports success without a persistent enrollment record.Source: Evaluating the service and its… · p. 5
- A proving ground evaluates assembled service behavior under required conditions, whereas component tests evaluate narrower objects and criteria.Source: Evaluating the service and its… · p. 5
- Acceptance criteria should be justified against demand, and process evaluation should test multiple recorded configurations against the same external criteria.Source: Evaluating the service and its… · p. 5
Does the task need a separate program?
The paper distinguishes generating a task-specific program from using an existing system to perform the task without generating a new program. Either means of delivery must satisfy acceptance criteria defined by the required enrollment outcome.
Implementation alternatives
- Acceptance criteria can evaluate service delivery without assuming a particular implementation.This allows comparison between generated programs and other means of providing enrollment.Source: Does the task need a separate program? · p. 5
- An existing system may perform a task without generating a new program, although it still depends on software and operating infrastructure.This possibility differs from hiding code or generating it dynamically, both of which still involve an implementation.Source: Does the task need a separate program? · pp. 5–6
Enrollment evaluation
- For enrollment, the relevant comparison is between generating a program and having an existing system carry out the operations.Whether the latter meets the demand remains an evaluation question rather than an assumption.Source: Does the task need a separate program? · p. 6
- Any delivery method must satisfy valid enrollment and required downstream effects under actual operating conditions.The acceptance criteria remain tied to the service outcome rather than to authorship or implementation form.Source: Does the task need a separate program? · p. 6
Responsibility
- If substitution is feasible, no newly generated program requires authorship assignment, but responsibility for providing the service and handling failures remains.The practical question becomes whether the chosen means of delivery meets the demand.Source: Does the task need a separate program? · p. 6
Limitations and conclusion
The note uses a hypothetical failure and proposes distinctions for release and incident decisions rather than reporting empirical findings. Its evaluation approach remains bounded by selected test conditions, requiring post-deployment observation and revision.
Scope
- The enrollment failure is hypothetical, and the cited studies do not certify safe delivery or establish that collective ownership collapses after failure.The note instead asks how these relationships inform release decisions and incident handling.Source: Limitations and conclusion · p. 6
Evaluation boundary
- A proving ground can miss relevant operating conditions because it covers only selected scenarios.Its scenarios and acceptance criteria therefore require justification against the conditions in which the service is needed.Source: Limitations and conclusion · p. 6
- Post-deployment observation is needed to detect omitted conditions and revise the tests.Pre-release evidence alone does not exhaust the conditions requiring evaluation.Source: Limitations and conclusion · p. 6
Conclusion
- Distinguishing who produced the expression, which process accepted it, and who experienced the failure supports questions about action and release evidence.These distinctions organize responsibility without assigning every duty to the producer.Source: Limitations and conclusion · p. 6
- Calling the code ours or replacing the program with another delivery means still leaves the enrollment service subject to evaluation.The student must still be able to enroll.Source: Limitations and conclusion · p. 6