{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihmav6qiwkrdtytahhyuj3zyidvy5u36jlv5blere7ri2byf233va",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mlbplliktlw2"
  },
  "path": "/t/anti-llm-sentiment-considered-harmful/14008?page=4#post_80",
  "publishedAt": "2026-05-07T15:45:28.000Z",
  "site": "https://discourse.haskell.org",
  "tags": [
    "decades ago",
    "Z notation"
  ],
  "textContent": "shinzui:\n\n> What I _don’t_ love is repetitive mechanical work.\n\nAgreed.\n\nAnd LLMs are not the solution to that.\n\nThere is two types of solutions, IMO:\n\n  1. 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)\n  2. 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\n\n\n\nWhy is this more appropriate:\n\n  * it’s bounded\n  * it’s deterministic\n\n\n\nExcept, 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.\n\nNatural language as input to code generation is disconnecting our craft even more from “serious engineering”.\n\nYes, 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.\n\nBut it’s also quite characteristic for our industry:\n\n  * the ability to scale stuff to infinity\n  * the inability to care about foundations and make programming a serious engineering discipline\n\n\n\nMost 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.\n\nSo 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.\n\nshinzui:\n\n> We use Nix at work.\n\nMust… not… take the bait…\n\nshinzui:\n\n> 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.\n\nI guess it depends how you measure performance. If it’s lines of code, then sure.\n\nshinzui:\n\n> 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,\n\nWell 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.\n\nBut I simply don’t agree with that view.",
  "title": "Anti-LLM Sentiment Considered Harmful"
}