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.
How do you justify it against all the other abstractions you've accepted and no longer know how to do (or never learned in the first place). Why are the current set of manual steps the right level to be permanently aware of?
IMO, you are a better engineer if you understand how the abstraction works, at any layer of abstraction. You need to pick the point of diminishing returns for yourself, but I think it's pretty uncontroversial to say a developer that understands how a compiler works, and will dig around in a hex editor from time to time will be more knowledgeable and more likely to notice issues sooner than a developer that assumes the compiler is a magic hole in which to throw source code into and perfect executables pop out every time.
"But what about what runs the compiler! What about what runs the OS! What about the physics involved in electron transfer!" Diminishing returns I guess? No one's ever said you needed to understand everything, but understanding or at least being aware of a few layers under you seems to have been common sense forever. Taking one abstraction layer step up doesn't really change that.
I don't think that's the point. The point is that if you outsource thinking to a machine, you will lose your ability to think and reason on your own, and overtime become a worse engineer. Maybe the software ai writes will be fine, idk... But eventually, you will be an objectively worse engineer than someone that doesn't need a machine to think and write for them.
“In order to be effective working at any layer of abstraction you must have in-depth knowledge of the layer below where you’re at”.
To be the most effective at AI assisted engineering (if treated as an abstraction layer) you need to understand how code works, behaves, architectures etc. and what well performing, well built things look like. Doesn’t necessarily mean you have to know everything like you would pre-AI, but enough to be effective.
> I write all my code in assembly on paper then manually translate into opcodes
LOL! There was actually a time (way back when dinosaurs still roamed the Earth) when that was actually how it was done. ;)
(I remember as a kid having to look-up hexadecimal 6502 CPU opcodes on a chart then type in a huge list of hex into the computer to write "machine code" if you wanted anything faster and more powerful than BASIC.)
AI prompts aren't a new abstraction layer, it's automating the same abstraction layer, only with less understanding
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
Abstractions are convenience. They’re not free, there is a cost to any work you ask the computer to do. Just staying at the surface level and never understanding what’s under the top level is why software is slow and bloated today. You’re supposed to move beyond the abstraction, understand what you need underneath and use what you really want to do the task.
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.
AI seems to be the give us an abstraction I've been waiting for: a method to write code at the level of libraries , with libraries working with/adapting to other libraries.
There are plenty of people who understand the stack and ship actually fast software. This might be a skill issue that you’re choosing to frame as a “best practice”, because you do not want to put in the work.
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.
> that you’re choosing to frame as a “best practice”,
I don't follow.
> because you do not want to put in the work.
Yes, just as nobody wants to type opcodes, or write their own http clients, or etc. It's why most of us use higher level languages. Leave the solved things solved, and work on actually interesting/new things! That doesn't mean not understanding, it just means not wasting time on the same boilerplate/code duplicated by millions of developers.
> just as nobody wants to type opcodes, or write their own http clients
This is how you get faster software. You literally look “into” the code, see why stuff is slow, remove the extra work in the library that you do not need, and now your software has a faster server.
Abstractions make software “easy” to build. We’re not looking done easily, we’re looking for done well.
I think it's a good idea to learn how to work through those levels of abstraction, even if only academically, since it yields a lot of insight into why our current abstraction level is the way it is. I don't personally use git CLI on a day to day basis (I use a gasp GUI) but I know what a rebase is and how to recover from a variety of bad states using CLI alone during an emergency. Being aware of how commits actually works lets me know when I can rebase, squash and manipulate history in a safe manner and when such manipulations are likely to cause headaches to those around me.
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.
Commit messages, comments and function names are hard to come up with, that's why we spent years to argue on maximizing value. We also learned to pay attention because we new that this particular name is like that with a reason.
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
The author had 27 years of experience but still found "babysitting git" was painful.
I couldn't remember what's the last time git got in my way. I guess such benefit from AI is probably very specific to their setup. I don't know, maybe the author had some really complex workflow or used some super advanced git features.
I have only about 17 years of experience and I consider myself a moderately advanced git user — I do interactive rebases with squashes, rewords or reordering and I do chunk manipulation per commit all the time. Or at least I used to.
Now I just type into the LLM what I want it do with git and it does it for me, much much quicker. I did not find "babysitting" git painful before, but I today I do feel like doing it manually is a just huge waste of time. A $20 LLM subscription could do this shit for me just as well or better while I spent my time doing more fun and interesting things.
In my experience, those operations require understanding, judgement, and taste. But all of that only matters if I care about the codebase enough for it to matter.
So I don't think the disagreement is really about git. It's about how much of the thinking you're comfortable outsourcing. I do have some repos that's highly vibed up, in those repos I just let AI do whatever it want.
What do you mean with "manually"? Did you type complex commands by hand? Simple commands or using an GUI is faster than explaining an AI what you want to do, no?
I've never seen a GUI that could do anything git faster than me just doing CLI stuff in my terminal. Not even close.
> What do you mean with "manually"?
I type `git rebase -i head~15`, I select the commits I want to include, rearrange lines manually, mark the ones that I want to edit, squash, or reword. I save the buffer, exit, git starts giving me individual commits to edit/reword, so I edit chunks for manually type in the reworded messages etc
These days I just tell LLM what I want and it does git for me as a byproduct and it looks more or less the way I want, except with like 1% typing on my part and 100x times faster.
There's truth in this, git is probably the least of anyone's worries when it comes to understanding your code if you're pulling in any external dependencies in your codebase. For a typical web app these days, you're hundreds of thousands of lines deep in code written by someone else on day 0.
Your statement is technically correct (and mirrors my initial feelings) but the comment below that notes that we accept many other abstractions seems more “meaningful” in the larger scheme of things.
For instance, a software engineer who also understands how to design microprocessors would indeed in my own evaluation be a “better engineer” than me (someone who does not). Yet, I wonder if they would be meaningfully more productive than a good software engineer who “just” understands how microprocessors work..
That's a self selecting vain perspective to conclude with.
Code is just storage medium. The hardware ultimately decides a lot that's out of our hands anyway; hardware never runs code in any structured way so getting intimate with the source structure is wasted effort. You're a worse engineer being a bottleneck in deference to bike shedding.
End of the day code is just labels on a mathematical algorithm that fits a biz edge case. Like a k:v store; sumAllCustomerBalances() is a to the a value (the function logic) that serves a business need. If the business is reliant on that behavior it won't go anywhere. And algorithms need to change as data sets change or new better algorithms are discovered.
Code is disposable. We aren't building bridges.
Whole lot of romanticizing the machine seems to have occurred since I started in this industry back in the 00s. Imo a result of people being online debating the (from my perspective) same old since slashdot was the new hotness.
In conclusion I have a different view and have been successful in hardware and software engineering for almost 30 years now.
Yeah I am mostly retired in late 40s having saved as much as possible as fast as possible and have time on my hands. Am exploring social media I largely ignored while staying busy working.
Besides even if it was 3 years old account it still wouldn't tell the story correctly.
That's a measure as dumb as lines of code = productivity.
I understand; your parents made your account when you were born in 2017. Being 9 explains such shoddy reasoning. Oh wait is that when you got your first job; making an HN account some universal ritual for all new workers? Shoot too bad I missed out in 1999 when I landed my first real hardware engineer job.
You might need to logoff and go live in the real world a while. Coming off like one of those snowflakes I have heard about
So, it's firmware or embedded stuff what you had worked on?
And maybe you're an electronic engineer?
That could make things a bit more understandable, I would be less surprised that you don't give a fuck about the quality of source code (and probably wouldn't be able to write good code in any case).
Remembering and typing git commands does not improve the code or your understanding of it.
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.
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
i've got 4 AI read machines; the smallest will be 72GB; the largest 128GB; they're not wunderkind, but they're all running local models.
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.
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!
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.
I actually think it's much easier now when most contributions are LLM-assisted or LLM-authored.
Like, at my job we went from wild-west everyone uses their own commit message style to very nice uniformed one now when everyone's using Claude Code following the style enforced by AGENTS.md/CLAUDE.md
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.
> 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 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?
I wrote software before Stack Overflow existed, before Git existed, and before most of the tools I use today existed. I think I will survive an API outage :)
> 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 used AI to get a summary of this post, because in 2026, if you are not delegating this kind of reading overhead to AI, you are burning money. And, more importantly, you are ruining your life.
I am still skeptical of ai running everything, given how much it changes and quickly, I’ve not quite given over all control. And I try and use it to learn more about things normally I wouldn’t have time for.
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
> Then, when it was time to review or merge something, we spent even more time digging through the code just to understand what the commit or PR was supposed to do.
> Now I delegate that work to AI.
> […]
> If one day passes and nobody on the team reviews the PR, we merge it
It’s not clear to me whether or not the author is reviewing the code their agent is committing on their behalf, so maybe I shouldn’t be surprised that they don’t seem to care whether or not their team is reviewing it either.
But I am surprised. The author says they used to spend quite a lot of time writing developer guides, hopefully by building consensus among their peers. It seems to me like a big shift if it’s now a workplace where they might not even read each other’s code changes.
Or maybe the dev guides were top-down directions on the way they want the team to do things, and now AI is super compliant and they’re living the dream.
Author here: All code before removing [WIP] in a PR has been humanly reviewed, tested, then double and tripled checked with /skills. Then it comes code review, answering comments, etc.
AI discussions these days remind me of college when I agreed to "debate" some Christians. You can assign the camps however you want to assume. But the point is that there is not going to be a lot of constructive discussion.
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.
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.
I feel like if the logic in git were just a bit more sophisticated, many of these issues wouldn't even arise. Most of these are because someone foolishly (usually me) merged in the wrong direction for convenience's sake, and now I have a duplicated set of commits. It's not like Claude is doing anything very sophisticated; it's just looking at commit hashes and seeing what the unique changes are.
I think people are better developers when they slow down. But I also think that makes them worth less in the market. Pretty clear from existing software quality that quality software is not requisite for successful business.
Leslie Lamport famously said that you should be thinking above the code. It doesn't mean you are on ly high level and handwavy. I think agents are making us unthinking above the code
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
This is what I do mainly. I spend more time designing the solution, iterating by hand when it matters and anything that should be automated, let it be.
Yeah, one developer I recently had a chat with on Chatto (recently featured here on Hacker News) actually wrote the core code and project layout by hand before invoking the LLM and found that he had to hand-hold it a lot less because he had given it solid foundation to work from. That design stage you speak of there and the "iterating by hand when it matters" is a big part of what really helps the models do their part of the job a lot better. That's what the "vibe coders" (and often their bosses) don't seem to understand (yet), but they'll figure it out eventually I'm sure. Or maybe not. I guess we'll have to wait and see how it all turns out. In the meantime, we can have fun playing with the new tools they've given us. ;)
Maybe I'm alone in this, but I've always found the git GUIs more confusing than just typing out the commands. They never seem to map well to how I work.
Something I've personally noticed over the years is that when I take the time to hand to write thoughtful commit messages, the overall quality of my technical work tends to increase as well. My theory is that the process, while boring and time-consuming, forces me to think holistically about how my current task fits within the system and find gaps in my own understanding and implementation. I sympathize with the author's impulse to ignore these tedious details (I, too, love slacking off at work), but, at least for myself, my decades of (admittedly unstructured) A/B testing "how good is the software I write if I don't do this" unambiguously points to it being a somewhat load-bearing piece of my effectiveness as a software developer.
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.
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.
Force yourself to use git with the command line for as long as it takes to not confuse you with day to day operations. Then choose whatever interface you want to make your life easier.
Funny how all that stuff one spends so much time and effort learning was "a waste of time and effort" to everyone that has zero idea how anything works "under the hood", but the moment it breaks, you're always the guy that has to fix it in the end. I honestly believe that's one of the biggest contributing factors to "developer burn-out". Being ignored and ridiculed repeatedly (Shut up, Nerd. Nobody wants to hear you yammer about how to waste more time on backups and security.) until something breaks and then being called on to fix it like you're some sorta robot or something... (It's fixed? Great! Back to your cubicle now, code monkey!) And now all the scumbags at the top want to replace us all with "AI"? I mean, why even bother anymore? What's the point? Where's the reward for all the hard work and caring about doing a good job? What? Another kick in the nuts while I'm already down? That's the reward? Gee, thanks Boss... May I have another?
> @meerita: I think you are arguing against a point I did not make. (Sorry, it won't let me directly reply to your comment for some odd reason.)
I'm not actually "arguing against a point" you made or that anyone else made. It was more of a random rant triggered by how things are these days, and how they got there. Sometimes some of these articles just really rub some salt in the wounds... Also, I totally agree with the rest of your statements there following the above comment. Automation is not at all a bad thing, and neither is AI, when used properly by folks that "know how to hold the tool properly". ;)
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.
Despite having long valued statically typed languages, and IDEs with excellent refactoring tools (VS + ReSharper was a godsend back in the day before MS implemented most of the must-have features themselves)... I sort of disagree.
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.
My tools will catch string matches in docs, but if you're using reflection or etc where it's "too weird" for tools I can see it being useful there, yeah.
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
I instruct the agents to do the commit messages they way i want them written. They don't produce a book everytime, they produce what I think it's useful.
Codex is the opposite problem. If you don't aggressively prompt it, and let it write commit messages it will literally just do one incomprehensible line.
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.
At the end of the day LLM output is not deterministic, and the burden shifts from writing code to reviewing it. It makes sense to cover the review surface with deterministic checks/validations as much as possible - unit test, linters, static analysis tools, e2e integration test etc. one gap I noticed when it comes to such tools is that they are generally language/stack specific and don't cover things like file/directory structure/naming, file relationships/references, use of potentially harmful Unicode [0], general file/config structure, permissions, broken symlinks, files which should not be committed but are, etc. , etc. I've been building a tool - a general repo shape/structure linter, with extensible config/rules - to cover these cases in a deterministic way [1] [2].
I have my own tooling set in every project https://www.minid.net/2026/6/1/my-ai-workflow. I have couple dozens of make commands, that perform all the checks. I can do them manually after I finish coding or, I relegate these to the AI. If something is wrong, that's when I intervene. If nothing is wrong, that's because I've spent quite some time checking every single change.
I'm curious what validations/checks you find most useful in your workflows? alint basically started with me taking a bunch of make/shell scripts I already had and combining them into one tool, with some added niceties, and much better performance.
I find manually reviewing every change simply does not scale past a certain point. You need to rely on AI reviews and deterministic static analysis tooling, tests, modeling/verification, etc. to do the much of the heavy lifting.
I let agents write my code but not my commits. I think I gain some understanding by doing `git diff` and then writing the (brief) commit message myself.
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.
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.
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.
I constantly hear other engineers talk about how knowing the cli, git, Linux, whatever is useless. But then I’m the one that gets called when shit breaks, so it must not be that useless. If knowing how shit works at a low level is so useless they why do I need to bail colleagues out so much.
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.
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.
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.
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.
Subjective or not, there wasn't a single example of a "good" AI generated commit message or refactoring or whatever in the whole thing. If they're so good why not just show it? It's just weird.
"My new car is much better than my old car" is not something you'd reference your 27 years of car experience as evidence for--you'd just say what's good about your new car and what was bad about your old one, right?
"Newer cars are much better than older cars". How about this?
It'd be weird to ask for evidence of that statement cause it's very generic and there's like a million instances of newer cars that are shit and old cars that are brilliant. But in general the statement totally holds and you'd need to be insane to be arguing otherwise.
Having 27 years of driving cars experience would add weight to the opinion stated, but otherwise not provide any substantive credible evidence.
I only have 17 years of experience and I fully agree with the author here. This is my personal opinion and I would not be fucked to respond to any demands for evidence since those demands are not meant to be satisfiable in the first place.
When I read commit messages and comments Claude makes a large fraction of the time they don't seem terribly related to the code, nor necessarily relevant to the problem at hand. The commits don't generally make a great deal of logical, linear sense either. Reviewing Claude PRs commit-by-commit is kind of nauseating. I only have 12yrs of experience though so I must be wrong. I'll defer to you guys. Sure would be nice to know wtf everyone's so excited about though I just don't get it.
News flash: you can tell LLMs how to do shit and they're generally pretty good at following instructions.
Those things are good enough to solve novel math problems I've never even heard about, surely it can figure out how you like your commit messages and apply it a million times over in the time it'd take you to make yourself a cup of coffee.
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?"
As much as I disagree with the general consensus that the article follows of "delegating non-automatable work that requires thinking and understanding to the machine because it is boring, even though the machine is unreliable", according to Pangram this does seem human-written (confidence low).
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)
Hmm, if you read his previous blog posts pre-ai the tone is not much different. I hate the idea that this dude may just sound like AI at this point by accident.
It somewhat boggles my mind that there are an incredible number of persistent, useless, and annoying comments on here every day accusing any and every article of being AI slop.
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...
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.
How do you justify it against all the other abstractions you've accepted and no longer know how to do (or never learned in the first place). Why are the current set of manual steps the right level to be permanently aware of?
IMO, you are a better engineer if you understand how the abstraction works, at any layer of abstraction. You need to pick the point of diminishing returns for yourself, but I think it's pretty uncontroversial to say a developer that understands how a compiler works, and will dig around in a hex editor from time to time will be more knowledgeable and more likely to notice issues sooner than a developer that assumes the compiler is a magic hole in which to throw source code into and perfect executables pop out every time.
"But what about what runs the compiler! What about what runs the OS! What about the physics involved in electron transfer!" Diminishing returns I guess? No one's ever said you needed to understand everything, but understanding or at least being aware of a few layers under you seems to have been common sense forever. Taking one abstraction layer step up doesn't really change that.
A farmer producing meat is a better farmer than me even if I hire my own farmer.
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
But I don't want farmers, I want meat
I don't think that's the point. The point is that if you outsource thinking to a machine, you will lose your ability to think and reason on your own, and overtime become a worse engineer. Maybe the software ai writes will be fine, idk... But eventually, you will be an objectively worse engineer than someone that doesn't need a machine to think and write for them.
Sure you don’t need a farmer factory ?
Well clearly not, but you might need an AbstractBeanFarmerFactoryAbstractFactory.
Heard a quote I liked today.
“In order to be effective working at any layer of abstraction you must have in-depth knowledge of the layer below where you’re at”.
To be the most effective at AI assisted engineering (if treated as an abstraction layer) you need to understand how code works, behaves, architectures etc. and what well performing, well built things look like. Doesn’t necessarily mean you have to know everything like you would pre-AI, but enough to be effective.
Exactly, automation of manual tasks, doesn't mean it will wipe your knowledge or your ability to keep reviewing commits, writing comments on PRs, etc.
Because the abstractions of old still required you to read man pages and learn stuff.
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 best engineers hand-edit .git
Edit: But actually, one of my favorite Git explainers is https://wildlyinaccurate.com/a-hackers-guide-to-git/
I write all my code in assembly on paper then manually translate into opcodes
> I write all my code in assembly on paper then manually translate into opcodes
LOL! There was actually a time (way back when dinosaurs still roamed the Earth) when that was actually how it was done. ;)
(I remember as a kid having to look-up hexadecimal 6502 CPU opcodes on a chart then type in a huge list of hex into the computer to write "machine code" if you wanted anything faster and more powerful than BASIC.)
My dad worked with punched cards.
AI prompts aren't a new abstraction layer, it's automating the same abstraction layer, only with less understanding
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
Abstractions are convenience. They’re not free, there is a cost to any work you ask the computer to do. Just staying at the surface level and never understanding what’s under the top level is why software is slow and bloated today. You’re supposed to move beyond the abstraction, understand what you need underneath and use what you really want to do the task.
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?
I disagree.
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.
AI seems to be the give us an abstraction I've been waiting for: a method to write code at the level of libraries , with libraries working with/adapting to other libraries.
There are plenty of people who understand the stack and ship actually fast software. This might be a skill issue that you’re choosing to frame as a “best practice”, because you do not want to put in the work.
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.
> that you’re choosing to frame as a “best practice”,
I don't follow.
> because you do not want to put in the work.
Yes, just as nobody wants to type opcodes, or write their own http clients, or etc. It's why most of us use higher level languages. Leave the solved things solved, and work on actually interesting/new things! That doesn't mean not understanding, it just means not wasting time on the same boilerplate/code duplicated by millions of developers.
If you think software performance is a solved problem today, there is nothing more I have to say.
Consumer software is slower than ever. And only getting worse.
Please reread this comment thread. I never spoke to software performance being solved.
> just as nobody wants to type opcodes, or write their own http clients
This is how you get faster software. You literally look “into” the code, see why stuff is slow, remove the extra work in the library that you do not need, and now your software has a faster server.
Abstractions make software “easy” to build. We’re not looking done easily, we’re looking for done well.
I think it's a good idea to learn how to work through those levels of abstraction, even if only academically, since it yields a lot of insight into why our current abstraction level is the way it is. I don't personally use git CLI on a day to day basis (I use a gasp GUI) but I know what a rebase is and how to recover from a variety of bad states using CLI alone during an emergency. Being aware of how commits actually works lets me know when I can rebase, squash and manipulate history in a safe manner and when such manipulations are likely to cause headaches to those around me.
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.
Manual knowledge of git to get out of tricky situations will be as passe as using log book for multiplication. It's just not required anymore.
Who will get you out of such a tricky situation?
Any model, including inexpensive ones. It's not a hard problem.
[flagged]
[flagged]
Commit messages, comments and function names are hard to come up with, that's why we spent years to argue on maximizing value. We also learned to pay attention because we new that this particular name is like that with a reason.
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
The author had 27 years of experience but still found "babysitting git" was painful.
I couldn't remember what's the last time git got in my way. I guess such benefit from AI is probably very specific to their setup. I don't know, maybe the author had some really complex workflow or used some super advanced git features.
Don’t beat me, I’m getting old. Even Git is starting to feel like unnecessary cardio.
I have only about 17 years of experience and I consider myself a moderately advanced git user — I do interactive rebases with squashes, rewords or reordering and I do chunk manipulation per commit all the time. Or at least I used to.
Now I just type into the LLM what I want it do with git and it does it for me, much much quicker. I did not find "babysitting" git painful before, but I today I do feel like doing it manually is a just huge waste of time. A $20 LLM subscription could do this shit for me just as well or better while I spent my time doing more fun and interesting things.
In my experience, those operations require understanding, judgement, and taste. But all of that only matters if I care about the codebase enough for it to matter.
So I don't think the disagreement is really about git. It's about how much of the thinking you're comfortable outsourcing. I do have some repos that's highly vibed up, in those repos I just let AI do whatever it want.
What do you mean with "manually"? Did you type complex commands by hand? Simple commands or using an GUI is faster than explaining an AI what you want to do, no?
I've never seen a GUI that could do anything git faster than me just doing CLI stuff in my terminal. Not even close.
> What do you mean with "manually"?
I type `git rebase -i head~15`, I select the commits I want to include, rearrange lines manually, mark the ones that I want to edit, squash, or reword. I save the buffer, exit, git starts giving me individual commits to edit/reword, so I edit chunks for manually type in the reworded messages etc
These days I just tell LLM what I want and it does git for me as a byproduct and it looks more or less the way I want, except with like 1% typing on my part and 100x times faster.
I doubt you can beat a skill command. It's just /my-skill-do-the-job and that's it.
There's truth in this, git is probably the least of anyone's worries when it comes to understanding your code if you're pulling in any external dependencies in your codebase. For a typical web app these days, you're hundreds of thousands of lines deep in code written by someone else on day 0.
Your statement is technically correct (and mirrors my initial feelings) but the comment below that notes that we accept many other abstractions seems more “meaningful” in the larger scheme of things.
For instance, a software engineer who also understands how to design microprocessors would indeed in my own evaluation be a “better engineer” than me (someone who does not). Yet, I wonder if they would be meaningfully more productive than a good software engineer who “just” understands how microprocessors work..
Maybe it does make you a better engineer because when you look back on a commit that you were rushed on, you don't see a commit message of "Fixed it".
That's a self selecting vain perspective to conclude with.
Code is just storage medium. The hardware ultimately decides a lot that's out of our hands anyway; hardware never runs code in any structured way so getting intimate with the source structure is wasted effort. You're a worse engineer being a bottleneck in deference to bike shedding.
End of the day code is just labels on a mathematical algorithm that fits a biz edge case. Like a k:v store; sumAllCustomerBalances() is a to the a value (the function logic) that serves a business need. If the business is reliant on that behavior it won't go anywhere. And algorithms need to change as data sets change or new better algorithms are discovered.
Code is disposable. We aren't building bridges.
Whole lot of romanticizing the machine seems to have occurred since I started in this industry back in the 00s. Imo a result of people being online debating the (from my perspective) same old since slashdot was the new hotness.
In conclusion I have a different view and have been successful in hardware and software engineering for almost 30 years now.
Ymmv
> and have been successful in hardware and software engineering for almost 30 years now.
as shown by your one day old account
Yeah I am mostly retired in late 40s having saved as much as possible as fast as possible and have time on my hands. Am exploring social media I largely ignored while staying busy working.
Besides even if it was 3 years old account it still wouldn't tell the story correctly.
That's a measure as dumb as lines of code = productivity.
I understand; your parents made your account when you were born in 2017. Being 9 explains such shoddy reasoning. Oh wait is that when you got your first job; making an HN account some universal ritual for all new workers? Shoot too bad I missed out in 1999 when I landed my first real hardware engineer job.
You might need to logoff and go live in the real world a while. Coming off like one of those snowflakes I have heard about
Yeah, sure
> hardware and software engineering
So, it's firmware or embedded stuff what you had worked on?
And maybe you're an electronic engineer?
That could make things a bit more understandable, I would be less surprised that you don't give a fuck about the quality of source code (and probably wouldn't be able to write good code in any case).
Remembering and typing git commands does not improve the code or your understanding of it.
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.
>already outsourced their thinking
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
i've got 4 AI read machines; the smallest will be 72GB; the largest 128GB; they're not wunderkind, but they're all running local models.
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.
[flagged]
[dead]
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 imagine most people don't give a damn about others' workflows. But they're not posting about it, because they don't give a damn.
screaming for attention really.
Sure, do whatever you want on your own projects.
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.
I actually think it's much easier now when most contributions are LLM-assisted or LLM-authored.
Like, at my job we went from wild-west everyone uses their own commit message style to very nice uniformed one now when everyone's using Claude Code following the style enforced by AGENTS.md/CLAUDE.md
You’re mistaking how with what. We’re talking about „how” here
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.
> 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 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?
I wrote software before Stack Overflow existed, before Git existed, and before most of the tools I use today existed. I think I will survive an API outage :)
> 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 used AI to get a summary of this post, because in 2026, if you are not delegating this kind of reading overhead to AI, you are burning money. And, more importantly, you are ruining your life.
I don't get these kinds of posts. Zero how-to, zero share about the tradeoffs the author took.
It's just a random internet dude telling us how he thinks other people should feel about their work.
I am still skeptical of ai running everything, given how much it changes and quickly, I’ve not quite given over all control. And I try and use it to learn more about things normally I wouldn’t have time for.
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
> Then, when it was time to review or merge something, we spent even more time digging through the code just to understand what the commit or PR was supposed to do.
> Now I delegate that work to AI.
> […]
> If one day passes and nobody on the team reviews the PR, we merge it
It’s not clear to me whether or not the author is reviewing the code their agent is committing on their behalf, so maybe I shouldn’t be surprised that they don’t seem to care whether or not their team is reviewing it either.
But I am surprised. The author says they used to spend quite a lot of time writing developer guides, hopefully by building consensus among their peers. It seems to me like a big shift if it’s now a workplace where they might not even read each other’s code changes.
Or maybe the dev guides were top-down directions on the way they want the team to do things, and now AI is super compliant and they’re living the dream.
Author here: All code before removing [WIP] in a PR has been humanly reviewed, tested, then double and tripled checked with /skills. Then it comes code review, answering comments, etc.
AI discussions these days remind me of college when I agreed to "debate" some Christians. You can assign the camps however you want to assume. But the point is that there is not going to be a lot of constructive discussion.
>Ironically, the audience that values all that structure the most is now LLMs.
LLMs are not people and they don't have values.
“The consumer that maximizes utility of that structure is now an LLM”
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.
A rebase that can't just fast-forward?
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.
I feel like if the logic in git were just a bit more sophisticated, many of these issues wouldn't even arise. Most of these are because someone foolishly (usually me) merged in the wrong direction for convenience's sake, and now I have a duplicated set of commits. It's not like Claude is doing anything very sophisticated; it's just looking at commit hashes and seeing what the unique changes are.
Refactoring stuff has been easy for a long time.
Moving git commits or stuff that's not yet committed to another branch is not that difficult as well.
Sure, with AI you don't need to know how to do it. I works argue though that refactoring is faster and easier than having the AI doing it for you.
Commit messages, yes, that's much easier with AI.
I think people are better developers when they slow down. But I also think that makes them worth less in the market. Pretty clear from existing software quality that quality software is not requisite for successful business.
Leslie Lamport famously said that you should be thinking above the code. It doesn't mean you are on ly high level and handwavy. I think agents are making us unthinking above the code
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
it's tough for people here to admit, but AI is good at summarizing and that includes commit messages and PR fields
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
This is what I do mainly. I spend more time designing the solution, iterating by hand when it matters and anything that should be automated, let it be.
Yeah, one developer I recently had a chat with on Chatto (recently featured here on Hacker News) actually wrote the core code and project layout by hand before invoking the LLM and found that he had to hand-hold it a lot less because he had given it solid foundation to work from. That design stage you speak of there and the "iterating by hand when it matters" is a big part of what really helps the models do their part of the job a lot better. That's what the "vibe coders" (and often their bosses) don't seem to understand (yet), but they'll figure it out eventually I'm sure. Or maybe not. I guess we'll have to wait and see how it all turns out. In the meantime, we can have fun playing with the new tools they've given us. ;)
Maybe I'm alone in this, but I've always found the git GUIs more confusing than just typing out the commands. They never seem to map well to how I work.
Never had a git GUI that worked for me either
Something I've personally noticed over the years is that when I take the time to hand to write thoughtful commit messages, the overall quality of my technical work tends to increase as well. My theory is that the process, while boring and time-consuming, forces me to think holistically about how my current task fits within the system and find gaps in my own understanding and implementation. I sympathize with the author's impulse to ignore these tedious details (I, too, love slacking off at work), but, at least for myself, my decades of (admittedly unstructured) A/B testing "how good is the software I write if I don't do this" unambiguously points to it being a somewhat load-bearing piece of my effectiveness as a software developer.
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.
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.
Yes but you do not have to invoke them directly yourself anymore
Absolutely and I love it to be completely honest
Force yourself to use git with the command line for as long as it takes to not confuse you with day to day operations. Then choose whatever interface you want to make your life easier.
Hey Claude, Check if Claude 2, Claude 3 and Claude 4 are done yet, then merge their changes.
Hey cron, keep reminding Claude to do that while I drink.
Funny how all that stuff one spends so much time and effort learning was "a waste of time and effort" to everyone that has zero idea how anything works "under the hood", but the moment it breaks, you're always the guy that has to fix it in the end. I honestly believe that's one of the biggest contributing factors to "developer burn-out". Being ignored and ridiculed repeatedly (Shut up, Nerd. Nobody wants to hear you yammer about how to waste more time on backups and security.) until something breaks and then being called on to fix it like you're some sorta robot or something... (It's fixed? Great! Back to your cubicle now, code monkey!) And now all the scumbags at the top want to replace us all with "AI"? I mean, why even bother anymore? What's the point? Where's the reward for all the hard work and caring about doing a good job? What? Another kick in the nuts while I'm already down? That's the reward? Gee, thanks Boss... May I have another?
> @meerita: I think you are arguing against a point I did not make. (Sorry, it won't let me directly reply to your comment for some odd reason.)
I'm not actually "arguing against a point" you made or that anyone else made. It was more of a random rant triggered by how things are these days, and how they got there. Sometimes some of these articles just really rub some salt in the wounds... Also, I totally agree with the rest of your statements there following the above comment. Automation is not at all a bad thing, and neither is AI, when used properly by folks that "know how to hold the tool properly". ;)
[flagged]
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.
Despite having long valued statically typed languages, and IDEs with excellent refactoring tools (VS + ReSharper was a godsend back in the day before MS implemented most of the must-have features themselves)... I sort of disagree.
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.
My tools will catch string matches in docs, but if you're using reflection or etc where it's "too weird" for tools I can see it being useful there, yeah.
[dead]
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
I instruct the agents to do the commit messages they way i want them written. They don't produce a book everytime, they produce what I think it's useful.
Just put your last sentence in your AGENTS.md then
No, it should be short when there's little to say, and long when there's lots to say about things best written in a commit message
Codex is the opposite problem. If you don't aggressively prompt it, and let it write commit messages it will literally just do one incomprehensible line.
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.
At the end of the day LLM output is not deterministic, and the burden shifts from writing code to reviewing it. It makes sense to cover the review surface with deterministic checks/validations as much as possible - unit test, linters, static analysis tools, e2e integration test etc. one gap I noticed when it comes to such tools is that they are generally language/stack specific and don't cover things like file/directory structure/naming, file relationships/references, use of potentially harmful Unicode [0], general file/config structure, permissions, broken symlinks, files which should not be committed but are, etc. , etc. I've been building a tool - a general repo shape/structure linter, with extensible config/rules - to cover these cases in a deterministic way [1] [2].
[0] https://snyk.io/articles/defending-against-glassworm/
[1] https://github.com/asamarts/alint
[2] https://alint.org/
I have my own tooling set in every project https://www.minid.net/2026/6/1/my-ai-workflow. I have couple dozens of make commands, that perform all the checks. I can do them manually after I finish coding or, I relegate these to the AI. If something is wrong, that's when I intervene. If nothing is wrong, that's because I've spent quite some time checking every single change.
I'm curious what validations/checks you find most useful in your workflows? alint basically started with me taking a bunch of make/shell scripts I already had and combining them into one tool, with some added niceties, and much better performance.
I find manually reviewing every change simply does not scale past a certain point. You need to rely on AI reviews and deterministic static analysis tooling, tests, modeling/verification, etc. to do the much of the heavy lifting.
"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?
I let agents write my code but not my commits. I think I gain some understanding by doing `git diff` and then writing the (brief) commit message myself.
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.
[dead]
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.
No hands, I just roll my eyes way up behind my eyelids and instruct the machine teletypepathically.
I have switched to vocalised morse code. My colleagues love me.
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.
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.
I constantly hear other engineers talk about how knowing the cli, git, Linux, whatever is useless. But then I’m the one that gets called when shit breaks, so it must not be that useless. If knowing how shit works at a low level is so useless they why do I need to bail colleagues out so much.
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.
Our commit messages have become useless since we adopted a shared agent skill for making commits.
The LLM tends to fill the messages with irrelevant details while still failing to mention what the change actually does.
Exactly.
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.
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.
makes sense? commit messages is pre ai era, we need a new git, and people are already working on it
whats the point of a commit message if it can be inferred by an agent from the diff?
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.
> AI does this job better.
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.
This is a subjective statement. What kind of evidence you're expecting here?
Like:
— My new car is much better than my old car — Hurr durr, how can you make those confident statements without showing any evidence, huh?
It's not that deep.
Subjective or not, there wasn't a single example of a "good" AI generated commit message or refactoring or whatever in the whole thing. If they're so good why not just show it? It's just weird.
"My new car is much better than my old car" is not something you'd reference your 27 years of car experience as evidence for--you'd just say what's good about your new car and what was bad about your old one, right?
"Newer cars are much better than older cars". How about this?
It'd be weird to ask for evidence of that statement cause it's very generic and there's like a million instances of newer cars that are shit and old cars that are brilliant. But in general the statement totally holds and you'd need to be insane to be arguing otherwise.
Having 27 years of driving cars experience would add weight to the opinion stated, but otherwise not provide any substantive credible evidence.
I only have 17 years of experience and I fully agree with the author here. This is my personal opinion and I would not be fucked to respond to any demands for evidence since those demands are not meant to be satisfiable in the first place.
When I read commit messages and comments Claude makes a large fraction of the time they don't seem terribly related to the code, nor necessarily relevant to the problem at hand. The commits don't generally make a great deal of logical, linear sense either. Reviewing Claude PRs commit-by-commit is kind of nauseating. I only have 12yrs of experience though so I must be wrong. I'll defer to you guys. Sure would be nice to know wtf everyone's so excited about though I just don't get it.
News flash: you can tell LLMs how to do shit and they're generally pretty good at following instructions.
Those things are good enough to solve novel math problems I've never even heard about, surely it can figure out how you like your commit messages and apply it a million times over in the time it'd take you to make yourself a cup of coffee.
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?"
You are outsourcing your life to AI? Good for you, but don't be so pretentious, please.
[dead]
[flagged]
he may be in Barcelona, but he's got silicon valley level of entitlement, arrogance and confidence in one's opinion.
"don't believe in yourself, don't deceive with belief"
(David Bowie)
If you can't be bothered to write it, why should I bother reading it?
As much as I disagree with the general consensus that the article follows of "delegating non-automatable work that requires thinking and understanding to the machine because it is boring, even though the machine is unreliable", according to Pangram this does seem human-written (confidence low).
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)
Hmm, if you read his previous blog posts pre-ai the tone is not much different. I hate the idea that this dude may just sound like AI at this point by accident.
It somewhat boggles my mind that there are an incredible number of persistent, useless, and annoying comments on here every day accusing any and every article of being AI slop.
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...
[dead]
[dead]
"We are highly confident this text was AI generated" from gptzero, which is not perfect but is pretty spot on quite often. Just another small hint.
I put his older blog posts there: "We are highly confident this text is entirely human"
I see a flamebait title, I click flag. Simple as.