(Yet another) category suggestion: LLMs

The use of LLMs is divisive in the world at large right now.

Both sides of the divide are well-represented by the Haskell community.

Some people find LLMs abhorrent and don’t want to have to look at anything LLM-adjacent.

Some people like to share and discuss LLM usage and LLM-driven projects.

I figure if we at least had a category for it, the former could get an automatic content warning, and the latter wouldn’t have every discussion turn into an argument over their choice to use an LLM.

I think the alternatives are worse. The status quo is exhausting. A separate forum is divisive and duplicates a lot of work.

That said, I don’t pretend to think this suggestion will go down easily. I hesitate to even post it, because I know I’ll catch flak for asking to “encourage the use of LLMs” or something. I’m fine with not encouraging it. But it’s happening, anyway. Neither side of the divide is going away.

I’m interesting in finding ways of keeping the community cohesive in spite of the divide. Carving out a designated space of this shared resource seems like one such way.

17 Likes

I don’t think this is a problem that can be solved with categories. The vibecoding tag on Lobsters exists and has several problems:

  • People use it to filter out content, so it gets over applied. If a submission is even vaguely adjacent to LLMs, it will get tagged as vibecoding.
  • On the flip side, if you are interested in LLM topics, the tag is ineffective because there’s no way to distinguish “explicitly about LLMs” from “tangentially related to LLMs”.
  • Due to a combination of the above, discussion about the vibecoding tag runs rampant. Threads frequently re-litigate the appropriateness of the tag, and meta submissions pop up frequently.

Of course the Haskell Discourse is not Lobsters, so things could play out differently. But I feel that the two groups (very roughly “LLMs are great, let’s use them for everything” and “I don’t want to see anything about LLMs at all”) are mutually incompatible. Trying to quarantine the former into a category won’t appease the latter.

5 Likes

I think it’d be neat if any post whose OP has LLM-generated content is tagged with that. I like that as a rule mostly because it’s pretty crisp and well-defined. And the descriptor is objective.

vs the Lobsters vibecoding tag which is not an actual description and is somewhat pejorative/hyperbolic.

5 Likes

We’re working on enabling tags and requiring LLM related posts to be tagged as such. People who do not want to see such posts can then ignore those tags. On the flip side, we will be more strict in moderating general criticism about the LLM use itself in posts with that tag, that kind of discussion should then be done in separate topics.

(I think tags are better than a category, because you might still want to put your posts into announcements/learn/links.)

6 Likes

I think it’s fair to raise this. I believe, probably, that we’ll see communities split down this line and they won’t overlap anymore. E.g. language specific forums (such as this one) and aggregator sites like Lobsters, will probably end up with different domains and different user bases. The same person might login to both, but aware that they’re entering different types of spaces.

I don’t think that’s dramatic. Static typing vs dynamic typing is a familiar divide. The other one that comes to mind is proprietary vs free software ecosystems, which roughly overlaps with the windows/mac/linux-bsd divide. Some Windows programmers can spend a whole productive career just using the .NET ecosystem, writing their PowerShell scripts, and make good money. Likewise others spend their career on open source systems and actively avoid the other on principle where possible.

Given that the mainstream is all-in on LLM use, I suppose non-LLM communities will have to perform such splintering themselves. I don’t think it’s something that moderation is able to deal with. I’m not sure many communities will be recognisable eventually. So much platform splintering has already take place before the AI summer took off, that many communities are already spread thin.

Not to be a Debbie Downer! I think I’m just equally as bored of the endless LLM debates in various platforms and it’s slowly pushing me away from the Haskell Discourse and lobste.rs — which are the only social platforms I look at anymore. I’m becoming disengaged.

3 Likes

You may be right regarding the future. But today the split is still much less clear-cut than what you describe.

Social media tend to attract the extremes, as usual. In real life I see a much more nuanced situation. Lots of people still oscillate between different practices. I myself use LLMs quite regularly, but still write code manually when I think it’s more appropriate. And the whole LLM world is still too unstable to draw any conclusions. Honestly I think most people are still in “let’s wait and see” mode. Those who are already convinced are just louder.

3 Likes

I think a separate category is a great idea.

I’ve been using LLMs quite extensively at work on a new Haskell product we’re developing. We’ve gone with Haskell because there’s an existing Haskell product that’s over 10 years old but we’re taking a fresh approach so that’s allowed me to use modern libraries like servant and more interestingly miso for a Haskell frontend compiled to webassembly (which would have been very difficult to impossible ten years ago).

I’ve prototyped the frontend UI using LLMs and it being Haskell, the code isn’t as terrible as one would expect vibing out code with Luna. This is partly because I was far more careful designing the backend ensuring that I have a well typed Servant interface with Autodocodec defined serialiser/deserialisers etc.

I’m working on fixing some warts in the ecosystem, particularly about how to share code between backend native and frontend webassembly compile. For this sort of library work the LLMs are largely useless, like hyperactive kids they’re better at making a mess than cleaning it up, so I’ve got to gone back to old school reading type signatures and writing code.

But at some point it’s hopefully in the state where I can demo how to vibe up half decent backend+frontend applications in Haskell, with the compiler basically forcing LLMs to make at least somewhat maintainable code.

But some people really dislike this sort of stuff and they have their reasons. Those reasons I may not necessarily agree with but they’re often not unreasonable objections.

Given the thread of doom that resulted recently from the mere discussion of a GHC policy on LLM contributions, I’d be hesitant about posting an article about say “how to effectively use LLMs to generate Haskell code”, because I wouldn’t be surprised if the discussion turns into “whether LLMs should be used at all?”.

Different spaces create different contexts. If someone was on a lifestyle forum and posted about their favourite cigarettes, then perhaps it wouldn’t be unreasonable for someone to bring up the health impact of smoking.

But instead if it was a cigarette and cigar forum, I think most people would understand that it’s unreasonable to go there and rant about all the ways smoking is killing people on every forum post.

Both the lifestyle forum users and the smokers win from the separate spaces, as one side doesn’t want to see posts about smoking and the other side doesn’t want to see posts about cancer. Although maybe some people are happy to interact with both.

So some sort of LLM tag, that basically says “This is for discussion about how to use LLMs most effectively, not whether they should be used at all/moral/ethical/environment concerns” I think will be a positive thing, particularly then because others can use it both as a filter and also what the social expectation is around the discussion.

5 Likes

While there’s definitely radical no-LLM views, I think the divide is strongest when it comes to “generative AI” and the meat-proxy phenomenon: interacting with generated issues and pull requests, colleagues dumping AI answers in slack channels or emails. People showing off their vibe-coded projects, which is incredibly boring.

That’s why I’m not quite sure how the no-LLM community would rebrand itself. With free software it’s very easy to express and identify.

What exactly are our boundaries?