{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihh7gdoccpqgjfqdfbfkacmuxxunmm55ujd6jrwasvja5bf3vgoeu",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mkwca6kb7d32"
  },
  "path": "/t/how-to-filter-out-vibe-coded-dependencies/13918?page=4#post_67",
  "publishedAt": "2026-05-03T02:26:45.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "The “good” ones here aren’t really good signals imo.\n\nMicroHs is one guy who clearly knows what he’s doing.\n\nGHC is an old project - most of it isn’t AI. And it has a strong stewarding team to manage AI patches.\n\nThe downsides of AI are at the software engineering level. They have rippling effects.\n\nAI changes are good in a vacuum. The diff is good. But they tend to be gradient-descent-y changes. N% better. Can’t argue.\n\nBut if you just ride N% better blindly, you end up in a pit called a local maximum. This isn’t my opinion or taste - this is fact!\n\nYou need culture [1] and skill to ensure you don’t fall into that pit.\n\nEasier said than done. Doubly so in industry where short term-ism is the norm. I can’t tell you how many high level engineers/execs subscribe to the “make things 1% faster, multiply it by my big org chart and their salaries, and QED millions of dollars of value” fallacy.\n\n[1] Even small projects need culture. Even individuals! A culture of 1 person is called “taste”",
  "title": "How to filter out vibe-coded dependencies"
}