6 ms·

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

45 points by meerita 3mo ago

cratermoon 3mo ago
If you can't be bothered to write it, why should I bother reading it?
- PxldLtd 3mo ago
  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.
  - poszlem 3mo ago
    "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"
  - horsawlarway 3mo ago
    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...
    - DonHopkins 3mo ago
      [dead]
  - DonHopkins 3mo ago
    [dead]
  - cratermoon 3mo ago
    Everyone here is taking my comment as saying the blog post was written by AI, and that’s wrong. The author says he uses AI to write commit messages and code comments. Those are what I’m saying are not worth my time or effort to read.
- Krssst 3mo ago
  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)
cmrdporcupine 3mo ago
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.
- bunderbunder 3mo ago
  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.
  - cmrdporcupine 3mo ago
    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.
  - duskdozer 3mo ago
    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.
- deleted 3mo ago
  [deleted]
fdghbcxfiyfdr 3mo ago
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
mpalmer 3mo ago
I don't disagree with any of the points in the post. They're even framed better than the average "I love using AI because X" post. Unfortunately, you won't become a better writer letting AI do it for you.
vorpalhex 3mo ago
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.
- yoyohello13 3mo ago
  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.
giraffe_lady 3mo ago
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.
- deleted 3mo ago
  [deleted]
- DonHopkins 3mo ago
  [dead]
alex_x 3mo ago
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.
- yulker 3mo ago
  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?
  - radlad 3mo ago
    The best engineers hand-edit .git Edit: But actually, one of my favorite Git explainers is https://wildlyinaccurate.com/a-hackers-guide-to-git/ https://wildlyinaccurate.com/a-hackers-guide-to-git/
    - nijave 3mo ago
      I write all my code in assembly on paper then manually translate into opcodes
      - blooalien 3mo ago
        > 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.)
      - meerita 3mo ago
        My dad worked with punched cards.
lordkrandel 3mo ago
You are outsourcing your life to AI? Good for you, but don't be so pretentious, please.
DerrickViolet 3mo ago
[dead]
loloquwowndueo 3mo ago
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.
- peheje 3mo ago
  makes sense? commit messages is pre ai era, we need a new git, and people are already working on it
thunderfork 3mo ago
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.
- rspeele 3mo ago
  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.
  - thunderfork 3mo ago
    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.
- meerita 3mo ago
deleted 3mo ago
[deleted]
tangenter 3mo ago
I see a flamebait title, I click flag. Simple as.
nisegami 3mo ago
Just from the title I didn't even realize this would be a post about AI. I thought it was going to be about using Git in your IDE or other git UI tooling.
joeyhage 3mo ago
> In 2026, if you are not delegating this kind of engineering overhead to AI, you are burning money. And, more importantly, you are burning your life. AI use can be a divisive topic among developers but I generally believe it is a useful tool. That said, please don’t broadly advise people on what’s best for their life. It will only make people push away from AI more.
lanstin 3mo ago
I find I keep the git add to the be one thing I keep track of (in production services, if not throw-away or non-prod visualization vibe coded things). I've never even used git add . - I git diff each file one by one, and git add them in one by one. It's needed to prevent my own errors, and it's needed to keep some model of what the AI is doing in my mind. Now, I myself don't do much commenting in line; I tended to rely on good names, good function comments, good module descriptions as comments at the top of a file; for the flow, I would log a lot and hopefully the failure/success logs made the thinking clear for what is going on and why. But I let the AI keep all its comments, till they crowd out the code at least. Replying to a comment below (on shell scripts), I use it for shell scripts, python "get this data and slice it in these ways" and elisp, all the time. 30 seconds to get and answer instead of 30 minutes. Being able to do them in 30 minutes took a lot of skill and practice, but the pleasure of finishing that for an ad hoc thing when I really just want the data output is something I can give up.
hparadiz 3mo ago
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.
- MattDamonSpace 3mo ago
  Yes but you do not have to invoke them directly yourself anymore
  - hparadiz 3mo ago
    Absolutely and I love it to be completely honest
georgemcbay 3mo ago
I don't keep LLMs sandboxed away from executing git commands because I think it makes me a better engineer, I do it because as useful as LLMs can be for programming I still don't trust them to not occasionally attempt to burn my house down.
brunooliv 3mo ago
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.
- deleted 3mo ago
  [deleted]
- cortesoft 3mo ago
  > 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?
- meerita 3mo ago
  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 :)
vile_wretch 3mo ago
"In 2026, if you are not delegating this kind of engineering overhead to AI, you are burning money. And, more importantly, you are burning your life." Give me a break. Also, based on your LinkedIn you aren't an engineer at all?
nijave 3mo ago
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
- g-b-r 3mo ago
  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
  - nijave 3mo ago
    I suppose that's fair. The assumption here is things get linked back to the issue tracker and it's not very interesting boring business apps. Anything technical tends to be a link back to discussion on someone else's issue tracker
- mr_mitm 3mo ago
  Just put your last sentence in your AGENTS.md then
  - nijave 3mo ago
    There's too much nuance--it would take a dedicated skill
- cmrdporcupine 3mo ago
  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.
- meerita 3mo ago
  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.
h2aichat 3mo ago
[flagged]
overgard 3mo ago
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!
- cmrdporcupine 3mo ago
  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.
  - Otek 3mo ago
    You’re mistaking how with what. We’re talking about „how” here
  - bloody-crow 3mo ago
    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
    - duskdozer 3mo ago
      Easier to have them follow a format, sure, but definitely not easier to have them provide useful information.
- totallyhuman 3mo ago
  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.
- nepurcel 3mo ago
  screaming for attention really.
reinitctxoffset 3mo ago
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?"
CyLith 3mo ago
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.
- EliRivers 3mo ago
  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.
  - CyLith 3mo ago
    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.
27183 3mo ago
> 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.
- bloody-crow 3mo ago
  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.
  - 27183 3mo ago
    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?
    - bloody-crow 3mo ago
      "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.
      - 27183 3mo ago
        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.
operatingthetan 3mo ago
>Ironically, the audience that values all that structure the most is now LLMs. LLMs are not people and they don't have values.
- MattDamonSpace 3mo ago
  “The consumer that maximizes utility of that structure is now an LLM”
aleqs 3mo ago
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/ https://snyk.io/articles/defending-against-glassworm/ [1] https://github.com/asamarts/alint https://github.com/asamarts/alint [2] https://alint.org/ https://alint.org/
- meerita 3mo ago
  I have my own tooling set in every project https://www.minid.net/2026/6/1/my-ai-workflow 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.
  - aleqs 3mo ago
    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.
JeremyHerrman 3mo ago
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
- meerita 3mo ago
  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.
  - blooalien 3mo ago
    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. ;)
kklisura 3mo ago
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.
ilaksh 3mo ago
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.
andai 3mo ago
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.
khasan222 3mo ago
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
davidd_1004 3mo ago
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.
- MattDamonSpace 3mo ago
  Never had a git GUI that worked for me either
- meerita 3mo ago
  You are not alone. I got huge amount of frustration with the diffs tools in git GUIs over the years I always ended up on the command line.
pyrale 3mo ago
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.
- thiht 3mo ago
  Ain’t it what the internet is for?
nimih 3mo ago
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.
aleda145 3mo ago
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.
anuramat 3mo ago
whats the point of a commit message if it can be inferred by an agent from the diff?
e28eta 3mo ago
> 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.
- meerita 3mo ago
  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.
nepurcel 3mo ago
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)
blooalien 3mo ago
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 3mo ago
  [flagged]
- blooalien 3mo ago
  > @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". ;)
bulbar 3mo ago
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.
daledavies 3mo ago
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.
wseqyrku 3mo ago
No hands, I just roll my eyes way up behind my eyelids and instruct the machine teletypepathically.
- pan69 3mo ago
  I have switched to vocalised morse code. My colleagues love me.
hbogert 3mo ago
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
beej71 3mo ago
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.
Garlef 3mo ago
Letting the agent rebase stacked PRs (and create the respective subtasks in jira to begin with) is an incredible time saver

45 points by meerita 3mo ago

cratermoon 3mo ago

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

PxldLtd 3mo ago
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.
- poszlem 3mo ago
  "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"
- horsawlarway 3mo ago
  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...
  - DonHopkins 3mo ago
    [dead]
- DonHopkins 3mo ago
  [dead]
- cratermoon 3mo ago
  Everyone here is taking my comment as saying the blog post was written by AI, and that’s wrong. The author says he uses AI to write commit messages and code comments. Those are what I’m saying are not worth my time or effort to read.
Krssst 3mo ago
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)

cmrdporcupine 3mo ago

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.

bunderbunder 3mo ago
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.
- cmrdporcupine 3mo ago
  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.
- duskdozer 3mo ago
  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.
deleted 3mo ago
[deleted]

fdghbcxfiyfdr 3mo ago

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

mpalmer 3mo ago

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

vorpalhex 3mo ago

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.

yoyohello13 3mo ago
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.

giraffe_lady 3mo ago

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.

deleted 3mo ago
[deleted]
DonHopkins 3mo ago
[dead]

alex_x 3mo ago

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.

yulker 3mo ago
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?
- radlad 3mo ago
  The best engineers hand-edit .git Edit: But actually, one of my favorite Git explainers is https://wildlyinaccurate.com/a-hackers-guide-to-git/ https://wildlyinaccurate.com/a-hackers-guide-to-git/
  - nijave 3mo ago
    I write all my code in assembly on paper then manually translate into opcodes
    - blooalien 3mo ago
      > 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.)
    - meerita 3mo ago
      My dad worked with punched cards.

lordkrandel 3mo ago

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

DerrickViolet 3mo ago

[dead]

loloquwowndueo 3mo ago

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.

peheje 3mo ago
makes sense? commit messages is pre ai era, we need a new git, and people are already working on it

thunderfork 3mo ago

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.

rspeele 3mo ago
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.
- thunderfork 3mo ago
  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.
meerita 3mo ago

deleted 3mo ago

[deleted]

tangenter 3mo ago

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

nisegami 3mo ago

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

joeyhage 3mo ago

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

lanstin 3mo ago

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

hparadiz 3mo ago

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.

MattDamonSpace 3mo ago
Yes but you do not have to invoke them directly yourself anymore
- hparadiz 3mo ago
  Absolutely and I love it to be completely honest

georgemcbay 3mo ago

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

brunooliv 3mo ago

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.

deleted 3mo ago
[deleted]
cortesoft 3mo ago
> 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?
meerita 3mo ago
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 :)

vile_wretch 3mo ago

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

nijave 3mo ago

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

g-b-r 3mo ago
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
- nijave 3mo ago
  I suppose that's fair. The assumption here is things get linked back to the issue tracker and it's not very interesting boring business apps. Anything technical tends to be a link back to discussion on someone else's issue tracker
mr_mitm 3mo ago
Just put your last sentence in your AGENTS.md then
- nijave 3mo ago
  There's too much nuance--it would take a dedicated skill
cmrdporcupine 3mo ago
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.
meerita 3mo ago
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.

h2aichat 3mo ago

[flagged]

overgard 3mo ago

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!

cmrdporcupine 3mo ago
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.
- Otek 3mo ago
  You’re mistaking how with what. We’re talking about „how” here
- bloody-crow 3mo ago
  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
  - duskdozer 3mo ago
    Easier to have them follow a format, sure, but definitely not easier to have them provide useful information.
totallyhuman 3mo ago
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.
nepurcel 3mo ago
screaming for attention really.

reinitctxoffset 3mo ago

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?"

CyLith 3mo ago

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.

EliRivers 3mo ago
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.
- CyLith 3mo ago
  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.

27183 3mo ago

> 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.

bloody-crow 3mo ago
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.
- 27183 3mo ago
  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?
  - bloody-crow 3mo ago
    "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.
    - 27183 3mo ago
      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.

operatingthetan 3mo ago

>Ironically, the audience that values all that structure the most is now LLMs. LLMs are not people and they don't have values.

MattDamonSpace 3mo ago
“The consumer that maximizes utility of that structure is now an LLM”

aleqs 3mo ago

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/ https://snyk.io/articles/defending-against-glassworm/ [1] https://github.com/asamarts/alint https://github.com/asamarts/alint [2] https://alint.org/ https://alint.org/

meerita 3mo ago
I have my own tooling set in every project https://www.minid.net/2026/6/1/my-ai-workflow 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.
- aleqs 3mo ago
  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.

JeremyHerrman 3mo ago

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

meerita 3mo ago
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.
- blooalien 3mo ago
  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. ;)

kklisura 3mo ago

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.

ilaksh 3mo ago

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.

andai 3mo ago

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.

khasan222 3mo ago

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

davidd_1004 3mo ago

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.

MattDamonSpace 3mo ago
Never had a git GUI that worked for me either
meerita 3mo ago
You are not alone. I got huge amount of frustration with the diffs tools in git GUIs over the years I always ended up on the command line.

pyrale 3mo ago

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.

thiht 3mo ago
Ain’t it what the internet is for?

nimih 3mo ago

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.

aleda145 3mo ago

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.

anuramat 3mo ago

whats the point of a commit message if it can be inferred by an agent from the diff?

e28eta 3mo ago

> 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.

meerita 3mo ago
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.

nepurcel 3mo ago

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)

blooalien 3mo ago

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 3mo ago
[flagged]
blooalien 3mo ago
> @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". ;)

bulbar 3mo ago

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.

daledavies 3mo ago

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.

wseqyrku 3mo ago

No hands, I just roll my eyes way up behind my eyelids and instruct the machine teletypepathically.

pan69 3mo ago
I have switched to vocalised morse code. My colleagues love me.

hbogert 3mo ago

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

beej71 3mo ago

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.

Garlef 3mo ago

Letting the agent rebase stacked PRs (and create the respective subtasks in jira to begin with) is an incredible time saver