{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreia6r2veu6luy3ad3j54hhshtu733u2br764heqjfrcryfeqhormqe",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mgu2n7mt5zb2"
  },
  "path": "/t/haskell-vibes-jappie/13772?page=3#post_41",
  "publishedAt": "2026-03-11T23:45:02.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "Despite my quip above. I’ve used LLMs with Haskell, Python, Rust, Typescript as well as other odds and ends so far.\n\nThe first time I tried those tools they were usable on python/typescript and worthless on Haskell. I’ve started another trial run a few months back and they seem to work decently on Haskell now.\n\nI don’t know if Jappie used those tools to any meaningful degree in other languages. Because while I agree that encoding and expressing invariants in types is useful. In practice I can’t say I feel like this translates to generated Haskell code being particularly more reliable than generated python code, rust code or anything else.\nAt least if I take the same amount of effort in expressing invariants. It’s just that instead of adding (partial) type signatures I will add type hints, assertions or plain comments for python. It does make it a bit easier to reason about generated code if it includes type signatures afterwards. And I would rather manually patch up Haskell code than Python code if I have the choice. But that might just be me prefering Haskell in general.\n\nMaybe I just haven’t tried to apply it to complex enough problems in python yet. But so far I can’t say I feel like those tools work _better_ with Haskell. I might think the output, eventually, is better since it’s a Haskell program rather than a python program. But that feels somewhat orthogonal.\n\n* * *\n\n> That final 10% of the implementation is now my job, which is getting it correct. I have to ensure the software Claude produces works. I have to think in terms of verification.\n\nPersonally I often found that doing the “easy” part of the implementation also makes the verification much easier. I naturally think about the invariants, preconditions and postconditions of various parts of the code while writing it. And often without it adding much more effort to the implementation. And even when using LLMs I think one is much better off when thinking about how to ensure a program is - mostly - correct by construction from the start rather than trying to verify it behaves as expected afterwards. Last but not least because often when letting the LLM do much of the work it’s not even _that_ clear what the expect behavior is, making it even trickier to ensure correctness!\n\n_Maybe_ it’s still faster overall. But I feel like whenever I used these tools for a non-trivial task where I _actually_ cared about it being correct I didn’t get much of a productivity benefit. One of scripts? Random stuff I don’t care if it crash and burns? Sure. But taking any large AI generated diff and ensuring there aren’t bugs is hard work. And sometimes I found myself thinking it would have been easier if I had written it myself in these cases.",
  "title": "Haskell 💜 Vibes / Jappie"
}