Hear hear. What I’m pointing out however is the difference between the consumer/individual action (even coordinated) and industrial use. We don’t have enough haskellers (or even indie programmers) on the whole planet that boycotting major AI labs will move the needle. Everyone is of course free to opt out on the personal level, just let’s be honest to ourselves and each other. If one really wants to make the labs stop or change tracks then something else entirely has to be done.
1 Like
Just realised there’s a perfect meme fit for the „exponential growth“ thing here. 
„Over n% of code written by AI“ factoid actualy just statistical error. Average person uses 0 LLMs. Gastown George who uses a machine that produced a trillions incomprehensible lines of slop per year, is an outlier adn should not have been counted.
Additionally, to whom it may be news.
AI companies are forcing their „products“ down their users‘ throats and actively manipulate numbers. We should take a lot more convincing before jumping on these corporate bandwagons.
10 Likes
I agree, the consequences on the environment, the open source community (and free code in general), as well as the availability of hardware are horrendous.
Also, I should have relativated my last statement:
In a few years we most likely will either be writing code with an agentic assistant (or some newer technology), or we will have moved on to some other work that can’t be done by an agent.
If you write code as a hobby, of course, nobody will force you to use an agent. Also, if you do programming language research, you may not need an agent (albeit you will most likely be faster when using an agent). But if you write code for a living, you have to compete with others that use agents. And at the moment, the “write code manually” style may still be advantageous; but the balance is shifting continuously, and in a few years (maybe months), it will be extremely hard to compete against agents, especially when they are guided by knowledgeable people such as Haskellers. It is my firm opinion that we must jump on this boat or be left behind.
2 Likes
No one can force me to use an agent, whether it’s at home or at work.
This is also what I tell my clients.
No, I really don’t.
I think we need to take a step back and resist the FOMO, the aggressive marketing of tech CEOs and so on.
I’m not really sure how everything is going to evolve, but this narrative is deeply toxic.
I think we’re going to be left behind if we:
- don’t fix the haskell tooling
- continue to write insufficient documentation
- don’t improve the onboarding story
- can’t maintain a stable ecosystem
and most importantly, which is overarching all of this: let’s make Haskell fun to write. This language was developed by humans, for humans.
Coincidentally, I think all these points would also make Haskell more suitable for LLMs. So how about we worry about those instead?
29 Likes
I understand your points, and I completely agree with your remarks about other flaws in the ecosystem that we must fix to avoid being left behind.
However, I believe my opinion on agents is well founded; and I think it be good if we get used to using agents and take the best out of this new technology.
Of course, nobody can force you to use agents; but if person A is developing faster than person B, then person A will get the contract. I think that person A will be the one using an agent.
1 Like
I’m forced to use code assistants by my employer. Of course I could vote with my feet and just leave, but I’d have to deal with the consequences. They know they have the leverage to decide which tools I should or shouldn’t use.
I posted the below comment (reporting on how I use LLMs) on another thread, without realizing that this one existed:
I’m clearly on the pro-LLM side, but I can relate to one point from the anti-LLM site — which is the review overhead. When a contributor opens a PR that was LLM-generated, why should I accept it when I could have done the same myself (especially near-autonomously using srid/agency?). I don’t know the answer to this; an idea I came up with was to encourage contributors to submit elaborate proposals instead (see kolu and the example PR), which—once finalized, based on human discussions—can be fed directly to LLMs. The contributors contribution will be the proposal & spec that still gets record in the repository.
And LLMs do generate ‘average’ quality code. Not to mention, architecturally weaker one. And they are not creative enough to identify opportunities to extract frameworks or libraries out. All of this still requires the human in the loop, even though I believe it is possible to automate some of this in the future.
3 Likes
If the code is “average”, architecturally weaker and increases technical (and cognitive) debt… then it seems the only advantage is that you can deliver faster.
Then I’m curious why you would chose to do so in your open source projects, where you have less delivery pressure.
Is it that you care more about the end product than the process of coding?
I’ve head that theory recently, that the most avid LLM adopters are maybe those that in fact don’t care about coding on its own, but more as a means to an end. I have no idea how accurate that theory is, so I’m curious to hear your thoughts. I’ve also heard about people who claim it actually reinvigorated their excitement for coding (I’m guessing because they can potentially delegate all the stuff they don’t find interesting to the agents).
11 Likes
Why would I accept “average” code? All my employers insist we have a high hiring bar. Seems to me that “average” code should be rejected by me, as a vested steward of my company.
9 Likes
I’ll speak for myself in replying to both this and @Ambrose - when working on dataframe a lot of people that approach ask me to meet them where their data is. Which means supporting common, consistently evolving file formats and layout specs like Apache Arrow and Apache Parquet. Even if that’s done people will complain about plotting and notebooks and their favourite cloud provider etc. So to get people to use dataframes in their day to day work I have to end up having to drop dataframe development time (query optimization, API design, and all the pretty complicated Haskell abstractions you have to juggle to understand the core problem). Each of these I-would-use-it-buts is a substantial digression. It took almost a year of going to the meetings (for all 4 of DataFusion, Parquet, Arrow and Iceberg) and socializing with people that know Parquet enough to be comfortable writing it out. Even then you gotta spend a week or so understanding the quirks of data.binary and lazy bytestrings to get the implementation working.
I really enjoy coding and this currently very specific data structure that I think would be wonderful if it were in Haskell but currently that seems to commit me to doing a lot of no-that. I imagine for someone on payroll these incentives tip you to not using Haskell at all but even working on an open source project with less time and no access to cross cutting expertise the economics (time and effort wise) don’t make sense. Unless…
6 Likes
Your theory is partly right and partly wrong, I think. There’s a difference between the scaffolding part of coding and the architecture/ simplicity part. LLMs handle the first competently and the second poorly. Delegating the first has freed up more of my attention for the second. So it’s not “I don’t care about coding as craft” so much as “the craft I care about is architectural or higher-level, and LLMs let me do more of it per unit time.”
That said, you’re pointing at something real. There are users who don’t particularly enjoy coding and just want output, and there’s no care for code quality. I try to guard against the latter with explicit review (hickey/lowy and /code-police in srid/agency) … if the generated code doesn’t pass that bar, including my own manual review, it doesn’t get merged (I discard a lot of PRs, actually). I still enjoy the process as much as I did in the “pre-LLM” days.
3 Likes
I can see the argument, but I think I disagree with it.
Low-level things aren’t just about scaffolding. They’re about:
- designing primitives
- correctness
- performance
I don’t really see that LLMs excel here yet, especially the primitives part, since they appear to not mind code duplication at all. I can’t imagine having to review thousands of lines of code with all those properties in mind. Reviewing low-level details in-depth is exceptionally stressful.
I guess if you primarily enjoy high-level things and architecture, then it makes sense. But my hunch is that this isn’t so much about what LLMs are good at, but what particular part of the process I find a nuisance. I’m pretty sure people are using them for the architecture part as well, of course… with various degrees of success and quality.
We’ve done this type of work separation in teams of engineers for a long time. I guess the appealing thing, especially for open source, now is that I don’t have to find contributors who deal with the things I don’t care so much about.
1 Like
You should reach out to a trade union. More and more tech unions are starting to have working groups about the push for “AI at all costs” by employers.
7 Likes
It’s not all LLMs themselves that are harmful (not the maths). It’s those systems which are trained on data without explicit permission (e.g. copyright issues), send data to be analysed (potentially outside of a legal border) without explicit permission, those which destroy creativity (used instead of a human rather than being the tool of a human), allowing them to scrape anything and as much as possible (causing damage to servers), being over-trusted and used without understanding (developer-less CTOs) and allowing them to make decisions when they should be behind a human safety net.
By all means, use something like AllenAI with open weights. Just not things like ChatGPT.
4 Likes
This discussion has become so one-sided that I feel compelled to respond to a few recurring points, especially because the original topic got completely lost.
First, the claim that people who enjoy AI “don’t like programming” is absurd. I love programming. I’ve been doing it professionally for more than 25 years. I still work on side projects at night and on weekends. I’m constantly learning and exploring new ideas.
What I don’t love is repetitive mechanical work.
Once you know how to build a REST endpoint, wiring together the payloads, servant handlers, SQL, boilerplate, configuration, and glue code is not intellectually challenging. It’s manual labor. I’m very happy to offload that to LLMs so I can spend more time on the difficult and interesting parts of the system.
Same thing with infrastructure.
We use Nix at work. I have a love/hate relationship with it. Sometimes I lose hours fixing a broken build and get absolutely zero joy out of the process. If someone claims that debugging random Nix breakage is the pinnacle of programming enjoyment, I’m skeptical. I’m glad LLMs can help absorb some of that burden too.
A recent production issue is a perfect example. We hit a memory leak because our workload exceeded a certain threshold. Pre-LLM, I would’ve had to drop everything and spend days stress-debugging it manually. Instead, I asked Claude to help investigate it. Within hours it generated massive datasets, simulated the workflow, identified the likely root cause, and proposed fixes.
That doesn’t make me “less of a programmer.” It makes me more effective.
A strong programmer using LLMs properly will outperform programmers who refuse to use them, because LLMs are extremely good at the kinds of large-scale mechanical and exploratory work humans are comparatively bad at.
Now back to the original point.
Pretending that programming language ecosystems succeed without resources is naive. The more businesses successfully adopt Haskell, the more jobs, libraries, tooling, infrastructure, and long-term sustainability the ecosystem gains.
My argument was that Haskell’s ecosystem still has very real gaps that create substantial friction for companies trying to adopt it seriously, and LLMs are the first thing that has meaningfully reduced that burden for me.
Right now, building companies on Haskell is still painful because there are too many gaps in the ecosystem. LLMs are helping bridge those gaps dramatically, and this thread seems completely dismissive of the reality that these ecosystem holes are one of the biggest barriers to adoption.
The ironic part is that some of the strongest counterarguments are coming from a developer who works at Mercury, where Haskellers have publicly talked about these exact problems firsthand:
-
Writing Temporal bindings because the ecosystem lacked a solution
-
Investing heavily in OpenTelemetry because the tooling lagged behind other ecosystems
-
Pushing for GHC improvements to make observability tooling more ergonomic
-
Spending significant effort mitigating compile-time pain
And interestingly enough, the upcoming hs-opentelemetry release is reportedly being developed heavily with AI assistance by a Mercury engineer.
On top of that, Mercury itself heavily uses AI internally and released both the OpenAI and Claude packages on Hackage.
That’s exactly my point: AI is helping make Haskell more viable, not less.
8 Likes
Anti-AI, Pro-AI both have their pros and cons. We are all entitled to whatever opinion we choose to carry.
I personally think AI has value like any other tool that has come before it. Sure, AI is different in that it is an attempt at automating intelligence or something along those lines, but once you look beyond the marketing and the hype, it just seems like another way of writing code. As such, it’s only going to be as good as the person using it and their familiarity with it. That is to say, sure, AI makes it easier to produce slop, but it can also make it easier to produce high quality code too (i.e Ghostty).
From that perspective, perhaps it’s more productive to not treat AI generated code as slop outright but call out bad code as bad and good code as good regardless of whether it’s hand written or AI written.
As for AI and the Haskell community, I don’t think LLMs are going to magically improve things. Sure, they may help, but what we have with Haskell is, IMO, a people/branding problem (feel free to correct me if I am wrong). I mean, there are still people out there who consider Haskell a purely academic language of no practical use. Those people aren’t going to want to write Haskell, LLM sentiments aside. We need more people to first have an interest in the language and want to use it. LLMs may help or hinder us beyond that point but we need to get there first.
For those already in the community, I don’t particularly see the issue with using an LLM to patch stuff up (code, docs, etc…), again, so long as, it is of high/decent quality.
As for the volume problem, well, that’s not unique to us. We all, as an industry, need to work together to sort that one out, I think.
My two cents
5 Likes
Agreed.
And LLMs are not the solution to that.
There is two types of solutions, IMO:
- abstractions, libraries and frameworks so you don’t have to write the details by hand (a declarative DSL for servant+SQL for example seems not very far fetched)
- deterministic code generation… guess what, this has been done decades ago already, except not with natural language as input, but using e.g. Z notation
Why is this more appropriate:
- it’s bounded
- it’s deterministic
Except, it also requires a fair amount of expertise (specification languages, writing DSLs, etc.) and knowledge of what exactly you want… and that’s the difference. Babysitting an LLM doesn’t require expertise, no matter how hard people try to sell that as a skill. It’s a shortcut. “Write me a C compiler” doesn’t require you to understand the domain.
Natural language as input to code generation is disconnecting our craft even more from “serious engineering”.
Yes, people are coming up with all sorts of creative ideas to keep the stochastic copy-paste machine in check and I’ll be honest… I am impressed by all the agentic wizardry that people come up with. But in the end it’s still the wrong interface. The wrong tool.
But it’s also quite characteristic for our industry:
- the ability to scale stuff to infinity
- the inability to care about foundations and make programming a serious engineering discipline
Most of the time, there are no lives on the line and our craft is barely regulated, except in a few cases (e.g. functional safety). Haskell for me was so appealing, because I felt it’s where people are self-regulating and try to be above “industry standard”, because the industry standard is poor crap.
So what am I saying? That LLMs are not useful? Not at all. I’m saying despite having pretty cool use cases, they’re a net negative at the moment and we can have better solutions for the “repetitive mechanical work” problem.
Must… not… take the bait… 
I guess it depends how you measure performance. If it’s lines of code, then sure.
Well yeah, this is a pretty output-centric view. What we’re missing is the product. I guess if you view it that way, then LLM use can accelerate that type of development.
But I simply don’t agree with that view.
11 Likes
Would also recommend looking at https://www.workersdecide.tech/ to get a sense about how others have started to organize against AI mandates, both with and without unions.
7 Likes
That would be me. I enjoy coding so much more with agents. It might be more me than best-practice but agents are so much better at repository maintenance than I am. With a good checklist and a fresh LLM, my libraries are much cleaner than they used to be and easier, more streamlined. The costs of maintaining a library with proper CI, doctests, examples and design narrative has gone way. Observationally, LLMs feel like all of our readme’s come to life (good, bad, ugly or non-existent) and their is a renaissance in literate programming - LLM’s care as much about good docs as good code.
I’m in the middle of developing a new library and I’m very interested in how an agent uses it out of the box. If they write bad code or stuff it up it’s usually the library design at fault and not some hallicinating retch at the end of a tool call. A bad LLM should be able to write good code with your library - it might be that type of world going forward.
Often, I experience LLMs writing good code at speed. Better code than I can write by myself and more code than I could ever write. Out of the box, they know much more category theory than I ever will, which I’m finding invaluable in library design.
I think you’re wrong in the basic premise that LLMs are always harmful to code with. Agents love using Haskell - they can reason away and bounce off of type guardrails and get a compile eventually (just like us!). They help cover gaps in the ecosystem, make documentation cheap and cheerful and they write nice Haskell if you train them properly.
I realize there is a wall of pain heading our way in terms of LLMs and infrastructure, but that’s a global tech problem not confined to our little community.
So i enjoy using LLMs and especially for the interesting stuff, but I totally get why we should be freaking out over the likely effects on infrastructure.
11 Likes
I typically measure these things in problems solved. Hard to get an exact and fair measurement of, but easy to get an intuition of. Bugs, errors, crashes that existed for years are now all getting fixed at a much higher rate because solving problems is much easier with the help of LLMs. I effectively spend my time iterating on the quality of the solution. The result both faster problem solving, and higher quality code than if I were to do it manually.
This comes across to me more like a demand than as advice. My philosophy here is that I will use whatever tool helps me solve problems most effectively, up to a high engineering standard that I am willing to stand for, at an affordable cost. That is the choice I make for myself. The GPT models in particular are at quite an effective cost to value ratio here (judging by the GitHub copilot multipliers that I work with).
I’ve also worked with the opencode Zen models for my personal projects. They actually have some (currently) free models that also did quite well for what I needed (the GHC PR)
3 Likes