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.
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.
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.
I've recently had an interesting discussion on AI usage by students with a couple of friends who are all professors or lecturers in different fields. They report that AI makes their job harder, especially because it widens the gap between students:
Students who would have straight up failed before now produce passable essays/projects, but do not understand what they are handing in. They outsource their thinking and are overall worse than before. Students who would have excelled already pre-ai, are now even better. They use AI to learn more effectively, do broader research, and have more time to do deep research because they can outsource the grindy stuff.
This is very similar for software engineers. I'm not much faster at implementing features than before AI, despite heavily relying on agentic coding (95% of code is ai generated), but I've had significantly fewer bugs in production, less feature change requests (because w spend much more time designing/experimenting), and we are able to drive-by refactors or vulnerability fixes we would have grudgingly ignored before.
My coding skills are atrophying, but that was never interesting to me anyway. I'm getting better at systems design, cyber sec, data modelling and requirements engineering, because I have much more time to spend on it now. If LLMs disappeared tomorrow, I'd have to relearn coding, but I think it is significantly more likely that hand coding will become a specialist niche for experts.
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
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.
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.
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.
> 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.
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.
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.
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.
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.
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
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!
I think these are discussions about workplace / team policy that get extended into a post.
I recognize these from different dev teams where it was agreed that a "how much AI" policy is needed, but the actual policy was very hard to settle on.
IDK, you need a few tools to unbreak a wedged box so you can get to your fancy tools even if you only want the low effort tools. Otherwise when the Cursor config file is wedged? Or the machine came up and doesnt see the network? The agent doesn't do you any good if you can't launch it.
"Mr. Anderson, what good will a Claude Max plan do for you if you can't quit vim?"
These days, I am leaning heavily on Claude to deal with all the git issues that I never wanted to be bothered with. A rebase that can't just fast-forward? That's a job for Claude. A merge conflict that really shouldn't be a problem? Claude deals with it. These are things I never wanted to have to learn in the first place, and I don't feel like reserving a part of my brain to remember how to deal with these things is worthwhile. In almost all cases, there is no actual decision that needs to be made, it's purely a mechanical process.
50 comments
[ 3.4 ms ] story [ 56.1 ms ] threadGit commits and PR descriptions? Those are probably best at least edited/tuned by humans. Because they're meant to be read by humans.
Unfortunately, you won't become a better writer letting AI do it for you.
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.
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.
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.
Students who would have straight up failed before now produce passable essays/projects, but do not understand what they are handing in. They outsource their thinking and are overall worse than before. Students who would have excelled already pre-ai, are now even better. They use AI to learn more effectively, do broader research, and have more time to do deep research because they can outsource the grindy stuff.
This is very similar for software engineers. I'm not much faster at implementing features than before AI, despite heavily relying on agentic coding (95% of code is ai generated), but I've had significantly fewer bugs in production, less feature change requests (because w spend much more time designing/experimenting), and we are able to drive-by refactors or vulnerability fixes we would have grudgingly ignored before.
My coding skills are atrophying, but that was never interesting to me anyway. I'm getting better at systems design, cyber sec, data modelling and requirements engineering, because I have much more time to spend on it now. If LLMs disappeared tomorrow, I'd have to relearn coding, but I think it is significantly more likely that hand coding will become a specialist niche for experts.
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.
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.
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.
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.
Give me a break.
Also, based on your LinkedIn you aren't an engineer at all?
The commit should be a short summary <1 paragraph for quick context
I recognize these from different dev teams where it was agreed that a "how much AI" policy is needed, but the actual policy was very hard to settle on.
"Mr. Anderson, what good will a Claude Max plan do for you if you can't quit vim?"