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.
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.
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?
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?
Sure thing. Point releases of projects generally have to be buried or downweighted on HN due to being repetitive, particularly in cases like this, in which the previous discussion spent 24 hours on the front page less than two weeks ago.
Even if it is a major upgrade, the previous thread is so fresh in the hivemind's memory that it won't get the attention or gravitas that the previous version did.
You can try submitting a blog post explaining what's new and different about this version, but you might have better success if you wait a month or two (and also hike the major version number to 2).
Check what tools we already implemented, check your "slow" accusation, check the prompt system, check the provider integration (via Rig, so caching is already enabled), check the MCP support and other integrations that you don't even find on some major agents (git worktrees + loops).
For 3 years, your Lovable clone is something that Claude Code could make in a couple of days, but good luck shitting on other project I guess.
This is actually a topic of current interest, and I think that I will switch to a sandbox-by-default once the bwrap implementation inside of zerostack is well tested and highly configurable.
