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)
Comments as well. It's exactly the type of commenting they taught us not to do because it was useless. I'm sure it's also a negative to the LLMs as well by polluting the memory with useless info.
I'm the opposite personally; I love automating things (not my main job, but it makes things easier in the long run) but bash sucks my soul out.
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.
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.
Commit messages now do double duty: log of the changes, but also signing off that you've read and understand the code, are taking responsibility for it under your own name.
The second part is an emerging convention but it's fairly common from what I've seen. IDK maybe no one will be reading or writing code in 18 months but if they are we'll need to separate these two things.
Secondarily but probably more importantly: it's real easy to read something and say "yep I understand that." It's a lot harder to fool yourself when you have to actually write down, with your own brain, what that thing you read does. If you're not doing this you must have incredible discipline elsewhere to make up for it.
All above comes at a cost of author slowly starting to understand less and less code in their own projects.
Then in other projects as well.
After the initial boost is over they will have to pay money just to stay afloat because they have already outsourced their thinking.
I’m not anti AI, but I’m very worried about this bragging “you are not better engineer if you do things yourself”. Yes, you are, it all comes in small details.
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.
Yea you're completely correct, any computer science degree worth it's salt will cover computer architecture, networks, basic maths, etc. Do I remember every little detail about how transistors,the memory bus, or every network topology works? nah of course not, but does having a reasonable overview of how it all works under hood help inform system design when you're tackling the hard problems, performance, reliability, security,etc? Knowledge is power, so more knowledge can never be a bad thing.
“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.
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
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
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; consciously 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 and Alan Kay, 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.
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.
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).
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 per-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 have slightly different experience. Any time during deep work on codebase when I need to stop and switch lanes to study how exactly did .SECONDEXPANSION work or which of "git reset" "git checkout" flavours will do the thing I need instead of wiping all my work, or what magic sauce ingredient again prevents Dockerfile running on Podman — that is when I start understanding less the source code of my project. Because I am trying to multitask two deep study sessions. Going "computer, make this branch contain that stuff" and then proceeding with debugging kernel crash sits very well with me
I've recently had an interesting discussion on AI usage by students with a couple of friends who are all professors or lecturers in different fields. They report that AI makes their job harder, especially because it widens the gap between students:
Students who would have straight up failed before now produce passable essays/projects, but do not understand what they are handing in. They outsource their thinking and are overall worse than before. Students who would have excelled already pre-ai, are now even better. They use AI to learn more effectively, do broader research, and have more time to do deep research because they can outsource the grindy stuff.
This is very similar for software engineers. I'm not much faster at implementing features than before AI, despite heavily relying on agentic coding (95% of code is ai generated), but I've had significantly fewer bugs in production, less feature change requests (because w spend much more time designing/experimenting), and we are able to drive-by refactors or vulnerability fixes we would have grudgingly ignored before.
My coding skills are atrophying, but that was never interesting to me anyway. I'm getting better at systems design, cyber sec, data modelling and requirements engineering, because I have much more time to spend on it now. If LLMs disappeared tomorrow, I'd have to relearn coding, but I think it is significantly more likely that hand coding will become a specialist niche for experts.
I'd much rather use an AI to tell me what the cosebase does than read someone's AI generated comments. By the time I'm asking an AI to do it it'll probably be a more capable model than the one generating comments
Ew at the bit about letting AI write your commit messages. Don’t bother - if you didn’t take the time to write it why should anyone take the time to read it. I’ll just ask my AI to extract the intent from the actual code if I need it.
Picking on a particular nit here, but I think it is indicative of the broader flaw with this argument:
To rename `PostgreSQLClient`, I press F2 and type the new name, and I'm done.
I don't have to wait for an agent to "perform the refactor, update references, run the tests, fix the missing pieces, and mark the relevant checkboxes in the ticket" (btw, what checkboxes..?)
I press a key, type my change, and I'm done.
Wasting time waiting for tokens is also wasting time.
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.
Just from the title I didn't even realize this would be a post about AI. I thought it was going to be about using Git in your IDE or other git UI tooling.
> In 2026, if you are not delegating this kind of engineering overhead to AI, you are burning money. And, more importantly, you are burning your life.
AI use can be a divisive topic among developers but I generally believe it is a useful tool. That said, please don’t broadly advise people on what’s best for their life. It will only make people push away from AI more.
I find I keep the git add to the be one thing I keep track of (in production services, if not throw-away or non-prod visualization vibe coded things). I've never even used git add . - I git diff each file one by one, and git add them in one by one. It's needed to prevent my own errors, and it's needed to keep some model of what the AI is doing in my mind. Now, I myself don't do much commenting in line; I tended to rely on good names, good function comments, good module descriptions as comments at the top of a file; for the flow, I would log a lot and hopefully the failure/success logs made the thinking clear for what is going on and why. But I let the AI keep all its comments, till they crowd out the code at least.
Replying to a comment below (on shell scripts), I use it for shell scripts, python "get this data and slice it in these ways" and elisp, all the time. 30 seconds to get and answer instead of 30 minutes. Being able to do them in 30 minutes took a lot of skill and practice, but the pleasure of finishing that for an ad hoc thing when I really just want the data output is something I can give up.
I still tell the AI exactly what to do and you need to understand what reset, rebase, pull, and checkout actually do. Otherwise you end up with a mess.
I don't keep LLMs sandboxed away from executing git commands because I think it makes me a better engineer, I do it because as useful as LLMs can be for programming I still don't trust them to not occasionally attempt to burn my house down.
Delivery is becoming a sequence of checks, not a ritual
The same thing happens when it is time to deliver.
First, I invoke my /definition-of-done skill. It checks whether the implementation covers what was stated in the PR and in the plan. It checks tests and the other validations I care about. It tells me when something looks unusual, broken, or missing. When everything looks good, I invoke another skill, /pr-check-release. That checks the remote PR, updates labels, removes [WIP], adds [RFC], updates the description, and prepares the change for review. If one day passes and nobody on the team reviews the PR, we merge it. The agent also tracks that condition for me, so I can run /pr-merge-dev, and it takes care of the process: merge the PR, delete the remote branch, delete the local branch, and pull dev back into a fresh state. None of these steps is particularly difficult. That is exactly the point.
But then:
I still care about all of those things. Probably more than most people.
Obviously the author has irreversibly became AI-pilled and the day API costs balloon or APIs are down, what work will the author do?
I love using AI but please read the diffs and process them with your human brains and eyes. Spin up your containers manually, test the app, MANUALLY.
Talk to real users face to face.
Outsourcing the grunt work is fine, but there's a fine line between that and becoming a button-presser.
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 :)
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.
What is with all these people that are so interested in other people's workflow to the point of writing weirdly aggressive manifestos like this. "If you don't do it like me, you're wrong!" I would like to be the first person to state that I don't give a damn about your workflow. Do whatever you want!
I think these are discussions about workplace / team policy that get extended into a post.
I recognize these from different dev teams where it was agreed that a "how much AI" policy is needed, but the actual policy was very hard to settle on.
IDK, you need a few tools to unbreak a wedged box so you can get to your fancy tools even if you only want the low effort tools. Otherwise when the Cursor config file is wedged? Or the machine came up and doesnt see the network? The agent doesn't do you any good if you can't launch it.
"Mr. Anderson, what good will a Claude Max plan do for you if you can't quit vim?"
These days, I am leaning heavily on Claude to deal with all the git issues that I never wanted to be bothered with. A rebase that can't just fast-forward? That's a job for Claude. A merge conflict that really shouldn't be a problem? Claude deals with it. These are things I never wanted to have to learn in the first place, and I don't feel like reserving a part of my brain to remember how to deal with these things is worthwhile. In almost all cases, there is no actual decision that needs to be made, it's purely a mechanical process.
104 comments
[ 3579 ms ] story [ 243 ms ] threadAI 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)
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.
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.
"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.
“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.
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; consciously 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 and Alan Kay, 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.
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..
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
as shown by your one day old account
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
> 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).
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.
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.
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"?
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.
Students who would have straight up failed before now produce passable essays/projects, but do not understand what they are handing in. They outsource their thinking and are overall worse than before. Students who would have excelled already pre-ai, are now even better. They use AI to learn more effectively, do broader research, and have more time to do deep research because they can outsource the grindy stuff.
This is very similar for software engineers. I'm not much faster at implementing features than before AI, despite heavily relying on agentic coding (95% of code is ai generated), but I've had significantly fewer bugs in production, less feature change requests (because w spend much more time designing/experimenting), and we are able to drive-by refactors or vulnerability fixes we would have grudgingly ignored before.
My coding skills are atrophying, but that was never interesting to me anyway. I'm getting better at systems design, cyber sec, data modelling and requirements engineering, because I have much more time to spend on it now. If LLMs disappeared tomorrow, I'd have to relearn coding, but I think it is significantly more likely that hand coding will become a specialist niche for experts.
To rename `PostgreSQLClient`, I press F2 and type the new name, and I'm done.
I don't have to wait for an agent to "perform the refactor, update references, run the tests, fix the missing pieces, and mark the relevant checkboxes in the ticket" (btw, what checkboxes..?)
I press a key, type my change, and I'm done.
Wasting time waiting for tokens is also wasting time.
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.
Give me a break.
Also, based on your LinkedIn you aren't an engineer at all?
The commit should be a short summary <1 paragraph for quick context
I recognize these from different dev teams where it was agreed that a "how much AI" policy is needed, but the actual policy was very hard to settle on.
"Mr. Anderson, what good will a Claude Max plan do for you if you can't quit vim?"