A few years ago, the answer to the question "who wrote this code?" was relatively simple. You could point to a programmer, a team, or a software house responsible for a specific module.
Today, the situation looks completely different.
Part of the code may be written manually. Part may be generated by Copilot. Another piece may be created by a programming agent. Another will be pulled from an open source library. Yet another will be an external package dependency. On top of that come APIs, cloud services, ready-made components, frameworks, and tools provided by other companies.
The system works. But do you really know, what it was built from?
AI-generated code does not appear in a vacuum
The development of AI tools for programming is changing not only the way software is written. It is also changing the structure of responsibility for code.
A programmer can now describe a task to an agent and then receive a ready-made function, module, tests, configuration, or even architectural change suggestions. That is a huge acceleration of work.
The problem starts when we treat generated code as "code from nowhere".
AI does not create code in isolation from the entire programming ecosystem. Models are trained on huge datasets, and a generated fragment may be similar to existing solutions, patterns, or publicly available code. That is why the issue of code origin, licensing, and responsibility is becoming increasingly important.
This does not automatically mean that every piece of code generated by AI violates someone’s license. It does mean that an organization using AI in software development should treat code origin and verification as part of the engineering process, not a legal curiosity.
This is no longer just theory
On September 16, 2026, the 9th Circuit Court of Appeals decided part of the Doe v. GitHub case, in which programmers accused GitHub, Microsoft, and OpenAI-related entities, among other things, of using publicly available GitHub code to create and train tools such as Copilot and Codex.
One of the claims concerned the DMCA and copyright information. The court upheld the dismissal of that specific allegation. At the same time, the case also includes other issues related to copyright and open source licenses.
This is important not because one ruling gives a simple answer to the question of "whether AI code can be used".
It does not.
What matters more is that the dispute highlights a broader problem: in the world of AI, the boundary between code written by a human, code generated by a model, and code originating from an existing software ecosystem is becoming increasingly difficult to trace.
And for companies building software, that means a need for better management of this process.
Software supply chain, or your system has far more "authors"
In software security, the concept of the software supply chain has long existed.
These are all the components, tools, libraries, dependencies, and processes involved in creating the final product.
NIST points in this context, among other things, to the need to manage component provenance, control open source dependencies, monitor vulnerabilities, and use SBOM, or Software Bill of Materials.
In very simple terms, an SBOM can be compared to a list of product ingredients.
It does not just say "we have an application". It shows which components are inside.
For example:
- application framework,
- third-party libraries,
- versions of individual packages,
- open source components,
- indirect dependencies,
- elements provided by external vendors.
Thanks to this, when a vulnerability appears in a specific library, it is quicker to check which systems use it.
NIST also draws attention to provenance, meaning the ability to trace the origin of software elements.
And this is exactly where AI adds a new layer of complexity.
Because an additional way of creating code is added to the existing chain.
Imagine a typical business system
40% of the code was written by the team.
20% was created with AI assistance.
Another set of fragments was generated by an agent.
Several libraries come from open source.
Some dependencies were added by the framework.
The system uses an external vendor API.
One component comes from a package that nobody has updated in two years.
And the dependency documentation?
It is somewhere in the repository.
Or it does not exist.
The system works...
And that is precisely why the problem is invisible. Until something happens.
And then a vulnerability appears
Let’s assume a serious security flaw is discovered in one of the libraries.
The question is: Do you know whether your system uses it?
If you have a well-organized dependency register, the answer may take only minutes.
If you do not, manual searching through repositories begins, along with contacting developers, checking environments, package versions, and indirect dependencies.
Now let’s add AI-generated code to that.
Do you know which fragment was created using which tool?
Was code review performed?
Was the code covered by tests?
Were the dependencies checked?
Did anyone verify the component license?
Can you reproduce the process that resulted in a specific fragment being created?
These are no longer questions for the programmer alone.
These are questions about managing a company’s technological risk.
The biggest problem is not AI. It is the lack of a process
It would be easy to turn this article into a warning against artificial intelligence.
That would, however, be too simple a conclusion.
AI can significantly improve a development team's productivity.
The problem arises when a company increases the pace of code production but does not simultaneously increase control over that code.
It is a bit like a factory suddenly producing ten times more components, but not increasing quality control, material records, or supplier oversight.
In a software house, the equivalents of such a control system include:
- code review
- automated tests
- dependency scanning
- SBOM
- vulnerability monitoring
- open source license compliance
- CI/CD with security checks
- repository management
- architecture documentation
- tracking component provenance
- clear rules for using AI in development
NIST also points to the possibility of integrating supply chain security mechanisms directly into CI/CD pipelines.
This is an important shift in mindset.
Security should not be a control performed only before deployment.
It should be part of the software development process.
"Who wrote this code?" is no longer the right question
In traditional development, you could ask about the author.
In the world of AI-assisted development, much more important questions become:
- Where does this component come from?
- What license does it have?
- Who verified it?
- Which version are we using?
- What dependencies does it have?
- Is it still maintained?
- Do we know its vulnerabilities?
- Can we reproduce the change history?
- Do we know where AI participated in its creation?
And above all:
- Can the company prove that it is in control of all this?
Because the client does not buy "AI code". They buy a working system. And the responsibility for that system still lies with the organization that delivers and maintains it.
The code may be automatic. Responsibility is not
This is probably one of the most important changes AI brings to software houses.
The developer does not disappear. Their role changes.
More and more often, it is not only about writing a certain number of lines of code. It is about designing the solution, reviewing the generated elements, assessing risk, testing, integration, security, and maintaining the entire system.
Similarly, a company cannot limit itself to asking whether its developers use AI.
It should know how they use it, in what process, with what controls, and how it affects the entire software lifecycle.
Because in a few years the question may no longer be: "Who wrote this system?"
but: "Can you reproduce what it was built from and how it was built?"
If the answer is "not entirely", the problem is not the lack of yet another AI tool.
The problem is the lack of control over the software supply chain.
