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

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.

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?

There's truth in this, git is probably the least of anyone's worries when it comes to understanding your code if you're pulling in any external dependencies in your codebase. For a typical web app these days, you're hundreds of thousands of lines deep in code written by someone else on day 0.

Your statement is technically correct (and mirrors my initial feelings) but the comment below that notes that we accept many other abstractions seems more “meaningful” in the larger scheme of things.

For instance, a software engineer who also understands how to design microprocessors would indeed in my own evaluation be a “better engineer” than me (someone who does not). Yet, I wonder if they would be meaningfully more productive than a good software engineer who “just” understands how microprocessors work..

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

That's a self selecting vain perspective to conclude with.

Code is just storage medium. The hardware ultimately decides a lot that's out of our hands anyway; hardware never runs code in any structured way so getting intimate with the source structure is wasted effort. You're a worse engineer being a bottleneck in deference to bike shedding.

End of the day code is just labels on a mathematical algorithm that fits a biz edge case. Like a k:v store; sumAllCustomerBalances() is a to the a value (the function logic) that serves a business need. If the business is reliant on that behavior it won't go anywhere. And algorithms need to change as data sets change or new better algorithms are discovered.

Code is disposable. We aren't building bridges.

Whole lot of romanticizing the machine seems to have occurred since I started in this industry back in the 00s. Imo a result of people being online debating the (from my perspective) same old since slashdot was the new hotness.

In conclusion I have a different view and have been successful in hardware and software engineering for almost 30 years now.

Ymmv

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]