The second link in the body of OP is the dev explaining that he’d been working on it in his spare time for 5 years before releasing it as a public beta on Github.

He does mention using AI in a limited capacity.

Fluxer was largely built before LLMs became a normal part of day-to-day development. I do use them now, but in a limited way: as a rubber duck and for mechanical implementation work when I already have a detailed spec. I treat the code it outputs like I would any external contribution.

No LLM designed the system, wrote the specs, or made architectural decisions. That was all me. I only use LLMs when I already know the platform well enough to review the result properly.

Ultimately, you’ll have to take my word for it that I’m trying to handle this responsibly. Fluxer is a large, complicated codebase because the project itself is large and complicated. LLMs still aren’t capable of autonomously producing anything like what Fluxer is today.

If it were that easy to create something this polished on a whim using only LLMs, we’d already be swimming in credible Discord alternatives.

In short, for Fluxer: PRs should be reviewable, understandable, and test-backed. Submitting generated code you cannot explain, or using an LLM to bypass review standards, isn’t acceptable. At the same time, responsible use of LLMs as a tool is fine, and contributors should not be harassed for using them.

Moreover, the OSS release began from a clean slate, so the public commit count doesn’t reflect the full private iteration timeline, how long it has been deployed in production, or how extensively it has been tested. Going forward, what matters is that contributions will be reviewed, and tests will be required where appropriate. I also don’t condone low-effort, unreviewed AI slop.

I published the project with a squashed history because the early work happened privately, and I didn’t want to make 3,000+ messy commits part of the public record. I’m proud of where things are now, and the codebase has improved a lot over the 3+ years it was developed in private. Squashing commits during a closed source to open source transition is common practice, and it doesn’t imply the project was vibe-coded.