You see an app that solves a problem well. Perhaps it keeps a busy team’s conversations organised, turns a spreadsheet into a useful dashboard, or lets customers book an appointment without a phone call. Your first thought is reasonable: could we build something like that for our business?
With AI coding tools, the first working version can arrive surprisingly quickly. That makes a second question more urgent: are we building our own product, or copying someone else’s work?
A clean-room approach can help a team keep those activities separate and document independent development. It does not make every replica lawful. The inputs, the licence, the finished product and the countries where it will be sold still matter.
What does “clean room” mean in software?
Think of it as a carefully managed handover. One group studies what a product does through access it is entitled to use. It writes a neutral description of the required behaviour. A separate group builds from that description, without receiving the original code or other restricted material.
For example, “a team member can search messages they are allowed to read” describes a useful function. A folder containing a competitor’s source code, copied screen artwork and help pages is a very different starting point.
The separation is a way to produce evidence of how the new work was created. Having two teams is not a universal legal requirement, and the words “clean room” are not a legal certificate. A brief can itself carry copied material, so someone needs to review what crosses that boundary.
What recent AI rebuilds actually show
The headlines tend to put very different projects in the same “AI clone” basket. Looking at the development process tells us much more than the label.
Cloudflare’s Vinext: compatibility with an open-source framework
In February 2026, Cloudflare described building Vinext with AI, an implementation of the Next.js programming interface on a different foundation called Vite. The idea was to let developers run familiar Next.js applications with another implementation underneath.
There is a detail that matters to this discussion: Cloudflare said it ported tests from Next.js and that its AI sometimes examined framework internals. This was not evidence of a strict, source-isolated clean room. Next.js is available under the MIT licence, which permits reuse subject to its conditions, including preserving the required notice.
Cloudflare later announced Vinext 1.0 in September. The useful lesson is that licensed reuse and independent implementation are different routes. An open-source compatibility project does not establish permission to copy a closed commercial app.
Cursor’s browser and SQLite experiments: a demo is only the beginning
Cursor’s experiments included teams of AI agents building a browser. In its July 2026 account, Cursor described that browser as a proof of concept that fell well short of polished software. Calling it a finished replacement for Chrome would go beyond the evidence.
The same account described a SQLite database experiment built from its manual, with source code, the original binary, test suites and internet access withheld from the building agents. Separate tests measured the results afterwards. That is a useful example of controlling the information available to a builder. It is a company’s report of an experiment, not a legal ruling or proof that every detail of a mature product has been reproduced.
For a business, the practical question remains: will the new system handle permissions, awkward inputs, recovery and daily use? A convincing screen recording cannot answer all of that.
The Claude Code takedown: available online does not mean licensed
On 31 March 2026, Anthropic submitted a copyright takedown notice concerning a repository containing its work and named forks. The following day it partly retracted the notice, limiting it to the original repository and the individually listed forks after a broader network-wide removal.
That record concerns claimed copying and the scope of removal. It is not a court decision about every AI rewrite associated with the episode. It does, however, show why finding code on the internet is not enough to establish permission to use it.
Feeding restricted code to an AI and asking for a translation into another language does not establish independent creation. Renamed functions and different wording do not, by themselves, answer whether protected material was copied or adapted.
The chardet dispute: “rewritten” is a claim people can challenge
A smaller but revealing example is chardet, a tool that helps software recognise text encodings. Its AI-assisted rewrite led to a public licensing dispute in March 2026. The challenge questioned whether the rewrite could leave the earlier licence behind. The maintainer defended the rewrite and acknowledged extensive prior exposure to the old code.
Those are opposing positions in a project discussion, not a court’s findings. The point for a buyer is simple: ask how the team reached its conclusion about independence and licensing. A “complete rewrite” label or a low similarity score is not, on its own, legal clearance.
Where is the copyright boundary?
A useful starting distinction is between an idea and the way someone expressed it. In the United States, section 102(b) of the Copyright Act excludes ideas, processes, systems and methods of operation from copyright protection. That does not give permission to take the code, illustrations, wording or other protected expression used to deliver them.
A calendar feature is a business need. Copying another app’s original icons, onboarding text and distinctive screen composition raises different questions. Some interface elements are functional or commonplace; others may contain protected creative choices. There is no dependable rule that changing a colour or a certain percentage makes a copy safe.
In the European Union, the court’s SAS Institute v World Programming decision distinguished program functionality, programming language and relevant data-file formats from protected program expression. It also recognised limits: source code and protected material in manuals were different matters. Lawful observation was important to the facts; the decision is not a worldwide permission slip for any form of reverse engineering.
India also distinguishes ideas from expression in its official copyright guidance. Section 52(1)(ab) and (ac) of the Copyright Act provide specific exceptions relating to interoperability and observing or testing a program, with conditions. Interoperability means getting independently created programs to work together. These provisions are not a general exemption for making a commercial replica; the separate personal-use exception is limited to non-commercial personal use.
These are jurisdiction-specific starting points. The legal answer for a particular product depends on the actual materials, the applicable law and how the work was done.
Clean-room development does not clear every other right
Copyright is only part of the review. The USPTO’s explanation of intellectual property separates copyright from trademarks and patents. A confusingly similar product name or visual identity can create branding problems. Writing code independently does not automatically resolve a claim involving a valid patent.
Confidential information needs its own care. WIPO’s trade-secret guidance explains the protection of valuable secret information and the problems with unauthorised acquisition, use or disclosure. Do not bring a former employer’s private implementation, a customer database or a leaked repository into a new build.
Check account terms, licence restrictions, confidentiality promises and permission to use data. Do not bypass a login, paywall or other access control simply to study a product. In the US, section 1201 adds separate access-control rules; any exception needs to be assessed on its own conditions. Contract rules and mandatory legal exceptions also vary by country.
A worked example: a team workspace with familiar features
Consider a fictional catering business that likes the convenience of Slack-style conversations. It wants discussions grouped by event, fast message search and reminders for unanswered customer questions. This is an illustrative project, not a report of a Noesis client engagement.
The business starts by talking to its staff. They describe a daily frustration: delivery details are lost between the kitchen, the sales desk and the event manager. The brief focuses on that problem.
- Create one conversation space for each event, with access limited to the assigned staff.
- Let a person search only the messages they have permission to read.
- Attach a delivery note and record who acknowledged it.
- Show unanswered customer questions to the responsible team member.
- Allow quiet hours for notifications and a clear route to urgent help.
None of those requirements needs Slack’s code, brand or exact screen design. The new product could centre on an event schedule, with kitchen tasks beside each conversation. Its words, icons and layout should be developed for the catering team. Any imported records must be data the business is authorised to use.
Testing then asks practical questions. Can a temporary worker see another event’s private messages? Does removing a team member actually remove access? What happens when an attachment fails? That gives the buyer a more useful acceptance test than “does it look like Slack?”
How to run an AI-assisted clean-room project
The following is a practical process to discuss with your developers and, where needed, an intellectual-property lawyer. It is designed to make the work traceable, not to promise immunity from a claim.
1. Agree what the team may use
Make an intake list before collecting reference material. Record the product and version, how access was obtained, relevant terms, public documentation, approved open-source components and the rights attached to each item. Separate material you own from material you are licensed to use and material that must stay out.
If the starting material is leaked, confidential or of uncertain origin, stop that route and resolve the rights question. Do not ask an AI to remove names or disguise where it came from.
2. Write the behaviour in your own words
An authorised observer records inputs, visible results, permissions and failure cases. A reviewer removes copied wording, screen artwork, source fragments and unnecessary implementation detail before the brief reaches the builder. Public documentation can still be copyrighted; its availability is not permission to reproduce its prose.
For the catering workspace, write “a removed staff member cannot open event attachments” rather than describing a competitor’s internal permission code. A brief should say what the new software must do and how to check it.
3. Keep the building environment separate
Give the builder the reviewed brief and approved dependencies. Use separate repositories, file access and AI sessions for observation and implementation. Include assistants’ saved context and retrieval tools in that separation. Where stronger independence evidence is needed, use people who have not studied the restricted implementation.
A fresh chat cannot establish what a model encountered during training. It can help control what your project supplies now. If restricted material reaches the builder, document it and get advice on a remedy rather than deleting the record and continuing as though it never happened.
4. Build an original product and review the output
Ask AI to implement the approved requirements, not to make an exact replica. Give designers room to solve the customer’s problem in a different way. Review generated code, unusual comments, dependencies, copied assets and licence notices. Investigate material that looks borrowed; a model’s assurance that something is original is not evidence.
This is also why a clear brief becomes more valuable with better AI coding. It gives the team a specific target without turning a competitor’s implementation into the instructions.
5. Test the promised behaviour independently
Use tests and sample data you created or are entitled to use. Check the normal task, permission boundaries, errors and recovery. Have someone outside the building loop review both the product and its development record. Source-comparison tools can help investigate similarities, but no percentage score is a universal legal threshold.
Keep the quality review separate from the rights review. A product can have an original design and still lose customer data. It can pass a functional test and still contain an asset it has no right to ship.
6. Keep enough evidence to explain the work
Retain the dated input list, access permissions, reviewed brief, important AI instructions and outputs, design decisions, code history, dependency licences and test results. Keep records securely without collecting unnecessary personal data. This is a record of the real process, not a folder assembled afterwards to make the project look independent.
Before a commercial launch, review the particular product and intended markets with qualified counsel where the risks call for it. Agree who owns the work, what third-party components remain and who handles a complaint. Describe compatibility accurately without suggesting endorsement by the original supplier.
A better instruction to give your AI builder
A prompt is only useful when the surrounding access controls match it. With that in place, a starting instruction could read:
Build from this reviewed requirements brief and the approved components list. Do not retrieve or use the reference product’s source code, copied screens, wording or private data. Create our own implementation and interface. Record the dependencies and their licences. Ask when a requirement cannot be met without additional material.
That leaves the team with questions it can actually answer: what went into the build, why each part is there and how the finished product was checked.
Who owns software made with AI?
Avoid assuming that payment for an AI tool gives you exclusive copyright in everything it produces. Tool terms and copyright protection are separate questions. In its 2025 copyrightability report, the US Copyright Office explained that human-authored contributions can be protected when AI is used as a tool, while prompts alone generally do not provide the necessary control over the output. That is US guidance; other jurisdictions need their own assessment.
For a buyer, ask the development company to distinguish its own work, AI-assisted contributions and third-party components in the agreement. Keep a record of meaningful human design and coding decisions. An ownership clause cannot transfer rights the supplier never had.
Start with the work your customers need to do
An existing app can be a useful conversation starter. It should lead to a better question: which part of the customer’s day are we trying to improve? That is where a smaller, well-designed product can earn its place.
If you are considering a new product, our AI development team can help turn those needs into a practical brief. Bring the problem you want to solve and the materials you are entitled to use. An original product deserves a development history you can explain.
This article provides general information about development practice and selected legal principles. It is not legal advice or clearance for a particular product.
