An AI-Built App Turned Out to Be an Accidental Clone, Bug and All: The AI Code Plagiarism Check It Skipped

Last week, developer Terry Godier used Claude to build Dark Hours, a small web utility that shows what is currently visible in the night sky. He shipped it, started planning an iOS version, and moved on. Then another developer messaged him on Bluesky. He had built and open sourced an app with the same name, DarkHours.app, months earlier. Godier's version was not just similar in concept. It reproduced a bug the original developer had already found and fixed. That single detail is what makes this worth an AI code plagiarism check story rather than a footnote about naming collisions.

Godier published a full public apology the next day. He redirected the Dark Hours domain to the original DarkHours.app, canceled his iOS expansion, and wrote plainly: "I was careless in relying on AI to generate the project without doing the work to understand whether it closely resembled an existing project." He also said he is done using AI this way for web projects going forward, though he still uses it for iOS debugging rather than full builds.

What actually happened

The mechanism here matters more than the apology. Godier did not copy DarkHours.app's code by hand, and there is no evidence Claude was trained specifically on that repository as a targeted source. What happened is closer to convergence: given a similar prompt (show visible night-sky objects, in a browser, right now), a coding model can land on strikingly similar structure and logic to whatever prior art shaped its training data, without the person prompting it ever seeing the original.

The bug is the tell. Independent convergent design can plausibly produce similar architecture. It is much harder to independently reproduce a specific defect that someone else already found and patched. A shared bug is the software equivalent of a mapmaker's trap street, a deliberately fake detail inserted into an early map or directory specifically so that if a rival's version contained the same fake entry, it proved copying rather than independent surveying. No "we built this separately" claim survives a shared fabrication, or a shared bug, that could not plausibly arise twice by coincidence.

Why this slips through most workflows

The core problem for anyone doing vibe coding, meaning building real, shippable software mostly by describing what you want rather than writing every line, is that the model has no mechanism to flag when its output resembles someone else's existing work. It hands back code that reads as original because you did not personally write it line by line, and there is no equivalent of a spell-checker's red underline for "this pattern already exists, attributed to someone else."

That gap does not show up when you are using AI to debug a function inside a codebase you already own and understand. It shows up specifically when AI is generating a new project from a prompt, the exact situation where you have the least independent basis for judging whether what you got back is actually novel. Godier's own account draws that line for himself: he is stopping the practice for from-scratch web projects, not for AI-assisted debugging inside code he already wrote.

An AI code plagiarism check you can actually run

The due-diligence step missing from Godier's workflow, and probably from most people's, is not complicated. Before you ship anything an AI built for you from a prompt, especially anything with a name, a public URL, or a specific enough niche that prior art likely exists:

• Search before you launch, not after someone messages you. A plain search for the product name plus "app," "GitHub," or "open source," and a search for the specific niche it serves, takes two minutes and would have caught this before launch, not after.
• Read the code you are about to ship, at least once, end to end. Not to rewrite it, just to know what is actually in it. If you cannot explain why a specific function is structured the way it is, you also cannot vouch for whether it is original.
• Ask the model directly whether your idea resembles known existing projects, and treat the answer as a starting point, not a clearance. Models are not reliable at flagging resemblance to their own training data, but a direct question sometimes surfaces a name or category you had not searched for yet.
• Treat a public launch differently than a private build. Internal tools and personal scripts carry low originality risk. Anything with a name, a domain, and a public audience carries the same due-diligence bar as work you would publish under your own byline, because reputationally, it is exactly that.

None of this is about whether AI-assisted code is legally risky in some abstract sense. It is about the much more basic professional standard Godier named himself: doing the work to understand whether what you are about to publish resembles something that already exists, before you publish it rather than after.

What this means if you build with AI

The people getting burned by this are not doing anything unusual. Using a coding model to build a full small app from a prompt is now a completely normal workflow, and it produces working software fast enough that the temptation to skip verification is real. The lesson from Dark Hours is not "stop using AI to build things." It is that AI-generated code needs the same basic originality check a human collaborator's work would get before you put your name and a public URL on it. The model will not flag the resemblance for you. That check still has to be a step you run yourself, on purpose, every time.

Source: Terry Godier, "Mea Culpa: Dark Hours," August 9, 2026