{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiggjvnc2t44uirgzib6btb2oy3num67ylwjooiibclgqqkfqjqnd4",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mh3ocpurucz2"
  },
  "path": "/t/yet-another-opinion-on-llms-hasufells-blog/13775?page=2#post_22",
  "publishedAt": "2026-03-14T21:12:43.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "exactly this: give an LLM a stub function with some very distinct types and a defined behavior, and it can fill that in without issues. add a few unit tests to that to actually verify it, and it is having a hard time to produce anything that’s fundamentally wrong. the coding style? from meh to horrible at times, but if prodded enough, it can clean that up too\n\ndoing a refactor and now you got a bunch of simple compile errors all throughout the project? a coding agent is perfectly capable of compiling, fixing those locally, repeat. even isn’t that bad at writing sed scripts that to a lot of that mechanically (haskell has quite a big advantage here since it is nearly impossible to get this wrong and the code to still compile)\n\nso there are quite a few scenarios where you can effectively use them. you don’t even have to touch your editor to actually write out most of your actual, just stub out a structure that makes sense, mark problematic sections that need rework, point out edge cases that still need to be tested/verified, and in such a limited scope, that works perfectly well. just don’t let it off the leash, or you’ll end up with a mess that nobody (human or ai) can fix or maintain past a certain size",
  "title": "Yet another opinion on LLMs · Hasufell's blog"
}