{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifpjrdcqs3itgg47j6kci7iildz3fx7zrquxpgjjc46fpusjp2q74",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mjkaw3w6drc2"
  },
  "path": "/t/how-to-filter-out-vibe-coded-dependencies/13918?page=3#post_47",
  "publishedAt": "2026-04-15T15:33:39.000Z",
  "site": "https://discourse.haskell.org",
  "tags": [
    "Mc Cabe Complexity",
    "study",
    "a victory"
  ],
  "textContent": "arybczak:\n\n> Exactly. What’s the difference between a package that was badly coded by an LLM and a package that was badly coded by a human? I don’t see any.\n\nSo perhaps (derailing the particular task the OP set out to solve) we should look for established measures of code quality in other ecosystems. I presume much literature has been written on that subject.\nIn one particular ecosystem I happen to know a little, a linter is marketed that gauges\n\n  * Mc Cabe Complexity\n  * Code lines per source file / Libs\n  * Code lines per function\n  * Number of functions per file / libs\n  * Number of parameters per function\n  * Number of files per folder\n  * Dead code\n\n\n\nThese metrics could help to detect LLM slop as well as sloppy human coders alike. There is a study that has produced promising results.\n\nOnce the LLMs adapt and write well-organized, maintainable code to subvert the sloppiness filters, we can declare a victory.",
  "title": "How to filter out vibe-coded dependencies"
}