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.
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
How do you justify it against all the other abstractions you've accepted and no longer know how to do (or never learned in the first place). Why are the current set of manual steps the right level to be permanently aware of?
IMO, you are a better engineer if you understand how the abstraction works, at any layer of abstraction. You need to pick the point of diminishing returns for yourself, but I think it's pretty uncontroversial to say a developer that understands how a compiler works, and will dig around in a hex editor from time to time will be more knowledgeable and more likely to notice issues sooner than a developer that assumes the compiler is a magic hole in which to throw source code into and perfect executables pop out every time.
"But what about what runs the compiler! What about what runs the OS! What about the physics involved in electron transfer!" Diminishing returns I guess? No one's ever said you needed to understand everything, but understanding or at least being aware of a few layers under you seems to have been common sense forever. Taking one abstraction layer step up doesn't really change that.
I don't think that's the point. The point is that if you outsource thinking to a machine, you will lose your ability to think and reason on your own, and overtime become a worse engineer. Maybe the software ai writes will be fine, idk... But eventually, you will be an objectively worse engineer than someone that doesn't need a machine to think and write for them.
“In order to be effective working at any layer of abstraction you must have in-depth knowledge of the layer below where you’re at”.
To be the most effective at AI assisted engineering (if treated as an abstraction layer) you need to understand how code works, behaves, architectures etc. and what well performing, well built things look like. Doesn’t necessarily mean you have to know everything like you would pre-AI, but enough to be effective.
Abstractions are convenience. They’re not free, there is a cost to any work you ask the computer to do. Just staying at the surface level and never understanding what’s under the top level is why software is slow and bloated today. You’re supposed to move beyond the abstraction, understand what you need underneath and use what you really want to do the task.
No wonder we boot up entire browser engines to write simple text editors. But hey, we gotta be first to market to get that VC money, right?
Abstractions are not a convenience, they're a cognitive necessity, compressing large aspects of the problem space into easy to not think about blocks, allowing humans, with their limited working memory, to reason about larger problems. The only reason a seasoned developer can think at a high/system level is because of the abstractions/compressions they've formed in their heads.
Technology exists to make it so we don't have to think about/put time into low level things, so we can do more interesting things instead. Not thinking about banal things is the foundation of progress.
AI seems to be the give us an abstraction I've been waiting for: a method to write code at the level of libraries , with libraries working with/adapting to other libraries.
There are plenty of people who understand the stack and ship actually fast software. This might be a skill issue that you’re choosing to frame as a “best practice”, because you do not want to put in the work.
Our end users are who should benefit. You’re the pilot in the seat who doesn’t know what the throttle is and you’re telling the passenger it’s the plane’s fault it’s slow.
AI prompts aren't a new abstraction layer, it's automating the same abstraction layer, only with less understanding
It would be like saying being an engineering manager is a different abstraction layer. It's not. It's an entirely different domain, managing people and resources instead of programming machines directly
I think it's a good idea to learn how to work through those levels of abstraction, even if only academically, since it yields a lot of insight into why our current abstraction level is the way it is. I don't personally use git CLI on a day to day basis (I use a gasp GUI) but I know what a rebase is and how to recover from a variety of bad states using CLI alone during an emergency. Being aware of how commits actually works lets me know when I can rebase, squash and manipulate history in a safe manner and when such manipulations are likely to cause headaches to those around me.
The window of what steps technical people should understand in our stack of abstraction is always changing - there is no permanent window we should hold as sacred (outside of a cursory knowledge of the lowest of low levels - being passingly familiar with how machine code works is valuable to everyone) but the levels we should be aware of should exceed the levels that we casually interact with - we should at least be rather comfortable with the level one deeper than the one we often interact with.
> 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.)
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.
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.
Remembering and typing git commands does not improve the code or your understanding of it.
Reading the code yourself, human- or LLM-generated, does.
Vibe coders intentionally don't read LLM-generated code. That is the whole point, the definition of vibe coding.
But those kinds of people aren't likely to read code hand-written by their human colleagues either.
It's not whether an LLM or a human generates the code or not, it's about whether you take the time and effort to read it.
Accusing non-vibe LLM-using coders of outsourcing their thinking is only valid if they don't bother reading code, and that makes them vibe coders.
If you read the code, you're insourcing and internalizing the LLM's thinking, and you're then qualified to criticize it and ask the LLM to fix it, or fix it yourself.
I try to be a conscientious objector -- repossessing the term like reclaiming queer: conscientious about objects, prototypes, and code; conscientiously objecting to evil or sloppy work. Named at a Kaleida meetup with David Ungar's Self team and the ScriptX object-system designers; Joe Weizenbaum's line runs through Heinz Lemke's PIXIE history too.
This week, discussing light pens and PDP-7 drivers with Heinz, Alan Kay, and Lars Brinkhoff, we joked about issuing Conscientious Objector club cards for our wallets -- to show when someone asks us to write terrible, unethical, poorly designed code. Wallet-sized ethics beats /pr-merge-dev skills that merge after one day with no human review.
Not everybody here is a vibe coder. Some of us are just trying to read the diffs.
With the reliability of current LLMs, if you're outsourcing that much of your thinking, you're producing mainly slop and were never a good engineer to begin with.
If you have a quality threshold beyond "it appears to work" then agents still require a lot of hand holding and guidance
i've got 4 AI read machines; the smallest will be 72GB; the largest 128GB; they're not wunderkind, but they're all running local models.
We're definitely entering a different set of skills and we're costing on our abilities to use these systems raw, and when we start using them via AI, we're losing that raw context.
But when the gains allow us to flesh out where we've never done so, how to say no?
I never spent time on either docs or tests, but since guiding the AI requires several slices through the same logic/architecture/bug footprints, my work flow has to include looking at and maintaining all three.
If I didn't, the AI would be much worse than me doing it myself. Which means at the very least, whoever comes afte rme will have the same hardware and models and maintain the same level of support.
What is with all these people that are so interested in other people's workflow to the point of writing weirdly aggressive manifestos like this. "If you don't do it like me, you're wrong!" I would like to be the first person to state that I don't give a damn about your workflow. Do whatever you want!
But on a team, I expect people to follow some basic decorum on standards for commit messages and code reviews. That was hard to enforce and get before (GitHub encourages bad practices) but it's bloody impossible now.
> 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.
Delivery is becoming a sequence of checks, not a ritual
The same thing happens when it is time to deliver.
First, I invoke my /definition-of-done skill. It checks whether the implementation covers what was stated in the PR and in the plan. It checks tests and the other validations I care about. It tells me when something looks unusual, broken, or missing. When everything looks good, I invoke another skill, /pr-check-release. That checks the remote PR, updates labels, removes [WIP], adds [RFC], updates the description, and prepares the change for review. If one day passes and nobody on the team reviews the PR, we merge it. The agent also tracks that condition for me, so I can run /pr-merge-dev, and it takes care of the process: merge the PR, delete the remote branch, delete the local branch, and pull dev back into a fresh state. None of these steps is particularly difficult. That is exactly the point.
But then:
I still care about all of those things. Probably more than most people.
Obviously the author has irreversibly became AI-pilled and the day API costs balloon or APIs are down, what work will the author do?
I love using AI but please read the diffs and process them with your human brains and eyes. Spin up your containers manually, test the app, MANUALLY.
Talk to real users face to face.
Outsourcing the grunt work is fine, but there's a fine line between that and becoming a button-presser.
> Obviously the author has irreversibly became AI-pilled and the day API costs balloon or APIs are down, what work will the author do?
I am old enough to remember having these thoughts when documentation for things moved from books to being online. I thought looking things up in the internet was a recipe for failure, because the internet was new and unstable and changing, and what happens if you run out of your 10 hours a month of being online, or if someone in your house picks up the phone and you are disconnected?
Clearly those people were internet pilled, and the day the internet costs ballooned or was down, what would they do?
I wrote software before Stack Overflow existed, before Git existed, and before most of the tools I use today existed. I think I will survive an API outage :)
I find I keep the git add to the be one thing I keep track of (in production services, if not throw-away or non-prod visualization vibe coded things). I've never even used git add . - I git diff each file one by one, and git add them in one by one. It's needed to prevent my own errors, and it's needed to keep some model of what the AI is doing in my mind. Now, I myself don't do much commenting in line; I tended to rely on good names, good function comments, good module descriptions as comments at the top of a file; for the flow, I would log a lot and hopefully the failure/success logs made the thinking clear for what is going on and why. But I let the AI keep all its comments, till they crowd out the code at least.
Replying to a comment below (on shell scripts), I use it for shell scripts, python "get this data and slice it in these ways" and elisp, all the time. 30 seconds to get and answer instead of 30 minutes. Being able to do them in 30 minutes took a lot of skill and practice, but the pleasure of finishing that for an ad hoc thing when I really just want the data output is something I can give up.
I used AI to get a summary of this post, because in 2026, if you are not delegating this kind of reading overhead to AI, you are burning money. And, more importantly, you are ruining your life.
> 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.
These days, I am leaning heavily on Claude to deal with all the git issues that I never wanted to be bothered with. A rebase that can't just fast-forward? That's a job for Claude. A merge conflict that really shouldn't be a problem? Claude deals with it. These are things I never wanted to have to learn in the first place, and I don't feel like reserving a part of my brain to remember how to deal with these things is worthwhile. In almost all cases, there is no actual decision that needs to be made, it's purely a mechanical process.
That you know what that is makes you the right kind of person to be delegating it to an LLM; you can be trusted to use the LLM for this sort of thing because you understand what the problem is, what the right outcome should be, and how to know when it's been done correctly.
It's the person sitting behind you who doesn't understand any of those words who is going to do something dangerous at LLM-accelerated speed I'm concerned about.
I feel like if the logic in git were just a bit more sophisticated, many of these issues wouldn't even arise. Most of these are because someone foolishly (usually me) merged in the wrong direction for convenience's sake, and now I have a duplicated set of commits. It's not like Claude is doing anything very sophisticated; it's just looking at commit hashes and seeing what the unique changes are.
I 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
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.
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
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?
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 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.
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.
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.
At the end of the day LLM output is not deterministic, and the burden shifts from writing code to reviewing it. It makes sense to cover the review surface with deterministic checks/validations as much as possible - unit test, linters, static analysis tools, e2e integration test etc. one gap I noticed when it comes to such tools is that they are generally language/stack specific and don't cover things like file/directory structure/naming, file relationships/references, use of potentially harmful Unicode [0], general file/config structure, permissions, broken symlinks, files which should not be committed but are, etc. , etc. I've been building a tool - a general repo shape/structure linter, with extensible config/rules - to cover these cases in a deterministic way [1] [2].
I have my own tooling set in every project https://www.minid.net/2026/6/1/my-ai-workflow. I have couple dozens of make commands, that perform all the checks. I can do them manually after I finish coding or, I relegate these to the AI. If something is wrong, that's when I intervene. If nothing is wrong, that's because I've spent quite some time checking every single change.
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.
Eh, agents commits are always too verbose. I don't need a 3 paragraph mini novel. Design can go in a design docs folder, project info goes in the issue tracker.
The commit should be a short summary <1 paragraph for quick context
I instruct the agents to do the commit messages they way i want them written. They don't produce a book everytime, they produce what I think it's useful.
Codex is the opposite problem. If you don't aggressively prompt it, and let it write commit messages it will literally just do one incomprehensible line.
Claude will write a novel, sign it with its signature like it's a person, and fill it full of advertisement language and marketing text.
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.
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.
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.
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.
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.
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.
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.
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.
IDK, you need a few tools to unbreak a wedged box so you can get to your fancy tools even if you only want the low effort tools. Otherwise when the Cursor config file is wedged? Or the machine came up and doesnt see the network? The agent doesn't do you any good if you can't launch it.
"Mr. Anderson, what good will a Claude Max plan do for you if you can't quit vim?"
As much as I disagree with the general consensus that the article follows of "delegating non-automatable work that requires thinking and understanding to the machine because it is boring, even though the machine is unreliable", according to Pangram this does seem human-written (confidence low).
AI detectors are criticized but classifying stuff into two boxes is probably one of the stuff that is the easiest to measure the accuracy of (as long as one does not put the test set in the training set...).
(well one could see the irony of using ML to detect ML text while complaining about people not caring about understanding anymore, but that's one case where the machine is more reliable than the human)
Hmm, if you read his previous blog posts pre-ai the tone is not much different. I hate the idea that this dude may just sound like AI at this point by accident.
It somewhat boggles my mind that there are an incredible number of persistent, useless, and annoying comments on here every day accusing any and every article of being AI slop.
AI is a machine that generates content that is supposed to be statistically identical to the content that it was trained on, and it's trained on the content posted here.
The content here will look like AI generated content, and the AI generated content will look like the content here. By fucking definition.
---
Instead we get a bunch of pseudo-intellectual, hokey about how "my AI radar is perfect!" and "I can always spot it because of [insert bullshit about detecting style that's semantically the same as the pre-existing stuff]".
It's just... exhausting.
Yes - there is a lot of AI content on here. Just like there were a bunch of (and still are) under whelming marketing articles on here. Just like there's STILL a bunch of interesting and engaging articles (some of them even written by AI!).
Just vote based on the content and move on with your lives.
People out here wasting time and energy on trying to burn witches. If you want a "sure-fire" AI free experience... Go talk to a real person, in person. Otherwise...
All above comes at a cost of author slowly starting to understand less and less code in their own projects.
Then in other projects as well.
After the initial boost is over they will have to pay money just to stay afloat because they have already outsourced their thinking.
I’m not anti AI, but I’m very worried about this bragging “you are not better engineer if you do things yourself”. Yes, you are, it all comes in small details.
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
How do you justify it against all the other abstractions you've accepted and no longer know how to do (or never learned in the first place). Why are the current set of manual steps the right level to be permanently aware of?
IMO, you are a better engineer if you understand how the abstraction works, at any layer of abstraction. You need to pick the point of diminishing returns for yourself, but I think it's pretty uncontroversial to say a developer that understands how a compiler works, and will dig around in a hex editor from time to time will be more knowledgeable and more likely to notice issues sooner than a developer that assumes the compiler is a magic hole in which to throw source code into and perfect executables pop out every time.
"But what about what runs the compiler! What about what runs the OS! What about the physics involved in electron transfer!" Diminishing returns I guess? No one's ever said you needed to understand everything, but understanding or at least being aware of a few layers under you seems to have been common sense forever. Taking one abstraction layer step up doesn't really change that.
A farmer producing meat is a better farmer than me even if I hire my own farmer.
If we invent a meta-farmer profession (for those who hired a farmer) I will be great meta-farmer, but still suck as a farmer
But I don't want farmers, I want meat
I don't think that's the point. The point is that if you outsource thinking to a machine, you will lose your ability to think and reason on your own, and overtime become a worse engineer. Maybe the software ai writes will be fine, idk... But eventually, you will be an objectively worse engineer than someone that doesn't need a machine to think and write for them.
Sure you don’t need a farmer factory ?
Well clearly not, but you might need an AbstractBeanFarmerFactoryAbstractFactory.
Heard a quote I liked today.
“In order to be effective working at any layer of abstraction you must have in-depth knowledge of the layer below where you’re at”.
To be the most effective at AI assisted engineering (if treated as an abstraction layer) you need to understand how code works, behaves, architectures etc. and what well performing, well built things look like. Doesn’t necessarily mean you have to know everything like you would pre-AI, but enough to be effective.
Exactly, automation of manual tasks, doesn't mean it will wipe your knowledge or your ability to keep reviewing commits, writing comments on PRs, etc.
Because the abstractions of old still required you to read man pages and learn stuff.
And manual steps are good. At least you know what is happening.
The old Unix philosophy. Simple tools that combined become powerful.
If you use _anything_ in production, you better make sure you understand the stack.
Abstractions are convenience. They’re not free, there is a cost to any work you ask the computer to do. Just staying at the surface level and never understanding what’s under the top level is why software is slow and bloated today. You’re supposed to move beyond the abstraction, understand what you need underneath and use what you really want to do the task.
No wonder we boot up entire browser engines to write simple text editors. But hey, we gotta be first to market to get that VC money, right?
I disagree.
Abstractions are not a convenience, they're a cognitive necessity, compressing large aspects of the problem space into easy to not think about blocks, allowing humans, with their limited working memory, to reason about larger problems. The only reason a seasoned developer can think at a high/system level is because of the abstractions/compressions they've formed in their heads.
Technology exists to make it so we don't have to think about/put time into low level things, so we can do more interesting things instead. Not thinking about banal things is the foundation of progress.
AI seems to be the give us an abstraction I've been waiting for: a method to write code at the level of libraries , with libraries working with/adapting to other libraries.
There are plenty of people who understand the stack and ship actually fast software. This might be a skill issue that you’re choosing to frame as a “best practice”, because you do not want to put in the work.
Our end users are who should benefit. You’re the pilot in the seat who doesn’t know what the throttle is and you’re telling the passenger it’s the plane’s fault it’s slow.
AI prompts aren't a new abstraction layer, it's automating the same abstraction layer, only with less understanding
It would be like saying being an engineering manager is a different abstraction layer. It's not. It's an entirely different domain, managing people and resources instead of programming machines directly
I think it's a good idea to learn how to work through those levels of abstraction, even if only academically, since it yields a lot of insight into why our current abstraction level is the way it is. I don't personally use git CLI on a day to day basis (I use a gasp GUI) but I know what a rebase is and how to recover from a variety of bad states using CLI alone during an emergency. Being aware of how commits actually works lets me know when I can rebase, squash and manipulate history in a safe manner and when such manipulations are likely to cause headaches to those around me.
The window of what steps technical people should understand in our stack of abstraction is always changing - there is no permanent window we should hold as sacred (outside of a cursory knowledge of the lowest of low levels - being passingly familiar with how machine code works is valuable to everyone) but the levels we should be aware of should exceed the levels that we casually interact with - we should at least be rather comfortable with the level one deeper than the one we often interact with.
Manual knowledge of git to get out of tricky situations will be as passe as using log book for multiplication. It's just not required anymore.
[flagged]
The best engineers hand-edit .git
I write all my code in assembly on paper then manually translate into opcodes
My dad worked with punched cards.
> 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.)
[flagged]
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.
Ymmv
> and have been successful in hardware and software engineering for almost 30 years now.
as shown by your one day old account
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.
Remembering and typing git commands does not improve the code or your understanding of it.
Reading the code yourself, human- or LLM-generated, does.
Vibe coders intentionally don't read LLM-generated code. That is the whole point, the definition of vibe coding.
But those kinds of people aren't likely to read code hand-written by their human colleagues either.
It's not whether an LLM or a human generates the code or not, it's about whether you take the time and effort to read it.
Accusing non-vibe LLM-using coders of outsourcing their thinking is only valid if they don't bother reading code, and that makes them vibe coders.
If you read the code, you're insourcing and internalizing the LLM's thinking, and you're then qualified to criticize it and ask the LLM to fix it, or fix it yourself.
I try to be a conscientious objector -- repossessing the term like reclaiming queer: conscientious about objects, prototypes, and code; conscientiously objecting to evil or sloppy work. Named at a Kaleida meetup with David Ungar's Self team and the ScriptX object-system designers; Joe Weizenbaum's line runs through Heinz Lemke's PIXIE history too.
This week, discussing light pens and PDP-7 drivers with Heinz, Alan Kay, and Lars Brinkhoff, we joked about issuing Conscientious Objector club cards for our wallets -- to show when someone asks us to write terrible, unethical, poorly designed code. Wallet-sized ethics beats /pr-merge-dev skills that merge after one day with no human review.
Not everybody here is a vibe coder. Some of us are just trying to read the diffs.
>already outsourced their thinking
With the reliability of current LLMs, if you're outsourcing that much of your thinking, you're producing mainly slop and were never a good engineer to begin with.
If you have a quality threshold beyond "it appears to work" then agents still require a lot of hand holding and guidance
i've got 4 AI read machines; the smallest will be 72GB; the largest 128GB; they're not wunderkind, but they're all running local models.
We're definitely entering a different set of skills and we're costing on our abilities to use these systems raw, and when we start using them via AI, we're losing that raw context.
But when the gains allow us to flesh out where we've never done so, how to say no?
I never spent time on either docs or tests, but since guiding the AI requires several slices through the same logic/architecture/bug footprints, my work flow has to include looking at and maintaining all three.
If I didn't, the AI would be much worse than me doing it myself. Which means at the very least, whoever comes afte rme will have the same hardware and models and maintain the same level of support.
[flagged]
[dead]
What is with all these people that are so interested in other people's workflow to the point of writing weirdly aggressive manifestos like this. "If you don't do it like me, you're wrong!" I would like to be the first person to state that I don't give a damn about your workflow. Do whatever you want!
I imagine most people don't give a damn about others' workflows. But they're not posting about it, because they don't give a damn.
screaming for attention really.
Sure, do whatever you want on your own projects.
But on a team, I expect people to follow some basic decorum on standards for commit messages and code reviews. That was hard to enforce and get before (GitHub encourages bad practices) but it's bloody impossible now.
You’re mistaking how with what. We’re talking about „how” here
> 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.
So on one hand it states:
Delivery is becoming a sequence of checks, not a ritual The same thing happens when it is time to deliver.
First, I invoke my /definition-of-done skill. It checks whether the implementation covers what was stated in the PR and in the plan. It checks tests and the other validations I care about. It tells me when something looks unusual, broken, or missing. When everything looks good, I invoke another skill, /pr-check-release. That checks the remote PR, updates labels, removes [WIP], adds [RFC], updates the description, and prepares the change for review. If one day passes and nobody on the team reviews the PR, we merge it. The agent also tracks that condition for me, so I can run /pr-merge-dev, and it takes care of the process: merge the PR, delete the remote branch, delete the local branch, and pull dev back into a fresh state. None of these steps is particularly difficult. That is exactly the point.
But then:
I still care about all of those things. Probably more than most people.
Obviously the author has irreversibly became AI-pilled and the day API costs balloon or APIs are down, what work will the author do?
I love using AI but please read the diffs and process them with your human brains and eyes. Spin up your containers manually, test the app, MANUALLY. Talk to real users face to face.
Outsourcing the grunt work is fine, but there's a fine line between that and becoming a button-presser.
> Obviously the author has irreversibly became AI-pilled and the day API costs balloon or APIs are down, what work will the author do?
I am old enough to remember having these thoughts when documentation for things moved from books to being online. I thought looking things up in the internet was a recipe for failure, because the internet was new and unstable and changing, and what happens if you run out of your 10 hours a month of being online, or if someone in your house picks up the phone and you are disconnected?
Clearly those people were internet pilled, and the day the internet costs ballooned or was down, what would they do?
I wrote software before Stack Overflow existed, before Git existed, and before most of the tools I use today existed. I think I will survive an API outage :)
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 don't get these kinds of posts. Zero how-to, zero share about the tradeoffs the author took.
It's just a random internet dude telling us how he thinks other people should feel about their work.
I 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.
> 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.
These days, I am leaning heavily on Claude to deal with all the git issues that I never wanted to be bothered with. A rebase that can't just fast-forward? That's a job for Claude. A merge conflict that really shouldn't be a problem? Claude deals with it. These are things I never wanted to have to learn in the first place, and I don't feel like reserving a part of my brain to remember how to deal with these things is worthwhile. In almost all cases, there is no actual decision that needs to be made, it's purely a mechanical process.
A rebase that can't just fast-forward?
That you know what that is makes you the right kind of person to be delegating it to an LLM; you can be trusted to use the LLM for this sort of thing because you understand what the problem is, what the right outcome should be, and how to know when it's been done correctly.
It's the person sitting behind you who doesn't understand any of those words who is going to do something dangerous at LLM-accelerated speed I'm concerned about.
I feel like if the logic in git were just a bit more sophisticated, many of these issues wouldn't even arise. Most of these are because someone foolishly (usually me) merged in the wrong direction for convenience's sake, and now I have a duplicated set of commits. It's not like Claude is doing anything very sophisticated; it's just looking at commit hashes and seeing what the unique changes are.
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
>Ironically, the audience that values all that structure the most is now LLMs.
LLMs are not people and they don't have values.
“The consumer that maximizes utility of that structure is now an LLM”
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.
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
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?
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.
I still tell the AI exactly what to do and you need to understand what reset, rebase, pull, and checkout actually do. Otherwise you end up with a mess.
Yes but you do not have to invoke them directly yourself anymore
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.
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
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.
Maybe I'm alone in this, but I've always found the git GUIs more confusing than just typing out the commands. They never seem to map well to how I work.
Never had a git GUI that worked for me either
At the end of the day LLM output is not deterministic, and the burden shifts from writing code to reviewing it. It makes sense to cover the review surface with deterministic checks/validations as much as possible - unit test, linters, static analysis tools, e2e integration test etc. one gap I noticed when it comes to such tools is that they are generally language/stack specific and don't cover things like file/directory structure/naming, file relationships/references, use of potentially harmful Unicode [0], general file/config structure, permissions, broken symlinks, files which should not be committed but are, etc. , etc. I've been building a tool - a general repo shape/structure linter, with extensible config/rules - to cover these cases in a deterministic way [1] [2].
[0] https://snyk.io/articles/defending-against-glassworm/
[1] https://github.com/asamarts/alint
[2] https://alint.org/
I have my own tooling set in every project https://www.minid.net/2026/6/1/my-ai-workflow. I have couple dozens of make commands, that perform all the checks. I can do them manually after I finish coding or, I relegate these to the AI. If something is wrong, that's when I intervene. If nothing is wrong, that's because I've spent quite some time checking every single change.
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.
[dead]
Eh, agents commits are always too verbose. I don't need a 3 paragraph mini novel. Design can go in a design docs folder, project info goes in the issue tracker.
The commit should be a short summary <1 paragraph for quick context
I instruct the agents to do the commit messages they way i want them written. They don't produce a book everytime, they produce what I think it's useful.
Just put your last sentence in your AGENTS.md then
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.
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
"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?
whats the point of a commit message if it can be inferred by an agent from the diff?
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.
Commit messages now do double duty: log of the changes, but also signing off that you've read and understand the code, are taking responsibility for it under your own name.
The second part is an emerging convention but it's fairly common from what I've seen. IDK maybe no one will be reading or writing code in 18 months but if they are we'll need to separate these two things.
Secondarily but probably more importantly: it's real easy to read something and say "yep I understand that." It's a lot harder to fool yourself when you have to actually write down, with your own brain, what that thing you read does. If you're not doing this you must have incredible discipline elsewhere to make up for it.
[dead]
Similar arguments have been made about Git UIs and automated tools, and of course most people who depend on such things also depend on others to bail them out in difficult situations with git.
So it just becomes a question about whether or not it's part of your core value proposition. For many developers, the answer is obviously no. And then outsourcing those things to automation, including LLMs, seems fine.
But if you can outsource your job, so can everyone else. If the LLM (or ide or any other tool) just needs someone to vaguely press the "next" button to do your job, well, your boss and everyone else can press that button too.
Outsource carefully. Know the value you provide.
I constantly hear other engineers talk about how knowing the cli, git, Linux, whatever is useless. But then I’m the one that gets called when shit breaks, so it must not be that useless. If knowing how shit works at a low level is so useless they why do I need to bail colleagues out so much.
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.
Ew at the bit about letting AI write your commit messages. Don’t bother - if you didn’t take the time to write it why should anyone take the time to read it. I’ll just ask my AI to extract the intent from the actual code if I need it.
makes sense? commit messages is pre ai era, we need a new git, and people are already working on it
> 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.
You are outsourcing your life to AI? Good for you, but don't be so pretentious, please.
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.
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.
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.
Our commit messages have become useless since we adopted a shared agent skill for making commits.
The LLM tends to fill the messages with irrelevant details while still failing to mention what the change actually does.
Exactly.
I was team / tech lead on the last contract gig I had, and I had a policy in writing that people should write their own commit messages and PR descriptions. For this reason and others.
... And follow conventional commit format. Linear commits. Rebasing / fast-forward, no merge commits. Etc. etc.
Nobody paid any attention. The git history was next to useless. Bisecting would be completely impossible. People were mostly just pumping and dumping. I could have drawn a hard red line but the founder was the worst for it.
We're doomed.
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)
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?"
If you can't be bothered to write it, why should I bother reading it?
As much as I disagree with the general consensus that the article follows of "delegating non-automatable work that requires thinking and understanding to the machine because it is boring, even though the machine is unreliable", according to Pangram this does seem human-written (confidence low).
AI detectors are criticized but classifying stuff into two boxes is probably one of the stuff that is the easiest to measure the accuracy of (as long as one does not put the test set in the training set...).
(well one could see the irony of using ML to detect ML text while complaining about people not caring about understanding anymore, but that's one case where the machine is more reliable than the human)
Hmm, if you read his previous blog posts pre-ai the tone is not much different. I hate the idea that this dude may just sound like AI at this point by accident.
It somewhat boggles my mind that there are an incredible number of persistent, useless, and annoying comments on here every day accusing any and every article of being AI slop.
AI is a machine that generates content that is supposed to be statistically identical to the content that it was trained on, and it's trained on the content posted here.
The content here will look like AI generated content, and the AI generated content will look like the content here. By fucking definition.
---
Instead we get a bunch of pseudo-intellectual, hokey about how "my AI radar is perfect!" and "I can always spot it because of [insert bullshit about detecting style that's semantically the same as the pre-existing stuff]".
It's just... exhausting.
Yes - there is a lot of AI content on here. Just like there were a bunch of (and still are) under whelming marketing articles on here. Just like there's STILL a bunch of interesting and engaging articles (some of them even written by AI!).
Just vote based on the content and move on with your lives.
People out here wasting time and energy on trying to burn witches. If you want a "sure-fire" AI free experience... Go talk to a real person, in person. Otherwise...
"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"
[dead]
[flagged]
I see a flamebait title, I click flag. Simple as.