Building efficient agents is doable (I did it myself, github.com/gi-dellav/zerostack), companies just want to tokenmaxx, and as a by-product, produce and publish slop.
> These crates sit on the path that renders untrusted model output (diagram source → SVG). Vendoring gives a full audit surface, pins exact source, and avoids crates.io yanks. Local patches and upgrade checklists live in each crate’s Cargo.toml header comments — treat those as the source of truth when re-vendoring.
Which honestly feels like a misunderstanding of how cargo and yanks work. Each upstream package is locked to an exact version in your lockfile along with a cryptographic hash. The upstream can't change the source without you noticing. Unless you update your lockfile you will always pin to the exact version and source. When a package is yanked, it is still available for download if it is already in a lockfile. It just prevents new packages from resolving it. Crates.io will sometimes completely delete a package, but I've only seen that happen in cases of malware. It's fairly rare and seems out of line with the supply chain concerns here.
There are good arguments for relying on upstream package managers and there are good arguments for vendoring all packages. I've never seen a project mix before.
Rendering untrusted model output, ooh scary! Of course we want full audit surface!
Proper dependency managers changed that and it became much easier to consume libraries, just declare what you went, the build framework handles the rest.
But we now have problems with consistent versioning, churn, breaking API changes and supply-chain attacks.... and looks like "just vendor everything in" might be a thing again?
it's not an llm in a loop with tools anymore (as claude code was rumoured to be on HN).