Hacker News Reader

Comment by astonex | Hacker News Reader

> but like, if someone doesn't know how to manually configure their git remotes and what exact command to use to amend/squash their commits into the shape needed and instead has an agent prepare all that and use the GitHub CLI to open the PR, why should I care?

Because LLMs aren't a reason to not learn your tools. A determinist CLI command vs using a statistical machine for it. It's just a waste of tokens at the very least.

View on HN

No, the reason not to learn your tools is if they're not your tools anymore, and something else is. I don't spend time trying to manually invoke filesystem APIs to create files in my work projects and instead will often just have my LSP do it when I declare a module and the file isn't found. I could memorize the exact sequence of system calls needed, but my employer would prefer I spend time on things that are more worthwhile to them.

I don't disagree that having a deterministic CLI is useful, but I'd argue that's not the question here, because the CLI is what the statistical machine will be using. The question is whether the time spent doing it manually is worthwhile compared to the tokens spent on it. I'd further argue that if you instead learn how to pick the right model for the right job so that you don't use something way more expensive than needed for the task at hand, the token overhead will be extremely minimal for stuff like git operations; knowing that you can use something cheaper than like, Astra or Opus if all you want to do is a quick git cleanup and push is going to save your employer a lot more money in the long run than if you insist on doing every messy rebase by hand.

While using LLMs is a great idea, it has become crucial to put safeguards in place to ensure that their use doesn't deviate from team practices or compromise security.

I'd argue that these are not really specific to git (or even LLMs honestly); in terms of security, don't put company data into anything that your company hasn't given you explicit permission to put it into.

In terms of team practices, that basically seems like a code review thing. If my team has conventions around git, and a PR doesn't fit them, that's something I would point out regardless of how the PR was generated. If a team member is repeatedly not meeting the expectations we've all agreed upon, I would deal with it in the same way I always have; reach out and offer guidance for how to do things the way they're supposed to, notify my manager if they continue having trouble with it, and eventually just not bother looking at their PRs if they absolutely refuse to do things the way everyone else on the team has agreed they should be done.

The point of knowing your tools is to stop escalating to other people every time something doesn't work with them.

Even if an LLM can hold your hand through everything, the disruption I've had because people don't understand what the LLM tool is doing, and ultimately does damage (we've had repos corrupted, systems taken offline, systems brought their knees, numerous data security incidents... it's been a fucking nightmare) is immense.

Repos corrupted? From arbitrary usage of a git client? I feel like it's been generally a bad idea to allow arbitrary force pushes for anything shared for a while before LLMs entered the picture.

Automation bias!

Even worse, it gave a developer a command to run that basically crushed all history across all branches, it was a mess to clean up and lost a significant amount of work. It wasn't Claude running it on its own, but was entirely driven by a mix of a developer's lack of understanding their tools, and trusting Claude's output too much.

This was also the dev trying to "remove a key he had accidentally committed" again, just letting Claude take the wheel.

Of course, the new team _also_ really loved leaning on AI so they were all behind his plan to "clean up the repo" and not just reset the key and move on.

It was a nightmare.

The idea of saying the LLM is "my tool" as opposed to all the actual tools it calls, is about as appealing to me as saying the same about, say, Remote Desktop. "The statistical machine" is there to generate candidate actions, not to implement them.

In the before time, this is the sort of thing people would just google.

One time setup commands are the sort of thing people do once when setting up the repo, but dont use day to day. its understandable that people dont have that memorized and will reach for a man page, google or an AI.

I happen to have memorised how to add new remotes a long time ago, but I would 100% not care if someone I worked with googled it every time. That's how it was for me for several years. I don't think that has anything to do with "learning the tools". And getting claude to do it is not that much different from copy-pasting from google.

TBH I usually just search my shell history for the last time I added a remote and edit it.

It's also not particularly hard to write a shell function to avoid needing to care about the syntax, e.g.:

    add_github_remote() {
        git remote add $1 git@github.com:$2/$3.git
    }

thats just the same problem though, ig you arent using it regularly you are going to forget that part of your shell functions

I wholeheartedly agree that it's the same, but I fundamentally disagree about it being a "problem", or at least, one worth caring about. I don't honestly believe that typing out the extra 35 characters that are filled in by the helper function I gave here would solve anything that comes close to the convenience of not needing to memorize them.

1. Develop the instinct of "I probably have a shell function for that, if it isn't already obvious; and if I don't, I need to fix that"

2. Give your shell functions a common prefix, and/or big-endian naming convention (e.g. things that help you with git start with `@git-`)

3. Tab completion is your friend.

Better yet, assign the positional arguments to named variables for documentation purposes; you can see them when you `type` the function. (Comments get stripped, unless you make an actual script.)

> It's just a waste of tokens at the very least.

Some 6-figure per year developer spending a quarter’s worth of tokens to do something they do once a month or so is not something I’ll ever care to optimize away…

I misread this as a "quarter" as in "three month period of the calendar year" and was very confused until I remembered that was also the name of a coin

Tokens are cheaper than brain power. Why waste my time trying to recall the details of git's byzantine, ill-begotten command line interface when I can delegate that boring task to a robot?

Reply on news.ycombinator.com