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.
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.