5 ms·

> 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

> 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). (:

Forgeties79 16d ago
“But I have an agent for that.”
catlifeonmars 16d ago
Heh, I also notice some coding agents like to explicitly git ignore the lockfile.
eterm 16d ago
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 16d ago
  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.
  - jrockway 16d ago
    Makes sense. This is why I like using jj, because "update deps" and "fix bug" are going to be two separate commits, and when "fix bug" has changes in the lock file, the red flags go up. Claude seems to be super good at jj so that can take the edge off as well.
    - lesam 16d ago
      Why do you need jj for this? I'd usually make incremental commits with git, and I'm wondering how jj levels it up.
- esperent 16d ago
  > 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 16d ago
    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 16d ago
      >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?
      - hnuncommon 16d ago
        Check is-even and is-odd npm packages. https://www.npmjs.com/package/is-even https://www.npmjs.com/package/is-even
        vel0city 16d ago
        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!
DanielHB 16d ago
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 16d ago
  > 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.
  - DanielHB 16d ago
    I don't let claude make commits for me, every commit is my own. I check the diffs before commiting. > never mix your changes with the agent's changes yeah, but if you don't want to lose your existing context sometimes you have to. When I do, I tell claude to check the diff on the files I changed, which is quite annoying to be honest. But still easier than telling claude to do _very specific line-change_ on file X.
    - kouteiheika 16d ago
      > yeah, but if you don't want to lose your existing context sometimes you have to Sorry, I'm not sure I follow. What do you mean by "lose your existing context"? Can't you just... commit in turns? It's not like you're editing files while your agent's also editing in parallel, right? Again, the trick is to treat the commits as throwaway checkpoints/packets of work. They don't need to be pretty, nor need to make sense. The point where you clean that mess up is when you're done and you're doing an interactive rebase at the end. At least that's how I work.
nomel 16d ago
That's a manual step, not a solution. the solution is just boring basic file permissions. Treat Claude as semi hostile user. If you don't want them accessing your files, set the permissions to exclude them (like require sudo). I already do this for my unit tests, because Claude will "fix" the tests so they'll pass.

Forgeties79 16d ago

“But I have an agent for that.”

catlifeonmars 16d ago

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

eterm 16d ago

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 16d ago
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.
- jrockway 16d ago
  Makes sense. This is why I like using jj, because "update deps" and "fix bug" are going to be two separate commits, and when "fix bug" has changes in the lock file, the red flags go up. Claude seems to be super good at jj so that can take the edge off as well.
  - lesam 16d ago
    Why do you need jj for this? I'd usually make incremental commits with git, and I'm wondering how jj levels it up.
esperent 16d ago
> 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 16d ago
  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 16d ago
    >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?
    - hnuncommon 16d ago
      Check is-even and is-odd npm packages. https://www.npmjs.com/package/is-even https://www.npmjs.com/package/is-even
      - vel0city 16d ago
        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!

DanielHB 16d ago

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 16d ago
> 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.
- DanielHB 16d ago
  I don't let claude make commits for me, every commit is my own. I check the diffs before commiting. > never mix your changes with the agent's changes yeah, but if you don't want to lose your existing context sometimes you have to. When I do, I tell claude to check the diff on the files I changed, which is quite annoying to be honest. But still easier than telling claude to do _very specific line-change_ on file X.
  - kouteiheika 16d ago
    > yeah, but if you don't want to lose your existing context sometimes you have to Sorry, I'm not sure I follow. What do you mean by "lose your existing context"? Can't you just... commit in turns? It's not like you're editing files while your agent's also editing in parallel, right? Again, the trick is to treat the commits as throwaway checkpoints/packets of work. They don't need to be pretty, nor need to make sense. The point where you clean that mess up is when you're done and you're doing an interactive rebase at the end. At least that's how I work.

nomel 16d ago

That's a manual step, not a solution. the solution is just boring basic file permissions. Treat Claude as semi hostile user. If you don't want them accessing your files, set the permissions to exclude them (like require sudo). I already do this for my unit tests, because Claude will "fix" the tests so they'll pass.