When Your AI-Generated App Turns Out to Be Someone Else's, Bug for Bug

Last updated: August 9, 2026

Last week Terry Godier, the maker of the RSS reader Current, launched Dark Hours, a web app that shows what is visible in the night sky. Yesterday he took it down, redirected the domain to someone else's project, killed his plans for an iOS version, and published a public mea culpa. The reason reads like a cautionary tale for anyone shipping AI-generated products: the app he built with Claude turned out to be strikingly similar to an existing open source project called DarkHours - so similar it reproduced a bug the original author had already fixed.

The story is messier and more interesting than the apology post alone, and it has become one of the most-discussed developer threads of the weekend. Here is what actually happened, what the community is arguing about, and what every team using coding agents should take from it.

What the Sources Say#

The timeline, reconstructed from the primary sources:

January 2026. Godier submitted an app called Asterly to the App Store. Per the Daring Fireball retraction, the app was entirely dedicated to astrology and included a "Tarot card of the day" feature. Apple rejected it under the guideline that blocks new fortune-telling apps, and the App Review Board upheld that rejection in April.

Early August. Godier ported the astronomy side of the project to the web, launched it as "Dark Hours" at darkhours.io, and built it with Claude. On August 7 he published "Browsers Have Standards, the App Store Has Judgment" claiming his astronomy app had been wrongly rejected for astrology, with no tarot function and nothing anyone would associate with the category.

August 7-8. John Gruber at Daring Fireball wrote his "App Store Rejection of the Week" post based on Godier's account. Meanwhile Miguel Beher, creator of the open source DarkHours, an astrophotography and dark-sky planner at darkhours.app, pointed out the similarity on Bluesky - same name (space vs. no space), same feature set, and a shared bug that routed people to random fields in Mexico, a bug Beher had already fixed in his own code.

August 8-9. Godier edited his post to correct the App Store story (the app had in fact begun as an astrology app), took down the web app, redirected darkhours.io to darkhours.app, abandoned the iOS plans, and published the mea culpa. In it he writes that he had never seen DarkHours.app before, that he was careless in relying on AI without understanding whether the result resembled an existing project, and that he will not use AI to create web stuff this way going forward. Gruber, discovering he had been misled, retracted his post in full - by his own account the first retraction in 24 years of Daring Fireball - and preserved the original text for transparency.

The key factual claim for developers: a model-generated app, built on a generic "night sky website" idea, came out with the same name, the same feature set, and a bug that only existed in the original project's history. That is what a training-data fingerprint looks like in production.

What Developers Are Saying#

The discussion around the story split into roughly four camps.

The plausibility split. A large group of developers flatly refused to believe the model spontaneously recreated another project bug-for-bug, same name and all, without the prompts steering it there. The counterpoint came from developers who work with open source training data daily: the original DarkHours is public code on a popular platform, it sits in model training corpora, and a "build me a night-sky web app" prompt is exactly the kind of request that can surface memorized structure. The detail they kept returning to was the bug. A model that was re-implementing from a description would not reproduce an already-fixed bug. Only memorized code carries an author's fixed bug with it.

The accountability test. The strongest through-line was about responsibility, summarized in one common formulation: we are personally responsible for what our agents do. Several commenters noted that "Claude did it" now plays the role that "the computer did it" played decades ago, and that blaming the tool for the operator's launch decision does not survive contact with the work. If a mechanic mis-torques your lug bolts, "it was my first time with a torque wrench" is not a defense; the same logic applies to shipping whatever your agent produces without review.

Credit for the cleanup. Not everything was negative. The redirect, the shutdown, the apology, and the unusually complete retraction with the original preserved were read by many as how you own a mistake. The fact that a 24-year-old publication retracted in full, rather than quietly editing, drew genuine respect - alongside jokes about whether we are watching the first of many such retraction cycles.

The practical quibbles. A few commenters noted the domain was redirected, not transferred, so users who memorized the .io address could be stranded when it expires. And several pointed out that the model tools they use attach attribution links when adapting code from a repository, which made the absence of any such trace here harder to square with the "unaware" account.

Why This Matters for Developers#

Strip away the App Store drama and the apology, and this is the cleanest public demonstration we have had of what memorization looks like when it ships. Same name, same feature set, same fixed bug: the bug is the fingerprint. It is the difference between a model writing fresh code and a model replaying code it has seen, and it is exactly the failure mode every AI-assisted team needs a process for.

Three practical takeaways:

1. Provenance review is now part of the job. When an agent writes your feature, you review it for correctness, performance, and security. This story says you also review it for provenance: search your own product name before launch, search the category, and treat any code that feels familiar as a lead to investigate, not a coincidence. That is the same discipline as reviewing a dependency you are about to add, and we have covered the trust-boundary framing before in npm supply chain trust for agents. The name and the bug are the cheap signals; the expensive ones live in the diff.

2. Attribution needs forensics, not vibes. We argued exactly this in AI code attribution needs defect forensics: a "generated by AI" label answers nothing about where the code came from. The bug-for-bug reproduction is the rare case where the evidence is unambiguous. Build the habit of diffing generated output against similar public projects in the same niche before you ship, and record what you checked.

3. Your name is on the release. The community's reaction was unforgiving toward the "the model did it" framing, and that is a durable signal: audiences judge the operator, not the tool. The good news is that the bar is not heroic - it is search, compare, and question. As we wrote in what Hacker News gets right about AI coding agents, the community has developed consistent instincts about agent use, and the instinct here is: agents accelerate, but they do not absolve.

The other lesson is about AI slop more generally. When a product looks generic, the public increasingly assumes it is AI-generated and checks whether it is a copy of something else - spotting the slop is becoming a reader skill as fast as producing it is a developer shortcut. The teams that will keep trust are the ones that treat originality as a checklist item with the same seriousness as a code review, the same way we have seen human maintainability debates push teams toward real review processes.

In the end the story resolves the way the community wanted it to: the copy came down, the original got the traffic, and the author took responsibility in public. That is the right outcome. The durable takeaway is that when your agent ships something that looks familiar, it probably is familiar - and checking is a five-minute habit with a very expensive failure mode.

FAQ#

What happened with the Dark Hours app?#

Terry Godier launched Dark Hours, a night-sky web app built with Claude. Miguel Beher, creator of the open source DarkHours project, pointed out that it had the same name, the same feature set, and a bug that routed people to random fields in Mexico, which Beher had already fixed in his own code. Godier took the app down, redirected the domain to darkhours.app, dropped his iOS plans, and published a mea culpa.

Why does the shared bug matter so much?#

A model re-implementing an app from a description would not reproduce a bug that only existed in another project's history. Only memorized code carries an author's already-fixed bug with it, which is why the post calls the bug the fingerprint of memorization.

How can developers check AI-generated code for provenance before shipping?#

The post recommends searching your own product name and the category before launch, treating code that feels familiar as a lead to investigate, diffing generated output against similar public projects in the same niche, and recording what you checked.

Who is responsible when a coding agent reproduces someone else's project?#

The operator. The community reaction rejected the "the model did it" framing: audiences judge the person who shipped the release, not the tool, and agents accelerate the work without absolving the person who launches it.

Continue Reading#

• AI Code Attribution Needs Defect Forensics, Not Vibes
• AI Design Slop and How to Spot It
• What Hacker News Gets Right About AI Coding Agents
• npm Supply Chain: Trust Boundaries for AI Agents
• The AI Code Human Maintainability Debate

Sources#

• Mea Culpa - Dark Hours (Terry Godier, Aug 9 2026)
• Browsers Have Standards, the App Store Has Judgment (Godier, Aug 7 2026, with correction note)
• Daring Fireball: Retraction - The App Store Rejection of the Week That Was, in Fact, a Correct Rejection (John Gruber, Aug 8 2026)
• Original retracted post, preserved in plain text
• Miguel Beher's Bluesky post on the shared bug
• Godier's Bluesky launch thread
• GitHub: mbeher2200/DarkHours
• DarkHours.app