There’s no need to be an ass about it. I didn’t say this is definitely slop, but it is unsurprising that people think it is. I don’t think it’s without merit to wonder if someone committing 12 million lines of code within a few weeks is using AI.
The Internet archive has a version of the post that i believe has what you’re talking about still in it. Strange that it’s been edited out of that post
The section about LLM usage
The LLMephant in the room
Fluxer came from about five years of work.
If you have used Fluxer and know the limits of LLMs, this should be obvious. Software this large only reaches this level of quality when a competent person keeps working on it over time. In Fluxer’s case, that means years of on-and-off development, testing, reworking, and learning from real users. Most of the core product predates LLMs becoming a normal part of software development, and the architecture, data model, protocols, safety decisions, technical choices, and sense of what Fluxer should be are mine.
Many models were trained in ways I disagree with, and I dislike the direction most AI companies are taking. More recently I have preferred local open source models where they are good enough, because the tool exists either way and I use it on my own terms.
The closest way to describe it is as a second brain. When the codebase is large and the problem is subtle, it helps to have something that can sit with a crash log, a failing test, or a rough specification and help me think through where to look next. That can save time on the slow, repetitive parts of the work without changing who is responsible for the result.
The important part is that I stay in control. I decide the architecture, shape the specification, review the change, run the tests, and make sure it fits the surrounding system. If I cannot explain the change, I cannot ship it. Every change still has to preserve code quality, handle failure cases, and fit the product.
That is especially important because Fluxer is a real product with real-time delivery, media processing, billing, moderation, abuse prevention, and user safety concerns. LLMs can improve my throughput while the bar stays the same.
The clean commit history has a simpler explanation. The early work happened privately over more than three years, and I squashed it when Fluxer moved from closed development to public source. That is normal for a closed-to-open transition.
The contributor policy follows the same principle:
Understand every change in your PR. You should be able to explain what it does and why it is correct.
Keep AI-generated text out of bug reports, pull request descriptions, and GitHub comments, except for direct translation if English is not your native language.
If you use LLMs for coding help, disclose it. The contribution still needs to be understandable, reviewable, and tested well.
Contributors are welcome. As more people work on Fluxer, LLMs should become less important to day-to-day development.
With enough donations, Fluxer can offer bounties for specific work. My goal is to make Fluxer sustainable and community-developed.
Q: But a random stranger on an internet forum told me it is!
Oh well, then it has to be true, right?
Q: I still don’t trust you!
If you have used any vibecoded software before you’ll know that Fluxer is too good to be that. Trust your own feeling when using the app and when reading the code if that’s your sort of thing, not karma-seekers on Reddit, is my piece of advice.
I think “vibecided” is intentionally used. I remember the post I referenced talking about him using it for tasks, but then checking the code. I don’t think that’s technically vibe coding, but intentionally not disclosing any AI use is concerning to me.
A meaningful distinction to me at least is that when I’m vibecoding a one-off personal project I don’t care about, I don’t even look at the code.
When I’m using LLMs on a serious project that matters, I never blanketly give it a task to write code. Debugging and investigation work is more “go do the thing” vibecody, but when it comes to actually implementing fixes or features: I’d only ever use an LLM when I already know what the code should look like. And most of the time, when I’m writing in a language that I’m not perfectly familiar with, it’s writing as good as me if not better. Its a flat win case. In something like C++, I have a particular style and am very pedantic, and I know the standard very well, and so I tend to need to handhold and fix or rewrite a lot more. The vast majority of programmers who write C++ don’t write like I do, and I’m willing to bet that my “like me or better” statement about languages I’m only intermediate in applies to most casual or junior C++ devs.
With that said, his diff seems to have a hell of a lot of additions. I’d be willing to bet if he’s using Frontier LLMs that the vast majority of that is testing (and comments if they use claude…)
I think if someone has a hard no-AI stance, then it’s probably just safe to avoid the project. Whether or not it’s “vibecoding” depends a lot on their workflow and their standards.
If I need to write 10,000 lines, and I know what it should look like, and the AI produces that: I see no reason why I should waste my time typing it all out by hand. With that said, “Bot, go implement XYZ” isn’t how I or most experienced devs work with AI, and that’s where a lot of problems come from.
The good news is that it’s mostly a self-solving problem, because those codebases become completely impossible to work in over time.
AI was used in the development of this app because of course it was.
Where did you see that?
look at the Git repo, they have outputed more code in 2026 than I will ever type out in my lifetime.
Fluxer is PURE slop. 1.5 million lines commuted in one month by one person is obviously not human made.
12m lines of code committed in the last 3 months (the bulk of that within the last month) by one committer doesn’t exactly scream human input.
You’re right. Code generators, formatters, static analyzers, vendoring exist btw.
Not human input != LLM
Are there any actual software engineers in this thread. 😅
There’s no need to be an ass about it. I didn’t say this is definitely slop, but it is unsurprising that people think it is. I don’t think it’s without merit to wonder if someone committing 12 million lines of code within a few weeks is using AI.
It was in a blog post on the site that’s conveniently missing now.
The Internet archive has a version of the post that i believe has what you’re talking about still in it. Strange that it’s been edited out of that post
The section about LLM usage
The LLMephant in the room
Fluxer came from about five years of work.
If you have used Fluxer and know the limits of LLMs, this should be obvious. Software this large only reaches this level of quality when a competent person keeps working on it over time. In Fluxer’s case, that means years of on-and-off development, testing, reworking, and learning from real users. Most of the core product predates LLMs becoming a normal part of software development, and the architecture, data model, protocols, safety decisions, technical choices, and sense of what Fluxer should be are mine.
Many models were trained in ways I disagree with, and I dislike the direction most AI companies are taking. More recently I have preferred local open source models where they are good enough, because the tool exists either way and I use it on my own terms.
The closest way to describe it is as a second brain. When the codebase is large and the problem is subtle, it helps to have something that can sit with a crash log, a failing test, or a rough specification and help me think through where to look next. That can save time on the slow, repetitive parts of the work without changing who is responsible for the result.
The important part is that I stay in control. I decide the architecture, shape the specification, review the change, run the tests, and make sure it fits the surrounding system. If I cannot explain the change, I cannot ship it. Every change still has to preserve code quality, handle failure cases, and fit the product.
That is especially important because Fluxer is a real product with real-time delivery, media processing, billing, moderation, abuse prevention, and user safety concerns. LLMs can improve my throughput while the bar stays the same.
The clean commit history has a simpler explanation. The early work happened privately over more than three years, and I squashed it when Fluxer moved from closed development to public source. That is normal for a closed-to-open transition.
The contributor policy follows the same principle:
Contributors are welcome. As more people work on Fluxer, LLMs should become less important to day-to-day development.
With enough donations, Fluxer can offer bounties for specific work. My goal is to make Fluxer sustainable and community-developed.
Here is what it says in the FAQ:
I think “vibecided” is intentionally used. I remember the post I referenced talking about him using it for tasks, but then checking the code. I don’t think that’s technically vibe coding, but intentionally not disclosing any AI use is concerning to me.
Yes, overly specific denial is sus.
A meaningful distinction to me at least is that when I’m vibecoding a one-off personal project I don’t care about, I don’t even look at the code.
When I’m using LLMs on a serious project that matters, I never blanketly give it a task to write code. Debugging and investigation work is more “go do the thing” vibecody, but when it comes to actually implementing fixes or features: I’d only ever use an LLM when I already know what the code should look like. And most of the time, when I’m writing in a language that I’m not perfectly familiar with, it’s writing as good as me if not better. Its a flat win case. In something like C++, I have a particular style and am very pedantic, and I know the standard very well, and so I tend to need to handhold and fix or rewrite a lot more. The vast majority of programmers who write C++ don’t write like I do, and I’m willing to bet that my “like me or better” statement about languages I’m only intermediate in applies to most casual or junior C++ devs.
With that said, his diff seems to have a hell of a lot of additions. I’d be willing to bet if he’s using Frontier LLMs that the vast majority of that is testing (and comments if they use claude…)
I think if someone has a hard no-AI stance, then it’s probably just safe to avoid the project. Whether or not it’s “vibecoding” depends a lot on their workflow and their standards.
If I need to write 10,000 lines, and I know what it should look like, and the AI produces that: I see no reason why I should waste my time typing it all out by hand. With that said, “Bot, go implement XYZ” isn’t how I or most experienced devs work with AI, and that’s where a lot of problems come from.
The good news is that it’s mostly a self-solving problem, because those codebases become completely impossible to work in over time.
I will ask him about it. He is active in the “Fluxer HQ”.