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

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

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

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

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

Code is disposable. We aren't building bridges.

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

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

Ymmv

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

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.

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.

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?

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.

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.

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.

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.

The LLM tends to fill the messages with irrelevant details while still failing to mention what the change actually does.

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)