Ha, the irony isn’t lost on me. But the comment was mine, not generated. The project does use LLMs as a tool (that’s the point of it), but “uses LLMs” and “is slop” aren’t the same thing. The repo is public if you want to check the commit history and structure rather than take my word for it.
Fair point, I’ll own it. Dropping a project link in a thread about slopcode is going to read as a pitch, and I needed to promote or nothing will ever happen.
That said, I figured showing a concrete example was more useful than just adding another opinion to the pile. If you want to pull the repo (https://git.opensourcesolarpunk.com/Circuit-Forge/peregrine), the structure is there to review. There’s a deterministic pipeline underneath the LLM layer (eligibility checks, form validation, deadline tracking all run without LLM involvement), CI with test coverage, and a fine-tuned model approach that keeps inference on local hardware where possible.
The hard part wasn’t the LLM layer, it was the plumbing around it that keeps the LLM in an advisory role instead of a decision-making one. That design constraint is what I wanted to show, not just “look, I made a thing.”
The pre-LLM-effort-was-a-filter argument holds up, but I think what effort was really filtering for was why someone built the thing. High effort filtered out “this seemed fun for a weekend” projects. LLMs just surfaced that those were always the majority.
The better filter is: does this project serve a specific audience that genuinely needs it, or is it a demo of what you can do with Claude?
What I look for now:
We build CircuitForge, self-hosted tools for navigating opaque systems (job markets, government benefits, insurance). The architecture is deterministic-first: eligibility checks, validation, and data pipelines are rule-based and grounded in structured data, so the LLM is drafting from a clean, repeatable foundation rather than hallucinating into a void. That also means we can run smaller, specifically fine-tuned models instead of throwing a frontier model at everything and hoping for the best. Smaller models run on consumer hardware, which cuts hosting cost and shrinks the privacy risk surface significantly. Humans approve before anything acts. Pipeline layer is MIT and lives on Forgejo. There’s a full devops stack, a real business model, and I use these tools every day. We’re also actively collaborating with other devs and always looking for contributors.
The people using these tools actually need them. That’s the commitment signal that doesn’t evaporate when the novelty wears off.
Search for “Thiel Dialogue Leaks” for more nightmare fuel to read
Ah, well you see the explanation for that is pure ignorance. I’ve only ever used handbrake myself and was trying to help another friend who apparently uses makeMKV wrong or something or is bad at explaining to me xD
Sure, but that takes a lot of time and effort when you have a complicated stack, so it’s nice to be able to handle it in two clicks instead of setting up an entire encode queue while cross referencing all my metadata so I get episodes mapped right. Often a series session will take me upward of 30 minutes to set up an encode queue manually. With Discarr, it takes me 30 seconds
Edit: this came out of many attempts to create a single script that could post-process torrents, unpacking archives or converting disk images dynamically. The trouble is that dvd formatting for series follows no standards whatsoever, and really requires a human to map the titles. Discarr automates everything except that, and surfaces the title and episode queues side-by-side to allow quick identification and assignment
Sonarr/Radarr occasionally grab disk rips as they’re the only format available for certain titles, but they can’t be directly imported without conversion. This fills that gap cleanly.
Also, fair warning: my day job involves writing docs and reports for corporate clients, so the LinkedIn voice leaks in whether I want it to or not. Working on it.