{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreichzomsyerelfvh65glbqn2ohzhgu26guwx2jjkpealzxh3awk77y",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mjcikzaq4kn2"
  },
  "path": "/t/how-to-filter-out-vibe-coded-dependencies/13918?page=2#post_38",
  "publishedAt": "2026-04-12T13:46:33.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "hasufell:\n\n> And we need an incentive for maintainers to have good LLM contribution policies.\n\nHello!\n\nThat looks like a relevant question. And it does sounds quite different from filtering out vibe-coded dependencies. Isn’t it?\n\nIt starts to look similar to demanding good practices like documenting the implementation, or providing unit tests.\n\nHow about asking for code contributions to be peer reviewed? (like in pull requests) Does that help ensuring LLM generated code gets the same amount of attention as other contributions?\n\nIf the PRs are too large or too many, they can be rejected due to lack of resources to review them\n\nI’m happy to learn about the objections, though.\n\nCheers!",
  "title": "How to filter out vibe-coded dependencies"
}