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?

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.

The author had 27 years of experience but still found "babysitting git" was painful.

I couldn't remember what's the last time git got in my way. I guess such benefit from AI is probably very specific to their setup. I don't know, maybe the author had some really complex workflow or used some super advanced git features.

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.

I've recently had an interesting discussion on AI usage by students with a couple of friends who are all professors or lecturers in different fields. They report that AI makes their job harder, especially because it widens the gap between students:

Students who would have straight up failed before now produce passable essays/projects, but do not understand what they are handing in. They outsource their thinking and are overall worse than before. Students who would have excelled already pre-ai, are now even better. They use AI to learn more effectively, do broader research, and have more time to do deep research because they can outsource the grindy stuff.

This is very similar for software engineers. I'm not much faster at implementing features than before AI, despite heavily relying on agentic coding (95% of code is ai generated), but I've had significantly fewer bugs in production, less feature change requests (because w spend much more time designing/experimenting), and we are able to drive-by refactors or vulnerability fixes we would have grudgingly ignored before.

My coding skills are atrophying, but that was never interesting to me anyway. I'm getting better at systems design, cyber sec, data modelling and requirements engineering, because I have much more time to spend on it now. If LLMs disappeared tomorrow, I'd have to relearn coding, but I think it is significantly more likely that hand coding will become a specialist niche for experts.

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

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.

I have slightly different experience. Any time during deep work on codebase when I need to stop and switch lanes to study how exactly did .SECONDEXPANSION work or which of "git reset" "git checkout" flavours will do the thing I need instead of wiping all my work, or what magic sauce ingredient again prevents Dockerfile running on Podman — that is when I start understanding less the source code of my project. Because I am trying to multitask two deep study sessions. Going "computer, make this branch contain that stuff" and then proceeding with debugging kernel crash sits very well with me

Maybe it does make you a better engineer because when you look back on a commit that you were rushed on, you don't see a commit message of "Fixed it".

>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

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