Hacker News Reader

Comment by ppqqrr | Hacker News Reader

generic advice about how you should use the same tool and methodology (claude code, scrum) that everyone’s already using, lot of hand waving about being “senior,” This may be the most 2025 blog post ever written.

if anyone takes the art of software programming further using LLMs, it’s going to be young inexperienced people who grow up closely observing and learning the transcendental nature of LLMs and software, not hardened industry titans joyfully cracking their whip over an army of junior devs and LLMs.

View on HN

Not to be rude, but what about understanding the "transcendental nature" of LLMs allows people to build more, faster, or with better maintainability than a "hardened industry titan"?

New generations are always leapfrogging those that came before them, so I don't find it too hard to believe even under more pessimistic opinions of LLM usefulness.

They are young and inexperienced today, but won't stay that way for long. Learning new paradigms while your brain is still plastic is an advantage, and none of us can go back in time.

> Learning new paradigms while your brain is still plastic is an advantage, and none of us can go back in time.

You can absolutely learn new paradigms at any age. This idea that you can only do so as an 18-25 year old is ridiculous.

it's a lot of work and some of us are tired

But automating isn't a programming paradigm.

> They are young and inexperienced today, but won't stay that way for long.

I doubt that. For me this is the real dilemma with a generation of LLM-native developers. Does a worker in a fully automated watch factory become better at the craft of watchmaking with time?

But do those watches tell time better? or harder? or louder? Once you have the quartz crystal and have digital watches, mechanical movements became obsolete. Rolex and Patek Philippe are still around, but it's more of a curiosity than anything.

Absolutely agree. The watches do tell time better. But the factory worker does not become better at the craft of watchmaking or EE.

I think the idea that LLMs are just good at "automating" is the old curmudgeon idea that young people won't have.

I think the fundamental shift is something like having ancillary awareness of code at all but high capability to architect and drill down into product details. In other words, fresh-faced LLM programmers will come out the gate looking like really good product managers.

Similar to how C++ programmers looked down on web developers for not knowing all about malloc and pointers. Why dirty your mind with details that are abstracted away? Someone needs to know the underlying code at some point, but that may be reserved for the wizards making "core libraries" or something.

But the real advancement will be not being restricted by what used to be impossible. Why not a UI that is generated on the fly on every page load? Or why even have a webform that people have to fill out, just have the website ask users for the info it needs?

Yeah i agree with most of what you say.

> looking like really good product managers.

Exactly and that's a different field with a different skillset than developer/programmer.

And that's the purpose of technology in the first place tbh, to make the hard/tedious work easier.

we’ve been taught to think of programs as sculptures, shaped by the creator to a fixed purpose. with LLMs, the greatest advance isn’t in being able to make larger and more detailed sculptures more quickly; it’s that you can make the sculptures alive.

But who _wants_ a program to be alive? To be super clear, I love the tech behind LLMs and other transformers. But when discussing regular, run of the mill software projects that don't require AI capabilities - do you really need to have the understanding of the transcendental nature of LLMs to do that job well?

users.

Users want programs to be predictable. Especially non-technical users.

laughs in clippy

I didn't realize I had to specify that "predictably useless" doesn't count.

> generic advice about how you should use the same tool and methodology (claude code, scrum) that everyone’s already using, lot of hand waving about being “senior,” This may be the most 2025 blog post ever written.

This part tracks. It's honestly rather generic.

> if anyone takes the art of software programming further using LLMs, it’s going to be young inexperienced people who grow up closely observing and learning the transcendental nature of LLMs and software, not hardened industry titans joyfully cracking their whip over an army of junior devs and LLMs.

This, I'm not sure applies either. TBH the biggest risk I'm seeing already right now is how quickly we're starting to see juniors trying to enter the job market who don't have the faintest idea how actually code. Let alone build software (but let's be honest, that's usually been the case). What decisions to make when writing something are based on factors outside just implementing the functionality: how maintainable is this? how extensible?

Giving a junior a sycophant that's reasonably competent at spitting out something functional (not necessarily functional in the sense you need it to be but apparently working) is a recipe for disaster IMO.

There will absolutely be some who "get it". But, how does that scale?

More worryingly, something I don't see discussed enough is "review fatigue". It's far more fatiguing reviewing the output of an LLM than writing the code yourself a lot of the times. Early on in your career, this might lead to the tendency to just say "eh, looks alright enough".

> More worryingly, something I don't see discussed enough is "review fatigue". It's far more fatiguing reviewing the output of an LLM than writing the code yourself a lot of the times. Early on in your career, this might lead to the tendency to just say "eh, looks alright enough".

I am definitely worried about that. I got into a mode of doing morning code review every morning due to having a bunch of active open source repos, so over time as they grow in activity I learned to adapt my schedule, mind set, and everything around how to do the right amount of code review (when to finish the PR yourself, when to give pointers to train a new contributor, when it's not worth your time yet to say more than "tests fail", etc.). I started for years pulling every piece of code locally, running it, figuring out why someone would make a change like that, etc. and then it took like 5 years before I could actually start to do code review well just by reading a git diff. I needed to know the domain, the language, the problem space, and how people tend to work, all well enough to make that simple enough to have a mental model.

Then, I tend to see some junior programmers put up LLM stuff and I go "oh just handle the extra memory allocations and it's good to go" and they go "wait handle what where?". If you can't eyeball that in under a minute of scrolling through the code... then you shouldn't be doing code review by scrolling through it yet. But if they keep doing it like this, they will never build that skill.

That's why I think the right LLM usage is really for those who have already built that code review skill. It's not to gate the usage of LLMs, but people will never learn if they aren't strongly engaging with the code at some level.

Reply on news.ycombinator.com