At previous jobs, I was the one coworkers would come to when they had messy git problems and needed help cleaning them up. I've put in the hours in the past to learn how to do all of that, and then later forgotten it because it's just not worth it anymore. I switched to jj a few years ago and had the majority of the annoying rebase issues go away, and whatever's left goes into my LLM to spit out a potential solution that I can then manually tweak if the result isn't perfect.

My OS professor in college once told us about what he considered the difference between "knowledge" and "information", with "knowledge" being the underlying facts about how something works and "information" being the terminology/labeling/bucketing/etc. of how to refer to it. The point he made was that knowledge was more important than information, and that he would try to test us on knowledge rather than information. To me, knowing how the underlying version control model works and what "shapes" you might want to make with it is useful knowledge. The exact set of commands, interactions with an IDE, or specific prompts you can use to ask an LLM to produce them is information. Arguably the entire benefit of LLMs is that you can ask them to do things even if you don't have the exact information memorized; if you can describe it in a rigorous way, and recognize whether what it gives you as an output fits that or not, you don't need to know any of the actual information of how to do it manually.

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.

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.

> 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…

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?

I think that actual direct knowledge about how git merges things and what ends up surfacing as "conflicts" as a result of that is not particularly well understood by quite a large number of people who in practice do not have any trouble using git every day. Moreover, there's nothing specific to git in terms of reviewing code, which is fundamentally what you get from the result of fixing conflicts; once the conflicts are all resolved, there's a diff from the old state (pre-merge) to the new state, and you already should be reviewing it to see if it's what you want even if there were never any conflicts.

Nothing.

Should you resolve the conflicts in a bad way we're going to see the result in the MR, will we not?

I don't think git knowledge is essential anymore.

Back in the days of the crappy git GUIs this was a problem, because people would regularly misunderstand even the basics of what they were doing and managed to lose their local changes.

That shouldn't happen with LLMs.

LLMs solves them great. So who cares? At most it will ask for a few guidelines on what takes priority, but no one is using git directly anymore.

I have not run a single git command in like the entire 2026.

Yeah, I feel like knowing how to use tools is one of the key smells for finding good engineers.

just ask the agent "no mistakes" /s

Oh, I was not even attempting to discuss using them for the code itself in my above comment. Code that's checked into a repo has a much more complex set of tradeoffs that I'm much less convinced have a one-size-fits-all answer. My point was more that even if reasonable people can disagree on how much you need to care about the code itself being LLM generated, I can't wrap my head around why anyone should care whether an LLM happened to execute the `git commit` and `git push` shell commands!