{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifbtk5snulrhhbksn5bl3j2tppr2tbegejlau2xjwed2fr26hv32y",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mkwpml6v76j2"
  },
  "path": "/t/how-to-filter-out-vibe-coded-dependencies/13918?page=4#post_76",
  "publishedAt": "2026-05-03T06:52:11.000Z",
  "site": "https://discourse.haskell.org",
  "tags": [
    "ramp’s leadership seems strongly pro-vibecoding",
    "Here’s an almost good enough example"
  ],
  "textContent": "Maybe they did (and ramp’s leadership seems strongly pro-vibecoding, so the odds are pretty good). But, there’s no hard evidence, as far as I can tell.\n\nFor the topic of vibecoded dependencies, it would be good if there was an example (not necessarily in Haskell) of a regression being caused by a vibecoded PR that got merged. Here’s an almost good enough example (summary: PR with vibecoded assembly that is slower than C). However, in this case, the PR was not merged, so one could make an argument that maintainers do a good job of keeping out bad AI-generated PRs. It would be better if there was an example where the vibecoded regression was actually accepted.",
  "title": "How to filter out vibe-coded dependencies"
}