Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Grief and the AI split

blog.lmorchard.com

Post reply on HN
Print view View original

271–280 of 404 posts

Re: Grief and the AI split

#271

Post by sweetheart »

eloisius wrote: post #258
khafra wrote: post #241

Earlier quoted context omitted.

Whether the labor theory of value is right or wrong, the "real split" you describe will soon no longer exist. Capital owners will live on the labor of their capital. Non-capital-owners will live on the largesse of capital, or will not live at all. Unless we muster the political will to stop AI development, internationally, until we can be certain of our ability to durably imbue it with the intrinsic desire to keep hu…

I, for one, am looking forward to me and a band of my closest friends and family raiding heavily fortified data centers guarded by Boston Dynamics robot dogs to steal clean drinking water for our underground village. We might even hit a caravan of autonomous trucks carrying cricket protein powder in the same night.

can i come

Re: Grief and the AI split

#272

Post by tcgv »

That's an interesting take. I'm likely on the same side of the split as you, since I'm very much motivated by the new possibilities agentic coding tools open when used responsibly.

Back in February, I also wrote a piece on the recurring mourning/sense of grief we are seeing for 'craftsmanship' coding:

- https://thomasvilhena.com/2026/02/craftsmanship-coding-five-...

Re: Grief and the AI split

#273

Post by tyleo »

I think there is a split but I don’t think it’s between people who love hand-crafting things vs not.

I love hand crafting things, yet I’m waking up like a kid on Christmas every day, running to my computer to use Claude code. For my critical apps I review every line. For 1-off things, I’ve had Claude build single-serving applications.

If I had to guess the split is more between folks who have curiosity about the new technology and folks who fear things changing. With a decent center on that Venn Diagram of folks who feel both.

Re: Grief and the AI split

#274

Post by negroesrnegro »

mrob wrote: post #254

The optimal amount of generative AI in the world is zero. There are three possible scenarios, all of them bad: 1. Weaker than expected AI. Great Depression 2.0. Widespread poverty and suffering as the enormous investments already made fail to pay off. 2. AI works as expected. Dystopia. A few trillionaires gain absolute control of the entire world, and everyone else is enslaved or killed. 3. Stronger than excepted AI.…

you may notice tbat the same people benefit from 1 and 2 and 3 is just a fantasy sold to the plebs to detract attention from 1 and 2

what a councidence

Re: Grief and the AI split

#275

Post by skydhash »

simianwords wrote: post #257
FuckButtons wrote: post #230

Earlier quoted context omitted.

Sounds like you’ve never had a prototype become foundational infrastructure before, or dealt with someone else’s.

you can always change it later. this is exactly the dogmatism i'm speaking about - you need to prioritise pushing things. the clean up can come later. ironically it is your camp that advices to not use microservices but start with monolith. that's what i'm suggesting here.

> you can always change it later. this is exactly the dogmatism i'm speaking about - you need to prioritise pushing things. the clean up can come later.

Everyone that says this has not been the one that had to fix the code later. They have already moved to the next jobs (or have been fired). Engineers do know the tradeoff between quality and speed, and can do hack if that’s what needed to get the project to the finish line. But good ones will note down the hack and resolve it later. Bad ones will pat themselves in the back and add more hacks on top of that.

Re: Grief and the AI split

#276

Post by daveguy »

khafra wrote: post #264
forgetfreeman wrote: post #247

Earlier quoted context omitted.

"Non-capital-owners will live on the largesse of capital, or will not live at all." That's been tried several times now and has a tendency to end very badly for capital. You'd think folks with even a grade school level of historical literacy would know better than to stick a fork in that outlet.

It's never been tried before. Capital always required human labor, to be productive. Capital has never closed in on the ability to operate, maintain, defend, and expand itself without human assistance, as it is closing in on that ability now.

It's really not. The capital owners just think it is.

Re: Grief and the AI split

#277

Post by skydhash »

simianwords wrote: post #255
wiseowise wrote: post #244

Earlier quoted context omitted.

Where? > That does not mean you are correct. This mindset is useful only in serious reusable libraries and open source tools. Most enterprise code involves lots of exploring and fast iteration. Code quality doesn’t matter that much. No one else is going to see it. Here? Most of those that I’ve listed IS boring enterprise code. Unless we’re taking medical/military grade.

fair, you have presented specific niche where the ~quality~ correctness is important in enterprise - not just libraries. but most people aren't writing code in those places. its usually CRUD, advertisement, startups, ecommerce. also there are two things going on here: - quality of code - correctness of code in serious reusable libraries and opensource tools, quality of code matters. the interfaces, redundancy etc. bu…

Maybe you’re too entrenched in the web section of software development. Be aware that there’s a lot of desktop and system software out there.

Even in web software, you can write good code without compromising in delivery speed. That just requires you to be good at what you’re doing. But the web is more forgiving of mistakes and a lot of frameworks have no taste at all.

Re: Grief and the AI split

#278

Post by oytis »

I think we should already get past pretending it's about people who just like typing words on their stupid mechanical keyboards. The real split is whether you like understanding systems and inventing new things or whether you are OK to delegate this part to someone else and are just happy to take credit for their success. With a small note that when someone else is a human, the credit can be justified if you mentored them or created conditions for their success and growth.

Re: Grief and the AI split

#279

Post by thedevilslawyer »

forgetfreeman wrote: post #252
simonw wrote: post #2

This sounds right to me: > Before AI, both camps were doing the same thing every day. Writing code by hand. Using the same editors, the same languages, the same pull request workflows. The craft-lovers and the make-it-go people sat next to each other, shipped the same products, looked indistinguishable. The motivation behind the work was invisible because the process was identical. Helps explain why some people are d…

"The craft-lovers and the make-it-go people sat next to each other, shipped the same products, looked indistinguishable." Definitely not. Based on my observations from a career as an open source and agency developer it was obvious at a glance which of these camps any given developer lived in by their code quality. With few exceptions make-it-go types tended to produce brittle, hacky, short-sighted work that had a ten…

Generalize much? How would you feel if code-as-craft people were called out to be anti-social nerds who spent times on umpteenth rewrite and refactor, didn't care what impact that had on the actual user they were building for?

Re: Grief and the AI split

#280

Post by discreteevent »

simianwords wrote: post #257
FuckButtons wrote: post #230

Earlier quoted context omitted.

Sounds like you’ve never had a prototype become foundational infrastructure before, or dealt with someone else’s.

you can always change it later. this is exactly the dogmatism i'm speaking about - you need to prioritise pushing things. the clean up can come later. ironically it is your camp that advices to not use microservices but start with monolith. that's what i'm suggesting here.

> You can always change it later.

People seem to think that technical debt doesn't need to be paid back for ages. In my experience bad code starts to cost more than it saved after about three months. So if you have to get a demo ready right now that will save the company then hack it in. But that's not the case for most technical debt. In most cases the management just want the perception of speed so they pile debt upon debt. Then they can't figure out why delivery gets slower and slower.

> ironically it is your camp that advices to not use microservices but start with monolith. that's what i'm suggesting here.

I agree with this. But there's a difference between over-engineering and hacking in bad quality code. So to be clear, I am talking about the latter.

Post reply on HN