Do I own code that AI helped me write?

That is four separate questions, not one - what the tool's terms say, who did the work, what third-party libraries are inside the output, and what can be protected at all - and each can have a different answer. A blanket yes or no is almost always inaccurate, and the position for your specific case has to come from a lawyer rather than an article.

Does it matter which plan I used?

Yes - terms differ between consumer, team and enterprise plans, and that applies to the output question as well as the data question. Read what applies to the account you actually used, in the official terms rather than in an article, since terms are updated and any quotation of them dates. For a significant commercial project, show that point to a lawyer.

What if a freelancer built it for me using AI?

Then what governs is the agreement, exactly as in ordinary commissioned development - the tool does not change that question, and the default without a written agreement is not self-evident. If there is no written agreement, that is the point to address with a lawyer, and before there is a dispute rather than after.

What about open source libraries inside the software?

Software is almost never written from scratch and each library carries its own licence, some of which impose conditions on anyone distributing software that uses them - and that holds whether a person wrote the code or AI helped produce it. A non-developer usually does not know which libraries are in the project, which is a substantive reason for a technical review before it becomes a commercial product.

When does this question actually matter?

In three situations: when you sell the software or charge for it, when someone else built it for you, and when you sell the business and what is included gets examined. For a personal tool, a prototype or a one-off conversion the question is theoretical. In all three real cases, establish the position with a lawyer in advance - it costs substantially less than a dispute afterwards.

What is clearly mine regardless of the code question?

Your data - customers, orders, history; the business knowledge embodied in the tool, such as how you price and how your process works; your brand; and anything you kept to yourself, since code never distributed is in practice a trade secret. For most businesses the value sits there rather than in the code, because a small piece of software can be replicated and a customer list cannot.

Who Owns AI-Built Software - Yehonatan Saadia

This is a legal question with several separate parts, and the answer for your case has to come from a lawyer. What this describes is which parts exist - the tool's terms, who did the work, third-party code inside the output, and what you can protect regardless.

The question sounds simple and is not, because it is made of four separate questions that can have different answers. And to be clear from the outset: this text is descriptive only. The position for your case has to come from a lawyer, and an article should not be relied on.

Why this is not one question

Treating "who owns the code" as a yes-or-no is where people go wrong. There are actually four layers:

What the tool's terms say about the output.
Who did the work - you, an employee, or an external supplier.
What is inside the output - libraries and third-party code with their own licences.
What can be protected at all, and by what means.

Each of these can be entirely fine while another creates a problem. Which is why a blanket answer of "it's yours" or "it's not yours" is almost always inaccurate.

1. The tool's terms

The first place to look, and it is specific to the tool and the plan.

What matters to know: terms differ between consumer, team and enterprise plans - and that is true of the ownership question too, not only the data question.

What to do: read what applies to the account you actually used. Do not quote an article - including this one. Terms are updated, and a quotation dates.

And if the project is commercial and significant - this is a point to show a lawyer, not to conclude alone.

2. Who did the work

This layer surprises people, and it is usually more significant than the tool.

The question of who built it exists exactly as it does in ordinary development, and the tool does not change it:

Who built it	What decides
You, for yourself	The simplest case
An employee	The employment agreement
A contractor / freelancer	The agreement - and the default without one is not self-evident
A partner	The agreement between you

The practical point: if you paid someone to build something, what governs is what the agreement says. This is not a new question AI created - it has existed as long as commissioned development has, and AI does not resolve it.

So: if there is no written agreement, that is the point to address - with a lawyer.

3. What is inside the output

A technical layer that is easy to miss.

Software is almost never written from scratch - it uses open source libraries, and each carries its own licence. Some licences impose conditions on anyone distributing software that uses them.

And that holds whether the code was written by a person or produced with AI - the dependencies are the same.

What that means practically: know which libraries the project uses. And a non-developer usually does not know - which is a substantive reason to have someone technical review the project before it becomes a commercial product, on top of the security reasons.

4. What can be protected

Here it is important to separate what is subject to interpretation from what is not.

What is clearly yours - and does not depend on the code question:

Your data. Customers, orders, history.
The business knowledge embodied in the tool - how you price, how your process works.
The brand - name, logo, reputation.
What you keep to yourself. Code that was never distributed is in practice a trade secret.

What is more complex: the precise scope of protection for code produced with AI assistance is an evolving area and differs between jurisdictions. That is exactly the question for a lawyer - and not one to settle here.

A practical point worth making: for most businesses, the value is not in the code but in the data, the customers and the process. A small piece of software can be replicated by anyone who wants to; the customer list and the operational knowledge cannot.

What to do in practice

Four steps, in order of cost:

Keep records. When it was built, with what, by whom. If you are asked in two years you will not remember, and that is precisely when records are worth having.
Read the tool's terms for the account you used.
Sort out agreements with everyone involved - employee or supplier. Before there is a dispute.
Before it becomes a commercial product - a lawyer. And someone technical to review the dependencies.

When this does not matter at all

Worth some proportion: for most of what gets built this way, the question is theoretical.

A personal tool only you run, a prototype proving an idea, a one-off conversion - there is nothing here to fight over.

The question becomes real in three situations:

When you sell the software or charge for it.
When someone else built it for you.
When you sell the business and what exactly is included gets examined.

In all three - a lawyer, in advance. The cost of establishing the position beforehand is substantially lower than the cost of a dispute afterwards.

Again, because it matters

This text describes which questions exist. It is not legal advice and does not determine the answer for your case. Intellectual property law differs between jurisdictions, is evolving in this area, and depends on the specific facts. A lawyer who knows the field and your case is the source of the answer.

Who Owns Software You Built With AI? The Questions That Decide

Key takeaways