Claude ran npm update (update all dependencies to the latest version compatible with the semver specified) in my repo without telling me when trying to fix some problems. Given that only updates the dependency lock-file I didn't notice and it caused several hours of debugging for me.

It is quite sneaky how LLM output can sometimes bypass human verification like that. No one is going around checking every single line change in auto-generated files. Someone could easily sneak a malicious dependency in there through some online tutorial that the LLM searches for.

▲ kouteiheika 4 hours ago | parent | next [-]

> No one is going around checking every single line change in auto-generated files.

There's a simple fix for your particular case: commit your lock fine (which you should do) and always review the diff (which you should also do). (:

▲ eterm 3 hours ago | parent | next [-]

You've made me realise a good signal for bug hunting: Search repos with lock files listed in their .gitignore.

It's the sort of terrible practice that someone might be frustrated into taking after a nasty merge conflict, and signals a willingness to cut corners.

▲

DanielHB 2 hours ago | parent | next [-]

My lockfile was not gitignored, I had made significant changes to package.json so I was expecting diffs in the lockfile.

I just don't usually read lockfile diffs and claude inadvertently updated a few dozen packages to new minor versions without me noticing. In fact I only realized the problem after I looked at the lockfile diff.

▲

esperent 2 hours ago | parent | prev [-]

> You've made me realise a good signal for bug hunting: Search repos with lock files listed in their .gitignore.

What would be the point of that? Do you just go around hunting for bugs in random repos?

▲

eterm 2 hours ago | parent | next [-]

Sure, in the spirit of open source, why not? It's a hobby, and it scratches an itch. I very much enjoy deconstructing things more than putting them together.

We also live in a world where a package written by someone learning to code ended up critically underpinning the entire ecosystem and is downloaded 500 million times a month.

Ignoring the eco-terror aspect of that for now, it means there's an awful lot of code out there which is finding itself under constant attack by a fleet of hostile AI.

I don't personally believe that the solution to that is "more AI", which firstly just overwhelms maintainers and secondly surrenders our human agency to a giant machine, with a hope that the "good" side can out-spend the bad.

Nor do I think the solution is to abandon the open internet and retreat behind corporate walls into curated spaces, "benevolently" protected by giant companies.

Which means holding on to the open internet requires a human approach, and any signal to help amplify the work there is a benefit.

▲

order-matters an hour ago | parent [-]

>We also live in a world where a package written by someone learning to code ended up critically underpinning the entire ecosystem and is downloaded 500 million times a month

whoa what? which one is that?

▲

eterm 7 minutes ago | parent | next [-]

As another commenter said, it's "is-even":

https://github.com/i-voted-for-trump/is-even

From that page:

> I created this in 2014, when I was learning how to program.

I've nothing against Jon Schlinkert, it's not his fault the way we build software is more than messed up, where our build systems are so brittle that, "Throw out the universe and rebuild it from scratch" became not just acceptable, but the main way to get build systems to work reliably.

▲

hnuncommon an hour ago | parent | prev [-]

Check is-even and is-odd npm packages. https://www.npmjs.com/package/is-even

▲

vel0city 31 minutes ago | parent [-]

That's still quite a ways away from 500M+ downloads a month, more like ~4M downloads a month.

Still a huge number of downloads, don't get me wrong!

	▲	eterm 3 minutes ago \| parent [-]
		You're right, I was reading the stats for "is-number" and mixing them up for "is-even": https://www.npmjs.com/package/is-number 170M downloads / week. Same author, similar vintage. Arguably a necessary package, but that just further indicates how messed up javascript was.

▲

gwbas1c an hour ago | parent | prev [-]

It's also a good practice when taking a new job, especially if someone is a contractor and changes gigs every few months or years.

I've found that, when I start a job, I have to rely on smells like this to know what kind of mess (or if there is a mess) I need to clean up.

▲ DanielHB 3 hours ago | parent | prev | next [-]

I made changes to my dependency lists in the same code where Claude ran npm update. The lockfile diff was a few hundred lines after I undid what Claude did.

And yes, eventually I did check the lockfile changes and spotted the problem. I just usually don't check the lockfile that throughly.

	▲	kouteiheika 2 hours ago \| parent [-]
		> I made changes to my dependency lists in the same code where Claude ran npm update. ...but was it in the same commit? Two "update lockfile" commits, one yours and one Claude's should have made this obvious, no? Here's another useful rule of thumb: never mix your changes with the agent's changes. Agent always starts with a clean repository (no pending, uncommited human changes). You always start with with a clean repository (no pending, uncommited agent changes). Personally I have this in my `AGENTS.md`: ## Commit early, commit often You are allowed and encouraged to produce small, self-contained commits. Never `git push`; I will always review and rebase the full history and do the push myself. Commit messages should be short and on-point. They're there for me to review your work, and not a public historical artifact. So my workflow is usually this: start agent with a clean repository, tell it to do a thing, it works in the background, then once it's finished I come back, review, rewrite and clean up half of what it wrote, then maybe iterate some more with it, and finally do an interactive git rebase to get a clean commit history.

▲ catlifeonmars 3 hours ago | parent | prev | next [-]

Heh, I also notice some coding agents like to explicitly git ignore the lockfile.

▲ Forgeties79 3 hours ago | parent | prev [-]

“But I have an agent for that.”

▲ sippeangelo 37 minutes ago | parent | prev | next [-]

Worse: Claude installed packages by just typing versions into package.json instead of running `pnpm install x`, then when running `pnpm install`, discovering that the package versions are too new and incompatible due to the default `minimumReleaseAge`, then proceeding to circumvent this by disabling `minimumReleaseAge` and running a full package update :)

▲ fg137 2 hours ago | parent | prev | next [-]

I cannot tell you how much time I have saved by stopping Claude and asking, "what are you doing?"

At least 50% of the time, Claude "realizes" it already has all the information but is doing something that's unnecessary for the current work, stop, and tell me the previous step has completed.

People complain about approval prompts etc and have Claude run in fully autonomous mode. Outside small bug fixes, I just never find that useful. It helps me immensely to see what commands Claude is running to understand where the work is going.

	▲	UpsideDownRide 2 hours ago \| parent [-]
		Also Claude often cooks up atrocious overengineered ideas but responds pretty well to being guided hands on to the desirable scope.

▲ tuwtuwtuwtuw an hour ago | parent | prev [-]

Maybe I don't understand you correctly but if your lock file isn't in Git then you have bigger security issues than LLM output, given the last years NPM worms. Unless you're a single developer and the file on disk is the primary source of truth.