9 ms·

What a bunch of slop: 182 top-level external dependencies (so, without considering nested dependencies) and 1318853 lines of code in Rust. Building efficient a

What a bunch of slop: 182 top-level external dependencies (so, without considering nested dependencies) and 1318853 lines of code in Rust. 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.

petesergeant 2mo ago
Genuinely curious about whether comments like this consider all AI generated codebases to be slop? Are you just knee-jerking or is this one an example of actual trash? I have been building a product[0] where I’ve not written a single line of code; is it also definitely “just tokenmaxxed slop” or is any consideration going into comments like this? 0: https://github.com/pjlsergeant/byre https://github.com/pjlsergeant/byre
fouc 2mo ago
it started off with 500+ crates and then i still had to install dotslash crate which installed another 136 crates. seems insane.
overgard 2mo ago
That is an insane amount of code for something like this!
- kirtivr 2mo ago
  to be fair, coding agent harnesses have been becoming more and more complex. it's not an llm in a loop with tools anymore (as claude code was rumoured to be on HN).
  - thrance 2mo ago
    It's not a kernel either, 1.3M LoCs is ludicrous.
stusmall 2mo ago
It looks like some of that high LoC is because they are vendoring some deps. There readme gives the reason to vendor some but not others as: > 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.
- Pannoniae 2mo ago
  It's kind of full circle... dependency management was invented because consuming libraries or common code was hard, everyone kept reinventing the wheel and if you had some vendored code, updating it was a nightmare due to the build integration and source customisation. So people don't update much. 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?
  - LtWorf 2mo ago
    Who needs fixing well known vulnerabilities anyway?
- foltik 2mo ago
  Sounds like they did the ol “grok please make this secure” and it slopped out this plausible-if-you-squint nonsense. Rendering untrusted model output, ooh scary! Of course we want full audit surface!

petesergeant 2mo ago

Genuinely curious about whether comments like this consider all AI generated codebases to be slop? Are you just knee-jerking or is this one an example of actual trash? I have been building a product[0] where I’ve not written a single line of code; is it also definitely “just tokenmaxxed slop” or is any consideration going into comments like this? 0: https://github.com/pjlsergeant/byre https://github.com/pjlsergeant/byre

fouc 2mo ago

it started off with 500+ crates and then i still had to install dotslash crate which installed another 136 crates. seems insane.

overgard 2mo ago

That is an insane amount of code for something like this!

kirtivr 2mo ago
to be fair, coding agent harnesses have been becoming more and more complex. it's not an llm in a loop with tools anymore (as claude code was rumoured to be on HN).
- thrance 2mo ago
  It's not a kernel either, 1.3M LoCs is ludicrous.

stusmall 2mo ago

It looks like some of that high LoC is because they are vendoring some deps. There readme gives the reason to vendor some but not others as: > 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.

Pannoniae 2mo ago
It's kind of full circle... dependency management was invented because consuming libraries or common code was hard, everyone kept reinventing the wheel and if you had some vendored code, updating it was a nightmare due to the build integration and source customisation. So people don't update much. 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?
- LtWorf 2mo ago
  Who needs fixing well known vulnerabilities anyway?
foltik 2mo ago
Sounds like they did the ol “grok please make this secure” and it slopped out this plausible-if-you-squint nonsense. Rendering untrusted model output, ooh scary! Of course we want full audit surface!