AI is too useful to fail. Worst case with a bust is that startup investment dries up and we have a 'winter' of delayed improvement. But people aren't going to stop using the models we have today.
BUT, to play devil's advocate a little: Most human coders should be writing a lot more try/catch blocks than they actually do. It's very common that you don't actually want an error in one section (however unlikely) to interrupt the overall operation. (and sometimes you do, it just depends)
Neat investigation but I didn’t totally follow how the project would be useful for reverse engineering, it seems like a project that would mostly be useful for evading bot checks like web scraping or AI automation.
I think this prediction of "vibe code cleanup" is massively overblown. It's amazing how much code quality doesn't actually matter to the business. Yes we recognize symptoms and downsides of bad code, and yes it matters specifically to the engineers that have to work on it. But only in extreme cases does bad code actually cause an existential threat to the business. The world already runs on bad code.
it's kind of tongue-in-cheek but it would provide the maximum amount of isolation from any upstream package changes. Even if the package versions are removed from NPM (which happens in rare cases), you'd still have a copy.
Pnpm 10.x also has a feature to disallow post-install scripts by default. When using Pnpm you have to specifically enable a dependency to let it run its post-install scripts. It's a great feature that should be the standard.
Yes if someone compromises a package then they can also inject malicious code that will trigger at runtime.
But the thing about the recent NPM supply chain attack - it happened really quickly. There was a chain reaction of packages that got compromised which lead to more authors getting compromised. And I think a big reason why it moved so quickly was because of post-install scripts. If the attack happened more slowly, then the community would have more time to react and block the compromised packages. So just slowing down an attack is valuable on its own.
For experienced engineers, I'm seeing (internally in our company at least) a huge amount of caution and hesitancy to go all-in with AI. No one wants to end up maintaining huge codebases of slop code. I think that will shift over time. There are use cases where having quick low-quality code is fine. We need a new intuition about when to insist on handcrafted code, and when to just vibecode.
For non-experienced engineers, they currently hit a lot of complexity limits with getting a finished product to actually work, unless they're building something extremely simple. That will also shift - the range of what you can vibecode is increasing every year. Last year there was basically nothing that you could vibecode successfully, this year you can vibecode TODO apps and stuff like that. I definitely think that the App Store will be flooded in the coming future. It's just early.
Personally I have a side project where I'm using Claude & Codex and I definitely feel a measurable difference, it's about a 3x to 5x productivity boost IMO.
The summary.. Just because we don't see it yet, doesn't mean it's not coming.
The many suggestions about what NPM should do differently are universally all really unsatisfying, rearrange-the-deck-chairs-on-the-Titanic level solutions.
At the end of the day, if you're running code that you didn't write or verify yourself, you're taking on risk.
IMO the next hugely successful package manager (in whatever programming language) will be the one with a really good capabilities model, so you can run untrusted code with much less worry.
On the other side of the spectrum, if no one was installing 'latest', then no one would be testing latest, and we wouldn't catch these bugs until later. We would just all get surprised after 2 weeks (or whatever arbitrary delay) until the bad version became the blessed default version.
In other words.. If there isn't a trusted test pipeline then there's no benefit in delaying the latest version. Might as well just get latest.
> should use the version of colors that svgo asked for
Another thing about setting exact dependencies is reducing duplication. Libraries are encouraged to use loose ranges, because if everyone pins exact versions for every dependency, then you could end up with 10 to 20 different copies of 'colors' in your tree, instead of having just 1 or 2 copies that work across the board.