[alex_x]

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.

[alex_x]

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

[yulker]

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?

[graypegg]

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.

[ozlikethewizard]

Yea you're completely correct, any computer science degree worth it's salt will cover computer architecture, networks, basic maths, etc. Do I remember every little detail about how transistors,the memory bus, or every network topology works? nah of course not, but does having a reasonable overview of how it all works under hood help inform system design when you're tackling the hard problems, performance, reliability, security,etc? Knowledge is power, so more knowledge can never be a bad thing.

[bluefirebrand]

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

[alex_x]

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

[glhaynes]

But I don't want farmers, I want meat

[ryan_n]

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.

[pradeeproark]

Sure you don’t need a farmer factory ?

[munk-a]

Well clearly not, but you might need an AbstractBeanFarmerFactoryAbstractFactory.

[dnoberon]

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.

[meerita]

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.

[ajju]

Super useful succinct crystallization!

[rootnod3]

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.

[radlad]

The best engineers hand-edit .git

Edit: But actually, one of my favorite Git explainers is https://wildlyinaccurate.com/a-hackers-guide-to-git/

[nijave]

I write all my code in assembly on paper then manually translate into opcodes

[blooalien]

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

[allarm]

That's exactly what I did when I was writing code in a paper notebook around 1995. Mainly because I didn't have a computer at home, and I wanted to program more than anything else in the world.

[meerita]

My dad worked with punched cards.

[TheSamFischer]

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?

[nomel]

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.

[TheSamFischer]

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.

[nomel]

> that you’re choosing to frame as a “best practice”,

I don't follow.

> because you do not want to put in the work.

Yes, just as nobody wants to type opcodes, or write their own http clients, or etc. It's why most of us use higher level languages. Leave the solved things solved, and work on actually interesting/new things! That doesn't mean not understanding, it just means not wasting time on the same boilerplate/code duplicated by millions of developers.

[TheSamFischer]

If you think software performance is a solved problem today, there is nothing more I have to say.

Consumer software is slower than ever. And only getting worse.

[munk-a]

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.

[cognitiveinline]

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.

[munk-a]

Who will get you out of such a tricky situation?

[cognitiveinline]

Any model, including inexpensive ones. It's not a hard problem.

[DonHopkins]

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.

[zzyzxd]

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.

[meerita]

Don’t beat me, I’m getting old. Even Git is starting to feel like unnecessary cardio.

[bloody-crow]

I have only about 17 years of experience and I consider myself a moderately advanced git user — I do interactive rebases with squashes, rewords or reordering and I do chunk manipulation per commit all the time. Or at least I used to.

Now I just type into the LLM what I want it do with git and it does it for me, much much quicker. I did not find "babysitting" git painful before, but I today I do feel like doing it manually is a just huge waste of time. A $20 LLM subscription could do this shit for me just as well or better while I spent my time doing more fun and interesting things.

[zzyzxd]

In my experience, those operations require understanding, judgement, and taste. But all of that only matters if I care about the codebase enough for it to matter.

So I don't think the disagreement is really about git. It's about how much of the thinking you're comfortable outsourcing. I do have some repos that's highly vibed up, in those repos I just let AI do whatever it want.

[bulbar]

What do you mean with "manually"? Did you type complex commands by hand? Simple commands or using an GUI is faster than explaining an AI what you want to do, no?

[bloody-crow]

I've never seen a GUI that could do anything git faster than me just doing CLI stuff in my terminal. Not even close.

> What do you mean with "manually"?

I type `git rebase -i head~15`, I select the commits I want to include, rearrange lines manually, mark the ones that I want to edit, squash, or reword. I save the buffer, exit, git starts giving me individual commits to edit/reword, so I edit chunks for manually type in the reworded messages etc

These days I just tell LLM what I want and it does git for me as a byproduct and it looks more or less the way I want, except with like 1% typing on my part and 100x times faster.

[meerita]

I doubt you can beat a skill command. It's just /my-skill-do-the-job and that's it.

[bdcravens]

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.

[arw0n]

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.

[ajju]

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

[cyanydeez]

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.

[112233]

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

[ikidd]

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

[nijave]

>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

[browski]

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

[g-b-r]

> and have been successful in hardware and software engineering for almost 30 years now.

as shown by your one day old account

[browski]

Yeah I am mostly retired in late 40s having saved as much as possible as fast as possible and have time on my hands. Am exploring social media I largely ignored while staying busy working.

Besides even if it was 3 years old account it still wouldn't tell the story correctly.

That's a measure as dumb as lines of code = productivity.

I understand; your parents made your account when you were born in 2017. Being 9 explains such shoddy reasoning. Oh wait is that when you got your first job; making an HN account some universal ritual for all new workers? Shoot too bad I missed out in 1999 when I landed my first real hardware engineer job.

You might need to logoff and go live in the real world a while. Coming off like one of those snowflakes I have heard about

[g-b-r]

Yeah, sure

> hardware and software engineering

So, it's firmware or embedded stuff what you had worked on?

And maybe you're an electronic engineer?

That could make things a bit more understandable, I would be less surprised that you don't give a fuck about the quality of source code (and probably wouldn't be able to write good code in any case).