Git commits and PR descriptions? Those are probably best at least edited/tuned by humans. Because they're meant to be read by humans.
The LLM tends to fill the messages with irrelevant details while still failing to mention what the change actually does.
I was team / tech lead on the last contract gig I had, and I had a policy in writing that people should write their own commit messages and PR descriptions. For this reason and others.
... And follow conventional commit format. Linear commits. Rebasing / fast-forward, no merge commits. Etc. etc.
Nobody paid any attention. The git history was next to useless. Bisecting would be completely impossible. People were mostly just pumping and dumping. I could have drawn a hard red line but the founder was the worst for it.
We're doomed.
What I do on occasion if it's a nontrivial script (or I don't feel like remembering how to handle non positional arguments) is have the AI write it up, and then I verify by myself it is correct. I can write the script and understand it over an afternoon, it's more that I just don't find it enjoyable.
Cheaper than automating with an AI, it's deterministic, and I don't end up eyeballing the clock every 5 minutes at 2pm because I hit one of the many rough parts of bash.
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.
It would be like saying being an engineering manager is a different abstraction layer. It's not. It's an entirely different domain, managing people and resources instead of programming machines directly
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.
The problem is the IDE refactor->rename updates the code but the agent's "rename" will also catch developer-facing documentation in text files, comments, etc. that referenced the old name. It will often even catch reflection code that referred to the old name in a string. And it will do the mental work of disambiguating "this reference is something else that shouldn't be updated, that one is really pointing at the thing that got renamed and should be updated". If asked to, it can catch things like "var postGresClient = new PostgreSQLClient()" and change them to "var dbClient = new DatabaseClient()".
My preconception was: the IDE feature is deterministic and works every time. The LLM may hallucinate and fail to correctly do the rename, so it's both slower and worse.
My actual experience has been: So far, I've never actually seen Opus or GPT5.5 hallucinate and fail at a simple refactoring task like this, but I have had numerous instances where it caught extra stuff that a deterministic rename never could, and therefore did the task slower and much better.
I hate it because it feels lazy and stupid to type "do this trivial thing for me" into a prompt box. But dammit, it works too well.
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.
I am old enough to remember having these thoughts when documentation for things moved from books to being online. I thought looking things up in the internet was a recipe for failure, because the internet was new and unstable and changing, and what happens if you run out of your 10 hours a month of being online, or if someone in your house picks up the phone and you are disconnected?
Clearly those people were internet pilled, and the day the internet costs ballooned or was down, what would they do?
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
Claude will write a novel, sign it with its signature like it's a person, and fill it full of advertisement language and marketing text.
But on a team, I expect people to follow some basic decorum on standards for commit messages and code reviews. That was hard to enforce and get before (GitHub encourages bad practices) but it's bloody impossible now.
"Mr. Anderson, what good will a Claude Max plan do for you if you can't quit vim?"
That you know what that is makes you the right kind of person to be delegating it to an LLM; you can be trusted to use the LLM for this sort of thing because you understand what the problem is, what the right outcome should be, and how to know when it's been done correctly.
It's the person sitting behind you who doesn't understand any of those words who is going to do something dangerous at LLM-accelerated speed I'm concerned about.
Why do these posts always state things like this with maximum confidence and then not even make any attempt to show evidence? "I've got x years of experience trust me bro" is pretty weak.
[0] https://snyk.io/articles/defending-against-glassworm/
but that does NOT mean you get to skip understanding the code & whipping the AI in line during implementation
my preferred workflow:
- think hard about the problem before touching the keyboard
- back and forth with the AI, swatting down bad implementation ideas and poking holes
- settle on a detailed implementation plan
- let the AI go for however long it needs to (usually minutes, sometimes hours)
- review, iterate, test
- "this looks good, commit in focused chunks and create a PR"
- review commits & PR summary, hand edit for clarity
Hey cron, keep reminding Claude to do that while I drink.
LLMs are not people and they don't have values.
The goal of writing the git messages is to slow down and prevent a worst case scenario where work is lost. Given how powerful git is I think giving control over is like doing a sure fire migration without a backup in the way that it can lead to easily preventable problems that are difficult to fix afterwards, it’s just a bad paradigm.
I can appreciate some parts of this, like keeping a painfully detailed record of the changes written by ai, I have this too, but it is separate for the content meant for actual human eyes.
Like others here I find a hard time finding specific evidence or reasons for some of op’s thoughts, but in general it just seems like a recipe for problems when you’re too trusting with ai with all the processes
It's just a random internet dude telling us how he thinks other people should feel about their work.
Of course, if you're just optimizing for the amount of slop you can shove into github each week to appease your manager/PM, then yeah just let the chatbot write the commit messages too.
If we invent a meta-farmer profession (for those who hired a farmer) I will be great meta-farmer, but still suck as a farmer
No wonder we boot up entire browser engines to write simple text editors. But hey, we gotta be first to market to get that VC money, right?
Abstractions are not a convenience, they're a cognitive necessity, compressing large aspects of the problem space into easy to not think about blocks, allowing humans, with their limited working memory, to reason about larger problems. The only reason a seasoned developer can think at a high/system level is because of the abstractions/compressions they've formed in their heads.
Technology exists to make it so we don't have to think about/put time into low level things, so we can do more interesting things instead. Not thinking about banal things is the foundation of progress.
Our end users are who should benefit. You’re the pilot in the seat who doesn’t know what the throttle is and you’re telling the passenger it’s the plane’s fault it’s slow.
And manual steps are good. At least you know what is happening.
The old Unix philosophy. Simple tools that combined become powerful.
If you use _anything_ in production, you better make sure you understand the stack.
The window of what steps technical people should understand in our stack of abstraction is always changing - there is no permanent window we should hold as sacred (outside of a cursory knowledge of the lowest of low levels - being passingly familiar with how machine code works is valuable to everyone) but the levels we should be aware of should exceed the levels that we casually interact with - we should at least be rather comfortable with the level one deeper than the one we often interact with.
Now it's hard to pay attention to code comments and commit messages because costs to produce them is zero and llm doesn't care about communication and your attention budget
With the reliability of current LLMs, if you're outsourcing that much of your thinking, you're producing mainly slop and were never a good engineer to begin with.
If you have a quality threshold beyond "it appears to work" then agents still require a lot of hand holding and guidance
Reading the code yourself, human- or LLM-generated, does.
Vibe coders intentionally don't read LLM-generated code. That is the whole point, the definition of vibe coding.
But those kinds of people aren't likely to read code hand-written by their human colleagues either.
It's not whether an LLM or a human generates the code or not, it's about whether you take the time and effort to read it.
Accusing non-vibe LLM-using coders of outsourcing their thinking is only valid if they don't bother reading code, and that makes them vibe coders.
If you read the code, you're insourcing and internalizing the LLM's thinking, and you're then qualified to criticize it and ask the LLM to fix it, or fix it yourself.
I try to be a conscientious objector -- repossessing the term like reclaiming queer: conscientious about objects, prototypes, and code; conscientiously objecting to evil or sloppy work. Named at a Kaleida meetup with David Ungar's Self team and the ScriptX object-system designers; Joe Weizenbaum's line runs through Heinz Lemke's PIXIE history too.
This week, discussing light pens and PDP-7 drivers with Heinz, Alan Kay, and Lars Brinkhoff, we joked about issuing Conscientious Objector club cards for our wallets -- to show when someone asks us to write terrible, unethical, poorly designed code. Wallet-sized ethics beats /pr-merge-dev skills that merge after one day with no human review.
Not everybody here is a vibe coder. Some of us are just trying to read the diffs.
We're definitely entering a different set of skills and we're costing on our abilities to use these systems raw, and when we start using them via AI, we're losing that raw context.
But when the gains allow us to flesh out where we've never done so, how to say no?
I never spent time on either docs or tests, but since guiding the AI requires several slices through the same logic/architecture/bug footprints, my work flow has to include looking at and maintaining all three.
If I didn't, the AI would be much worse than me doing it myself. Which means at the very least, whoever comes afte rme will have the same hardware and models and maintain the same level of support.
cratermoon•30m ago
PxldLtd•28m ago
poszlem•26m ago
I put his older blog posts there: "We are highly confident this text is entirely human"
horsawlarway•14m ago
AI is a machine that generates content that is supposed to be statistically identical to the content that it was trained on, and it's trained on the content posted here.
The content here will look like AI generated content, and the AI generated content will look like the content here. By fucking definition.
---
Instead we get a bunch of pseudo-intellectual, hokey about how "my AI radar is perfect!" and "I can always spot it because of [insert bullshit about detecting style that's semantically the same as the pre-existing stuff]".
It's just... exhausting.
Yes - there is a lot of AI content on here. Just like there were a bunch of (and still are) under whelming marketing articles on here. Just like there's STILL a bunch of interesting and engaging articles (some of them even written by AI!).
Just vote based on the content and move on with your lives.
People out here wasting time and energy on trying to burn witches. If you want a "sure-fire" AI free experience... Go talk to a real person, in person. Otherwise...
Krssst•22m ago
AI detectors are criticized but classifying stuff into two boxes is probably one of the stuff that is the easiest to measure the accuracy of (as long as one does not put the test set in the training set...).
(well one could see the irony of using ML to detect ML text while complaining about people not caring about understanding anymore, but that's one case where the machine is more reliable than the human)