{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreievn4nf5be7edukgim2jn2swqzinpinhqr2inzqprvnwluqchtpgu",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mlbitslkd2l2"
  },
  "path": "/t/anti-llm-sentiment-considered-harmful/14008?page=4#post_78",
  "publishedAt": "2026-05-07T14:53:39.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "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.\n\nFirst, 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.\n\nWhat I _don’t_ love is repetitive mechanical work.\n\nOnce 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.\n\nSame thing with infrastructure.\n\nWe 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.\n\nA 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.\n\nThat doesn’t make me “less of a programmer.” It makes me more effective.\n\nA 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.\n\nNow back to the original point.\n\nPretending 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.\n\nMy 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.\n\nRight 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.\n\nThe 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:\n\n  * Writing Temporal bindings because the ecosystem lacked a solution\n\n  * Investing heavily in OpenTelemetry because the tooling lagged behind other ecosystems\n\n  * Pushing for GHC improvements to make observability tooling more ergonomic\n\n  * Spending significant effort mitigating compile-time pain\n\n\n\n\nAnd interestingly enough, the upcoming hs-opentelemetry release is reportedly being developed heavily with AI assistance by a Mercury engineer.\n\nOn top of that, Mercury itself heavily uses AI internally and released both the OpenAI and Claude packages on Hackage.\n\nThat’s exactly my point: AI is helping make Haskell more viable, not less.",
  "title": "Anti-LLM Sentiment Considered Harmful"
}