Vibe Coding Risks: How to Prove Your Own Your AI-Generated Code

This article is a summary of what was covered in Due Diligence, a newsletter that covers one fintech story per issue, a deal, a lawsuit, a product launch, an accusation, and breaks down what happened, what’s underneath it, and what it means for what you’re building.

In June 2026, Corgi, a Y Combinator backed insurtech, launched a document sharing product called Dataroom. Within about a day, Marc Seitz, co-founder of the open source data room project Papermark, publicly accused Corgi of copying Papermark's product and posted side-by-side screenshots showing the same feature names and near identical copy.

‍

Corgi denied it. The company told TechCrunch that no code was used from Papermark, that the similarities were limited to visual elements on two settings pages, and that those elements were updated right away. Corgi's CEO, Nico Laqua, attributed the resemblance to vibe coding rather than copying. No lawsuit has been filed and nothing has been proven either way.

‍

That's the part worth sitting with. The dispute was never really about whether the screens looked alike, because everyone could see that they did. It was about whether identical without copying counts for anything. And if nobody on your team wrote the code, you're the one who has to answer that question.

‍

This guide walks through what software copyright actually protects, where AI-generated code creates exposure you can't scan for, and the six-step audit you can run on your own codebase this week. It's based on a webinar by Samuel Corso, who runs engineering pods for fintech startups at TechSuite and traced the Papermark repository himself to see where the disputed screens came from.

‍

One note before we start: this is engineering guidance, not legal advice. There's a point where the technical process ends and a lawyer's process begins, and we'll cover exactly where that line sits.

‍

Who owns AI-generated code?

‍

Here's the assumption most founders are working from: the AI wrote it from scratch, so it's mine and it's clean.

‍

The reasoning seems sound. Nobody opened a competitor's repo. Nobody pasted someone else's code into a prompt. The model produced what looked like fresh output.

‍

The problem isn't ownership in the abstract. It's provenance. Provenance means the verified history and origin of a software artifact, and human-written code has witnesses: commit history, design docs, and an engineer who can explain why each decision was made. When AI generates the bulk of your codebase, the honest answer to "where did this come from?" is often an AI session output that nobody logged.

‍

That creates two separate problems, and the second one is the bigger of the two:

‍

• You can't cleanly prove your product didn't absorb someone else's protected expression. Absence of proof cuts both ways when an accusation lands.
• Your code is only proprietary if you can prove it's yours. Diligence teams have caught up to this. They now ask for the AI share of the codebase, which tools you used, session transcripts or telemetry, and your AI output review process.

‍

If you're raising, selling, or signing an enterprise customer in the next year, that second point is the one that costs you money.

‍

What software copyright actually protects

‍

Copyright infringement doesn't require intent. Even if you sincerely intended not to copy, if you did copy, there's potential exposure. So it helps to know what's actually protectable in the first place.

‍

Thirty-five years of case law points in a consistent direction: the closer something sits to pure function, the less protection it gets.

‍

• Whelan v. Jaslow (1986): courts protected structure, sequence, and organization. This was the high water mark for software copyright, and protection has narrowed a lot since.
• Computer Associates v. Altai (1992): established the abstraction-filtration-comparison test, which strips out function before comparing two works. Nobody owns a function. This test still governs today.
• Apple v. Microsoft (1994): courts found that desktop look and feel wasn't protectable.
• Lotus v. Borland (1996): a menu command hierarchy was found to be a method of operation, not copyrightable.
• Google v. Oracle (2021): the Supreme Court sidestepped copyrightability entirely and ruled for Google on fair use.

‍

It's easier to hold onto if you picture a spectrum running from least protected to most protected:

‍

• Function (no protection): feature sets, workflows, menu structures. Every data room has a share link. Nobody owns that.
• Structure (filtered, sometimes survives): flows, screens, organization, architecture. Anything functional gets stripped out first. Anyone can build a chat flow that quotes insurance, but copying the specific narrative and sequence of Lemonade's Maya chatbot could support a structural claim.
• Visual design (thin protection): original look and distinctive aesthetic choices. Custom artwork like Mailchimp's chimp is protected. A standard dashboard layout isn't.
• Original prose (protection depends on quantity and originality): feature descriptions and distinctive microcopy. Nobody can protect a "Send now" button. Mailchimp's distinctive send page copy is a different story.

‍

Notice where the Corgi allegations landed. Same headings, same paragraph text, same button labels, but different code underneath. That's the expression zone, and it's the one zone you cannot scan for.

‍

Reference risk: your prompts are evidence

‍

AI models are prediction engines. You describe features, and the model regenerates the decisions that are statistically most likely to satisfy what you asked for. Inside that are thousands of distinct choices: feature names, flows, screens, copy.

‍

The common misconception is that this is purely a training data problem. It isn't. Agentic coding tools can browse. Even if a model was never trained on a particular repo, the agent may have been able to access it during the session.

‍

Access matters because of how courts test for infringement. Direct proof is rare, so they rely on circumstantial evidence through a two-part test: access and substantial similarity. Your prompts speak directly to the first half.

‍

Compare these two:

‍

1. "Build me a DocSend alternative like Papermark, but for insurance."
2. "A tool where founders share files with investors and see who opened what."

‍

The first names a competitor to converge on, which is a written record that you accessed and referenced them. The second describes an outcome. Same product, very different evidentiary position.

‍

And no, you can't solve this by adding "don't copy anything" to the prompt. Models are easy to game and impossible to force into obedience.

‍

What actually works is a clean room approach: one AI session reads the competitor's product and writes a functional spec but writes no code, then a separate session implements from the spec alone. There's no source for the implementing session to reference, and you have a document trail showing it.

‍

Licenses grant access, copyright is what protects

‍

This one trips up a lot of founders. People look at an open source repo, see a LICENSE file, and assume that file is what protects the code.

It's the other way around. All original code is protected by copyright the moment it's written. A license is what grants you conditional permission to use parts of it. No license, no permission at all.

Papermark is a useful example because it uses a dual license setup that's common in commercial open source. Everything under the ee directory (short for Enterprise Edition) carries a separate commercial license. Everything else is AGPL 3.0.

Why AGPL exists: regular GPL copyleft only triggers on distribution, meaning a downloadable binary. Most SaaS products aren't downloaded, so that obligation never fires. AGPL was written to close that gap for software users interact with over a network.

‍

What that means practically:

‍

• AGPL has a compliance path. Use the code unmodified, or open source your changes. Section 13's modification trigger means the obligation to share source attaches when you change the original software. Modify AGPL code and deploy it in a proprietary product, and the license terminates, which puts you straight into infringement.
• A commercial license only exists if you bought it. No Enterprise Edition subscription, no license, no permission. It's that simple.

‍

When Samuel traced the Papermark repository, he found that the "danger zone" settings page composes both at once: the delete functionality comes from a core AGPL component, and the freeze functionality comes from a commercially licensed enterprise component. On one screen.

‍

Nobody outside Corgi has seen Corgi's codebase, and nobody outside it will. But it does mean the "it's just a settings page, settings pages are functional" defense is doing more work than it looks like.

‍

How to audit your AI-generated codebase in six steps

‍

This is the part you can act on. None of it requires a lawyer and most of it fits in an afternoon.

‍

1. Build a reference log

‍

Create a simple three-column table: one row per feature, what it was built from, and the risk level of that decision.

It looks almost too simple to matter, and that's the point. Scanning tools only cover the literal zone, meaning exactly copied code. The reference log is the only thing that covers lookalikes, and it answers the diligence question you can't scan your way out of.

‍

2. Run a license scan

‍

Scan your full dependency tree, including transitive dependencies. ScanCode is a widely used open source option, and Snyk covers this commercially.

Most rows come back fine. The value is in the two that don't, which is usually copyleft code or something explicitly copyrighted sitting inside a product you sell. Run it once manually, then automate it weekly, because you're adding new dependencies constantly.

‍

3. Do a comparable check

‍

Go screen by screen and compare your copy against your closest competitors. Three quick examples of what you're sorting for:

• "Secure document sharing" is functional and generic. Nobody owns it. Keep it.
• "This action cannot be undone" as a word-for-word match is worth rewriting, even though it feels trivial.
• The same idea in genuinely different words is fine. Keep it.

This is tedious, and it's also the step that would have prevented the screenshots in the Corgi thread.

‍

4. Check your AI tool's indemnification terms

‍

Some AI coding tools, usually the paid or enterprise tiers, carry IP indemnification. Many also have a setting that allows or blocks suggestions derived from public code.

Here's the catch: on some products, leaving public code suggestions enabled voids the indemnification. You lose the protection you're paying for. Read your specific terms, and if that setting exists, turn the blocking on.

‍

5. Name your moat

‍

Say out loud what makes your product hard to copy. If the answer is your UI, you don't have a moat. A beautiful, dead simple dashboard takes a weekend to regenerate now, and everybody knows it.

In fintech, durable moats are the things that are hard to regenerate:

• Proprietary data flywheels, like underwriting logic tuned on real loss experience.
• Regulatory approvals, like a broker-dealer license or state lending authority.
• Deep integrations with systems that took years to wire up correctly.

This matters in both directions. If your differentiation is look and feel, someone can do to you exactly what Corgi was accused of doing to Papermark.

‍

6. Install one question between build and ship

‍

Add a single checkpoint to your release process: what did this borrow, and are we licensed for it?

It takes five minutes. It's a very good five minutes on the occasions when the answer isn't yes.

‍

Run the whole thing from a checklist

‍

Those six steps expand into 33 specific items, and working from a list beats working from memory when you're checking your own product.

‍

We put them into a free AI Codebase Audit Checklist you can run yourself. It walks you through each step in order and gives you a verdict at the end, so you finish knowing where you actually stand rather than with a vague sense that you should probably look into it.

‍

Download the AI Codebase Audit Checklist →

‍

When to stop and call a lawyer

‍

The audit above is an engineering process. There are four situations where you should hand it to counsel instead:

‍

1. You receive a cease and desist or a demand letter.
2. You're publicly accused of copying, in any venue, including a tweet.
3. A license scan finds copyleft code inside a product you sell or distribute.
4. You're launching directly against a known open source incumbent.

‍

That last one is the cheapest to catch, because you know it's true before you write a line of code.

‍

The real liability isn't AI

‍

Building with AI isn't the problem, and none of this is an argument against it. At TechSuite we build and orchestrate AI agents across every client engagement.

‍

The claim that doesn't survive contact with a diligence team is "AI wrote it from scratch, so it's mine." That can't be proven without a process behind it. Corgi may turn out to be completely right on the facts, and it will still have spent time, legal fees, and reputation on a question that a five minute checkpoint could have closed.

‍

Start with the reference log and the license scan this week. Those two alone move you from "we think we're fine" to something you can hand to an investor.

‍

If you'd rather not run it yourself

‍

Plenty of founders read all this, agree with it, and still don't have anyone on the team who can go screen by screen through a codebase they didn't write. That's a fair place to be.

‍

TechSuite runs technical due diligence audits for fintech startups, and this is exactly what they cover: license scanning across the full dependency tree, a comparable check against your closest competitors, a reference log reconstructed from what's actually in your repo, and a written verdict on where your exposure sits. It's a fixed fee, so you know the cost before you start.

‍

And if you decide you want us to fix what we find, we credit that fee against the engagement.

‍

Request a technical due diligence audit →