You're Not a Better Engineer Because You Type Git Commands by Hand

cratermoon

If you can't be bothered to write it, why should I bother reading it?

cmrdporcupine

TBH writing shell scripts (and automation tools generally) is the grunt work I most love it for. Git commits and PR descriptions? Those are probably best at least edited/tuned by humans. Because they're meant to be read by humans.

mpalmer

I don't disagree with any of the points in the post. They're even framed better than the average "I love using AI because X" post. Unfortunately, you won't become a better writer letting AI do it for you.

vorpalhex

Similar arguments have been made about Git UIs and automated tools, and of course most people who depend on such things also depend on others to bail them out in difficult situations with git. So it just becomes a question about whether or not it's part of your core value proposition. For many developers, the answer is obviously no. And then outsourcing those things to automation, including LLMs, seems fine. But if you can outsource your job, so can everyone else. If the LLM (or ide or any other tool) just needs someone to vaguely press the "next" button to do your job, well, your boss and everyone else can press that button too. Outsource carefully. Know the value you provide.

giraffe_lady

Commit messages now do double duty: log of the changes, but also signing off that you've read and understand the code, are taking responsibility for it under your own name. The second part is an emerging convention but it's fairly common from what I've seen. IDK maybe no one will be reading or writing code in 18 months but if they are we'll need to separate these two things. Secondarily but probably more importantly: it's real easy to read something and say "yep I understand that." It's a lot harder to fool yourself when you have to actually write down, with your own brain, what that thing you read does. If you're not doing this you must have incredible discipline elsewhere to make up for it.

alex_x

All above comes at a cost of author slowly starting to understand less and less code in their own projects. Then in other projects as well. After the initial boost is over they will have to pay money just to stay afloat because they have already outsourced their thinking. I’m not anti AI, but I’m very worried about this bragging “you are not better engineer if you do things yourself”. Yes, you are, it all comes in small details.

fdghbcxfiyfdr

I'd much rather use an AI to tell me what the cosebase does than read someone's AI generated comments. By the time I'm asking an AI to do it it'll probably be a more capable model than the one generating comments

lordkrandel

You are outsourcing your life to AI? Good for you, but don't be so pretentious, please.

loloquwowndueo

Ew at the bit about letting AI write your commit messages. Don’t bother - if you didn’t take the time to write it why should anyone take the time to read it. I’ll just ask my AI to extract the intent from the actual code if I need it.

thunderfork

Picking on a particular nit here, but I think it is indicative of the broader flaw with this argument: To rename `PostgreSQLClient`, I press F2 and type the new name, and I'm done. I don't have to wait for an agent to "perform the refactor, update references, run the tests, fix the missing pieces, and mark the relevant checkboxes in the ticket" (btw, what checkboxes..?) I press a key, type my change, and I'm done. Wasting time waiting for tokens is also wasting time.

tangenter

I see a flamebait title, I click flag. Simple as.

nisegami

Just from the title I didn't even realize this would be a post about AI. I thought it was going to be about using Git in your IDE or other git UI tooling.

joeyhage

> In 2026, if you are not delegating this kind of engineering overhead to AI, you are burning money. And, more importantly, you are burning your life. AI use can be a divisive topic among developers but I generally believe it is a useful tool. That said, please don’t broadly advise people on what’s best for their life. It will only make people push away from AI more.

lanstin

I find I keep the git add to the be one thing I keep track of (in production services, if not throw-away or non-prod visualization vibe coded things). I've never even used git add . - I git diff each file one by one, and git add them in one by one. It's needed to prevent my own errors, and it's needed to keep some model of what the AI is doing in my mind. Now, I myself don't do much commenting in line; I tended to rely on good names, good function comments, good module descriptions as comments at the top of a file; for the flow, I would log a lot and hopefully the failure/success logs made the thinking clear for what is going on and why. But I let the AI keep all its comments, till they crowd out the code at least. Replying to a comment below (on shell scripts), I use it for shell scripts, python "get this data and slice it in these ways" and elisp, all the time. 30 seconds to get and answer instead of 30 minutes. Being able to do them in 30 minutes took a lot of skill and practice, but the pleasure of finishing that for an ad hoc thing when I really just want the data output is something I can give up.

hparadiz

I still tell the AI exactly what to do and you need to understand what reset, rebase, pull, and checkout actually do. Otherwise you end up with a mess.

georgemcbay

I don't keep LLMs sandboxed away from executing git commands because I think it makes me a better engineer, I do it because as useful as LLMs can be for programming I still don't trust them to not occasionally attempt to burn my house down.

brunooliv

So on one hand it states: Delivery is becoming a sequence of checks, not a ritual The same thing happens when it is time to deliver. First, I invoke my /definition-of-done skill. It checks whether the implementation covers what was stated in the PR and in the plan. It checks tests and the other validations I care about. It tells me when something looks unusual, broken, or missing. When everything looks good, I invoke another skill, /pr-check-release. That checks the remote PR, updates labels, removes [WIP], adds [RFC], updates the description, and prepares the change for review. If one day passes and nobody on the team reviews the PR, we merge it. The agent also tracks that condition for me, so I can run /pr-merge-dev, and it takes care of the process: merge the PR, delete the remote branch, delete the local branch, and pull dev back into a fresh state. None of these steps is particularly difficult. That is exactly the point. But then: I still care about all of those things. Probably more than most people. Obviously the author has irreversibly became AI-pilled and the day API costs balloon or APIs are down, what work will the author do? I love using AI but please read the diffs and process them with your human brains and eyes. Spin up your containers manually, test the app, MANUALLY. Talk to real users face to face. Outsourcing the grunt work is fine, but there's a fine line between that and becoming a button-presser.

vile_wretch

"In 2026, if you are not delegating this kind of engineering overhead to AI, you are burning money. And, more importantly, you are burning your life." Give me a break. Also, based on your LinkedIn you aren't an engineer at all?

nijave

Eh, agents commits are always too verbose. I don't need a 3 paragraph mini novel. Design can go in a design docs folder, project info goes in the issue tracker. The commit should be a short summary <1 paragraph for quick context

overgard

What is with all these people that are so interested in other people's workflow to the point of writing weirdly aggressive manifestos like this. "If you don't do it like me, you're wrong!" I would like to be the first person to state that I don't give a damn about your workflow . Do whatever you want!