Good argument for why this might be a good idea.

Juraj

npub1m2mvvpjugwdehtaskrcl7ksvdqnnhnjur9v6g9v266nss504q7mqvlr8p9

hex

d70783027b306caac3e1795f642e852fb4f97c996c0638e583074870a7087c19

nevent

nevent1qqsdwpurqfanqm92c0shjhmy96zjld8e0jvkcp3cukpswjrs5uy8cxgprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgsd4dkxqewy8xum47ctpu0ltgxxsfemeewpjkdyzk9ddfcg286s0dsa3z8g9

Kind-1 (TextNote)

2026-03-25T07:19:46Z

↳ Reply to Leo Wandersleb (npub1gm7tuvr9atc6u7q3gevjfeyfyvmrlul4y67k7u7hcxztz67ceexs078rf6)

You still trust the LLM more than the other maintainer. For each individual library that's probably a sane approach but collectively we are so screwed...

Good argument for why this might be a good idea.

If you trust a dependency, you trust all of these: human maintainers, their LLMs, supply chain (dependencies), distribution channel.

Any of them can be compromised.

With vibing, you only trust your LLM, which you can choose and can change when suspicious.

By Andrej Karpathy: Software horror: litellm PyPI supply chain attack.

Simple pip install litellm was enough to exfiltrate SSH keys, AWS/GCP/Azure creds, Kubernetes configs, git credentials, env vars (all your API keys), shell history, crypto wallets, SSL private keys, CI/CD secrets, database passwords.

LiteLLM itself has 97 million downloads per month which is already terrible, but much worse, the contagion spreads to any project that depends on litellm. For example, if you did pip install dspy (which depended on litellm>=1.64.0), you'd also be pwnd. Same for any other large project that depended on litellm.

Afaict the poisoned version was up for only less than ~1 hour. The attack had a bug which led to its discovery - Callum McMahon was using an MCP plugin inside Cursor that pulled in litellm as a transitive dependency. When litellm 1.82.8 installed, their machine ran out of RAM and crashed. So if the attacker didn't vibe code this attack it could have been undetected for many days or weeks.

Supply chain attacks like this are basically the scariest thing imaginable in modern software. Every time you install any depedency you could be pulling in a poisoned package anywhere deep inside its entire depedency tree. This is especially risky with large projects that might have lots and lots of dependencies. The credentials that do get stolen in each attack can then be used to take over more accounts and compromise more packages.

Classical software engineering would have you believe that dependencies are good (we're building pyramids from bricks), but imo this has to be re-evaluated, and it's why I've been so growingly averse to them, preferring to use LLMs to "yoink" functionality when it's simple enough and possible. Source: https://xcancel.com/karpathy/status/2036487306585268612?s=20

Raw JSON

{
  "kind": 1,
  "id": "d70783027b306caac3e1795f642e852fb4f97c996c0638e583074870a7087c19",
  "pubkey": "dab6c6065c439b9bafb0b0f1ff5a0c68273bce5c1959a4158ad6a70851f507b6",
  "created_at": 1774423186,
  "tags": [
    [
      "p",
      "dab6c6065c439b9bafb0b0f1ff5a0c68273bce5c1959a4158ad6a70851f507b6",
      "",
      "mention"
    ],
    [
      "p",
      "46fcbe3065eaf1ae7811465924e48923363ff3f526bd6f73d7c184b16bd8ce4d",
      "",
      "mention"
    ],
    [
      "e",
      "7e75f25eece265238b5ea6020c85b730c84a5ebc670ce8a4b99634f928e2be19",
      "",
      "root"
    ],
    [
      "e",
      "5d6e2d4831d7380ef023f0944da59b972c0a840c4a003ab489ecff3e1a9da20e",
      "",
      "reply"
    ]
  ],
  "content": "Good argument for why this might be a good idea. \n\nIf you trust a dependency, you trust all of these: human maintainers, their LLMs, supply chain (dependencies), distribution channel. \n\nAny of them can be compromised. \n\nWith vibing, you only trust your LLM, which you can choose and can change when suspicious.\n\nBy Andrej Karpathy:\nSoftware horror: litellm PyPI supply chain attack. \n\nSimple `pip install litellm` was enough to exfiltrate SSH keys, AWS/GCP/Azure creds, Kubernetes configs, git credentials, env vars (all your API keys), shell history, crypto wallets, SSL private keys, CI/CD secrets, database passwords.\n\nLiteLLM itself has 97 million downloads per month which is already terrible, but much worse, the contagion spreads to any project that depends on litellm. For example, if you did `pip install dspy` (which depended on litellm\u003e=1.64.0), you'd also be pwnd. Same for any other large project that depended on litellm.\n\nAfaict the poisoned version was up for only less than ~1 hour. The attack had a bug which led to its discovery - Callum McMahon was using an MCP plugin inside Cursor that pulled in litellm as a transitive dependency. When litellm 1.82.8 installed, their machine ran out of RAM and crashed. So if the attacker didn't vibe code this attack it could have been undetected for many days or weeks.\n\nSupply chain attacks like this are basically the scariest thing imaginable in modern software. Every time you install any depedency you could be pulling in a poisoned package anywhere deep inside its entire depedency tree. This is especially risky with large projects that might have lots and lots of dependencies. The credentials that do get stolen in each attack can then be used to take over more accounts and compromise more packages.\n\nClassical software engineering would have you believe that dependencies are good (we're building pyramids from bricks), but imo this has to be re-evaluated, and it's why I've been so growingly averse to them, preferring to use LLMs to \"yoink\" functionality when it's simple enough and possible.\nSource:\nhttps://xcancel.com/karpathy/status/2036487306585268612?s=20",
  "sig": "28e746f77ab74b34147468a6a99d99a9813aac77bf77d1adfe1e6d114d0095489b60ea53593b21377aafe4d9feb4c655b00f62b5447d0f091ab90b7b39d48ca3"
}