I read their "why use our fork" page, and it's very obviously AI-written, which causes me to distrust it.
As a happy Immich self-hoster, I'm not excited by the idea of switching to a fork written by folks who can't even be bothered to write their "why this fork exists" explanation themselves. It inspires very low confidence both in the quality of the many additions (because of the vibecoding) and the long-term sustainability of the project (because of the lack of any effort, and because vibe-coded one-offs tend to die faster than labors of love).
Buried at the very bottom of the wall of slop text on their "why our fork" page is this very last "FAQ" question:
>Why fork at all instead of upstreaming features?
>Several Gallery-exclusive features (Shared Spaces, Pet Detection, contextual filters) were either declined upstream, considered out of scope, or required architectural changes that wouldn't have fit Immich's roadmap. Forking lets us experiment without slowing down the upstream team — and rebasing means we never lose touch with their progress.
There's no mention there of "our vibe-coded implementations of these features were declined by upstream because we vibecoded them"; instead, they frame it as "upstream doesn't want these features for their users", with a dash of "upstream has made bad design decisions" (particularly the note about how upstream Immich "required architectural changes").
That's more than a little disingenuous on "Noodle Gallery's" part.
You’re reading that into it. That is not what it says.
So far the Noodle communications feel considered, professional and friendly (that’s what a Claude sub buys you), while the Immich communication is just “vibe coded”.
Okay - is the code bad? Are you collaborating to improve it? The answer appears to be no, for reasons hopefully better considered than “vibe coded”.
Of course. We have many big items on our roadmap[0], and just recently in our latest minor[1] we released a new search query API and the first piece of many sharing improvements.
Please consider communicating it more like that rather than putting the focus on the process of the creation. This saves you some irritation by people like me who find it weird and unproductive to do the latter.
Additionally, the author claims to not have vibe coded the features, so some of your credibility is on the line here in claiming they did.
Sometimes, certain processes strongly predict bad outcomes, though.
If someone told me to choose between two barbecue restaurants, where one used an wood-fired smoker and the other used a microwave, my reaction wouldn't be "you really shouldn't judge based on just the process." The microwave is a sufficient indicator of low quality.
Vibecoding (as distinct from using AI as a resource while writing better code yourself) is the microwave: fast, hands-off, low-effort, low-quality.
