AI-Generated Code: Copyright, Inventorship, and What the Repository Can Prove

Technical-information note: Cyberonix is a software engineering consultancy, not a law firm. This article summarizes public U.S. agency and court materials available as of September 2, 2026, and discusses the technical records that may bear on AI-assisted software development. It is not legal advice or an opinion about any particular work, registration, patent application, or dispute. It does not address contracts, assignments, work-made-for-hire rules, or other ownership issues.

Open a Git commit and you can inspect the snapshot it points to, its parent references, author and committer fields, timestamps, and message. The Git data model explains that record. It does not record how each block of code was produced.

With AI coding tools, that gap becomes harder to ignore. A developer might write the interface, accept an AI-generated implementation, replace the error handling, and then squash the entire sequence into one commit. The merged diff shows the result. Much of the path there may be gone.

When that code later becomes the subject of a copyright registration, a patent application, a licensing review, or litigation, two questions tend to get tangled together: Who authored the code’s expression? Who conceived the claimed invention? The U.S. Copyright Office addresses the first question; the U.S. Patent and Trademark Office (USPTO) addresses the second. The questions are related, but they are not interchangeable. The commit record alone does not answer either one.

Copyright asks who controlled the expression

Software copyright is already narrower than ownership of a codebase. The Copyright Office’s Circular 61 states that protection extends to copyrightable expression embodied in a computer program, not to functional aspects such as algorithms, formatting, functions, logic, or system design. AI adds a separate question: which parts of that expression came from a human author?

The Copyright Office’s 2025 report on copyrightability and artificial intelligence says AI can be used in the creative process without automatically disqualifying the material a person authored. Its focus is the expression the person actually contributed or controlled. Expression supplied by the system falls outside the claim when the person did not determine enough of the result. The Office applies that inquiry to the particular work.

The Copyright Office organizes its analysis around three kinds of human contribution: prompts, human-authored expressive inputs, and human modification or arrangement of AI-generated material. The categories are useful for software, even though the Office has not issued a code-specific formula.

A prompt is an instruction, not necessarily authorship

In the Office’s present analysis of generally available systems, prompting by itself usually leaves too many expressive decisions to the model. A request can be detailed and still specify only the intended result, while the system chooses the actual wording, structure, and other expressive elements. The report notes that later technology could change this analysis. (Copyright Office report, pp. 18–21)

In a software record, the difference may be visible. “Add rate limiting to this service” states a goal. A design that specifies the data structure, keying scheme, update rule, concurrency behavior, and failure handling contains much more of the solution. That contrast does not decide copyrightability, but it tells a technical reviewer what evidence to find and preserve.

Human input and later revision require their own analysis

The same report says a human may claim protection for original expression that remains perceptible in an AI-assisted output. It also recognizes protection for sufficiently creative human selection, arrangement, or modification, while leaving the AI-generated material itself outside the claim. (Copyright Office report, pp. 22–27)

For code, the useful comparison is often not “human or AI?” It is the sequence: the code before the session, the model’s proposed patch, the developer’s edits, the review comments, and the merged result. A pull request containing substantial human revision presents a different factual record from an untouched generated file, even if both ultimately appear under a human committer’s name.

A case involving no claimed human contribution was easier. In Thaler v. Perlmutter, the D.C. Circuit held that the Copyright Act requires human authorship where the applicant identified a machine as the work’s sole creator. The Supreme Court denied review on March 2, 2026. The decision did not say how much human contribution is enough in a mixed human-and-AI work.

Registration turns provenance into a practical problem

The registration form calls for specifics. The Copyright Office’s 2023 AI registration guidance instructs applicants to describe the human-created material under “Author Created.” AI-generated material above the de minimis threshold belongs among the exclusions under “Limitation of the Claim.” Merely using a tool does not make the tool or its provider an author on the application.

The same guidance recognizes that some uses of AI do not raise a human-authorship issue and require no disclaimer. It also explains how to correct a pending application or supplement an issued registration when a required disclosure was omitted. In an infringement action, a court may disregard a registration if it finds that an applicant knowingly supplied inaccurate information and that accurate information would have caused the Office to refuse registration. (Copyright Office registration guidance, pp. 4–6)

Computer-program registrations add a versioning problem. For a revised program, the Copyright Office treats new copyrightable authorship as the subject of the later registration. Previously published or registered material, public-domain material, and third-party material are outside that new claim. (Copyright Office Compendium, ch. 700, § 721.9(G)) For code without trade secrets, the ordinary deposit is the first and last twenty-five pages of the source; Circular 61 provides different deposit options when trade secrets are present. (Circular 61, pp. 2–4)

Someone therefore has to connect the application and deposit to an identifiable version of the software. A repository tag, release record, build identifier, or preserved source snapshot can make that connection. Without it, even a careful description of human and AI contributions may point to the wrong state of the code.

Patent inventorship looks upstream of the implementation

The USPTO changed its AI inventorship guidance in November 2025. The revised notice rescinded the agency’s February 2024 guidance, including its use of the Pannu joint-inventorship factors to analyze one person working with an AI system. The USPTO explained that those factors apply when evaluating contributions by multiple natural persons; an AI system cannot be a joint inventor because it is not a person. (USPTO revised guidance)

What remains is the traditional conception inquiry. The guidance uses the established standard of “a definite and permanent idea of the complete and operative invention,” rather than a general objective or a research plan. The person must have a specific, settled solution and be able to describe the claimed invention with particularity. AI systems may supply services or ideas, but the USPTO treats them as instruments used by human inventors. (USPTO revised guidance, 90 Fed. Reg. 54636–37)

That makes timing important. Suppose an engineer documented a specific mechanism and then asked a coding assistant to implement it. Now suppose the engineer instead entered a broad problem statement, received an unfamiliar mechanism from the tool, and adopted it. The two histories raise different factual questions about conception. The source code may help explain the mechanism, but dated design records, tickets, diagrams, notebooks, and AI-session material may better show when the human had the claimed idea.

The claim language matters too. The USPTO asks whether the person had the complete mental picture of the claimed invention, including its limitations. A general contribution to the project is not automatically a contribution to every claim. (USPTO revised guidance)

Reconstructing the development history

There is rarely one decisive artifact. Depending on the project, a technical reconstruction may draw from several parts of the development record:

• The source baseline. Preserve the relevant repository state, branches, tags, and releases. Git records snapshots and lineage; it does not inherently record whether a person or a model composed a particular line. (Git data model)
• The design history. Tickets, architecture decision records, specifications, diagrams, and dated notes may show what the human team had decided before implementation began.
• AI-session material. If retained, prompts, responses, proposed patches, tool versions, and session timestamps may show what the system received and returned. They do not establish, on their own, who conceived an invention or authored the final expression.
• Review history. Pull-request comments, requested changes, proposed edits, and successive patches can document how generated material changed before merge. Review platforms may preserve both discussion and line-specific suggestions. (GitHub review documentation)
• The filing or transaction record. The copyright deposit, patent claims, licensed release, or diligence snapshot should be tied to the corresponding code version. Otherwise, the analysis can be technically sound and still address the wrong artifact.
• Witness accounts. Developer interviews can explain why a change was made and how a tool was used. Those recollections are strongest when they can be tested against contemporaneous records.

The order of preservation matters. Routine rebasing, squashing, log expiration, account deletion, or repository migration can remove context without changing the final source tree. Once that context is gone, a later reviewer may be able to describe the code but not reconstruct its path into the product.

What the records can prove

Technical evidence can narrow the factual dispute. It can identify versions, compare proposed and merged code, trace when a mechanism appeared, and test whether a witness’s account fits the available history.

It cannot turn a metadata field into an authorship conclusion. A human name on a commit does not establish that the person wrote every line. Approval of a pull request does not show that the reviewer made creative changes. A saved prompt does not, by itself, prove that the user controlled the output’s expression or had already conceived every limitation of a later patent claim. The absence of an AI log is not proof that no AI tool was used.

A detector score should not be used to fill those gaps. Even if a classifier suggests that code resembles model output, that result does not identify the relevant human contribution, connect the code to a particular session, or answer either agency’s legal test. At most, it supplies a lead to investigate against the underlying records.

How a software expert can assist

Counsel defines the legal issue. The technical task is to build an accurate, reproducible account of the software and its development history: which version matters, what changed, what records survive, what those records support, and where the evidence stops.

Cyberonix can perform that work through source code review and software engineering expert witness engagements. Depending on the dispute, the analysis may support counsel working through software copyright, patent, or artificial intelligence questions. The aim is a factual map of the engineering record, not a legal ownership opinion and not a promise that missing provenance can always be recovered.

For a team adopting an AI coding tool, the mundane records turn out to matter: what the engineers decided before generation, what the tool returned, what a person changed, and what finally shipped. The repository alone may not retain that story.

Related Cyberonix resources

• Artificial intelligence expert witness
• Software expert witness for copyright
• Software expert witness for patent litigation
• Source code review
• Pre-litigation source code review and reverse engineering
• AI-integrated software engineering

Sources

• U.S. Copyright Office, Copyright and Artificial Intelligence, Part 2: Copyrightability (January 2025).
• U.S. Copyright Office, Copyright Registration Guidance: Works Containing Material Generated by Artificial Intelligence, 88 Fed. Reg. 16190 (March 16, 2023).
• U.S. Copyright Office, Circular 61, Copyright Registration of Computer Programs (revised March 2021).
• U.S. Copyright Office, Compendium of U.S. Copyright Office Practices, Chapter 700, Literary Works (third edition, January 28, 2021).
• USPTO, Revised Inventorship Guidance for AI-Assisted Inventions, 90 Fed. Reg. 54636 (November 28, 2025).
• Thaler v. Perlmutter, No. 23-5233 (D.C. Cir. March 18, 2025); Supreme Court docket No. 25-449 (certiorari denied March 2, 2026).
• Git, Git Data Model.
• GitHub, Giving Reviews.