Live data from Hacker News

Grief and the AI split

blog.lmorchard.com

71–80 of 404 posts

Re: Grief and the AI split

#71
There's no divide.

Brilliant engineers, among the best software craftsmen out there are using AI daily and speeding up their processes.

The author of Redis, antirez, stated a month ago he spent 2 weeks on Redis tinkering with LLMs...and it was just design phase, not a single line of code was authored. The ability to interrogate LLMs and have them criticize his ideas and edge cases sped up his process by month.

He also used LLMs successfully to find multiple issues in Redis that would've took him longer to do without.

I myself spend with AI way more time tinkering and gathering information than authoring code.

Am I a craft lover or a result chaser?

But sure, let's keep everything in the divide conservative vs liberal, black and white, craftsman vs vibe coder...give me a break..

Re: Grief and the AI split

#72

Lots of mentions of the term mourning... As they say in my country, don't sell the skin until you kill the bear. All I'm seeing around me is people dropping best practices in a FOMO driven push for speed: let's stop reviews, let's drive 5 agents in parallel, let's not even look at the code! This is going to blow up. Only after we pick up the remains we'll find a more sustainable approach for AI usage. I suspect that…

> If we end up in a place where the craft truly is dead, then congratulations, your value probably just dropped to zero I think, then that the value of all knowledge work will have dropped to zero. Software engineering is, to my mind, “intelligence complete.” If you can do it with knowledge work, you can have software do it.

That’s not the point of nor the reason for knowledge work.

The fundamental mechanism of knowledge work is people. They haven’t changed at all. And what they need to understand and learn hasn’t changed. All the agents in the world and all of the methane guzzling data centres can’t tell you what to write in the specification nor if what the computer has generated faithfully implements that specification.

Re: Grief and the AI split

#73

The important thing to remember is that for a large number of people (in the US), "work" is a place where they do things that they hate for eight hours a day, for people they hate (surveys routinely show between 40% and 60% of people are "satisfied" with their jobs). Those of us who are in the tech industry because we like actually programming computers (the "craft-lovers", in the parlance of this blog post) have bee…

I agree some people go to work to work, and claude is find / good for them, but I feel that characterization of us who are loving claude is disingenuous. I’m a creative, while I loved coding and honed my craft, it was creating that always had me hooked. Claude is creating on steroids. Not to mention, it can help you massively improve your code cleanliness. All of the little nice-to-have features, the cleanups, the high unit test coverage, nagging bug fixes, etc., they’re all trivial to do now.

It’s not the same as writing code, but it’s fun.

If your coworkers can’t outpace your code output they’re either not using opus4.6 or they aren’t really trying.

It’s pretty easy to slam 20 PRs a day with some of them being complex changes. The hardest part is testing the diffs, but people are figuring that out too.

Re: Grief and the AI split

#74

I just do not want to deal with other people's AI-generated code.

Your AI can rewrite it to your own standards for free.

You can tell your AI to read their code, and create a new requirements document for a clean-room implementation.

Then you have your AI implement using your own requirements document.

Re: Grief and the AI split

#75
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…

I strongly disagree. There's always been two camps ... on everything! Emacs vs. vi. Command-line editor vs. IDE. IntelliJ vs. VS Code. I could do like twenty more of these: dev teams have always split on technology choices. But, all of those were rational separations. Emacs and vi, IntelliJ and VS Code ... they're all viable options, so they boil down to subjective preference. By definition, anything subjective will…

It doesn’t help that the CEOs of these companies are hyping up the fear. It’s no wonder people are afraid when the people making the products are spouting prophecies of doom.

Re: Grief and the AI split

#76

I’ve heard this thesis a lot, but it’s almost always from the result chasers. It doesn’t resonate with me because I am a result chaser. I like woodworking because I like building something that never existed before. I don’t mind using a CNC router or a 3 printer to help me out. I don’t care about the process, I care about the result. But I care deeply about the quality of the result. I don’t care about the beauty of…

> AI doesn’t help me with these. At least not much. Mostly because the time I spend coding is time I spend understanding, diagnosing, and perfecting. Not the code. The product.

It can actually help a lot here too.

In fact I rarely have AI author or edit code, but I have it all time researching, finding edge cases I didn't think about, digging into dependencies code, finding ideas or alternative approaches. My usage is 90% of the time assisting with information gathering, criticizing (I have multiple reviewer skills with different personas, and I have multiple LLMs run them), refining, reviewing.

Even when it comes to product stuff, many of my clients have complicated business logic. Talking multi-tenant-company warehouse software where each process is drastically different and complexity balloons fast even for a single one of them. It helps to connect the dots between different sources of information (old Jira task, discord dumps, confluence, codebase, etc).

And it can iteratively test and find edge cases in applications too, same as you would do manually by taking control of the browser and testing the most uncommon paths.

I would do much less without this assistance.

I really don't get why people focus so much on the least empowering part (code), where it actually tends to balloon complexity quick or overwhelm you with so much content and edits that you can't have the energy to follow while maintaining quality.

Re: Grief and the AI split

#77
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…

Enjoying something and getting satisfaction out of it are two different things. I don't enjoy the act of coding. But I enjoy the feeling when I figure something out. I also think that having to solve novel puzzles as part of my job helps preserve my brain plasticity as I age. I'm not sure I'll get either of those from claude.

Re: Grief and the AI split

#78
post #24

The divide is a matter of perspective. I'm a 23+ year dev; among the highest level ICs in my org. It's still craft, its just that the craft is different. I don't write *.ts, *.cs files anymore; I write *.md files that other devs are using, that we're using as guardrails, that ensures that we minimize the slop while increasing speed and basically lift every developers level up by several notches. I went from building…

Came here to say something similar. For me, the craft aspect is now even more exciting because I can craft more ambitious things without getting bogged down in the details. For me, refining my conceptual model, drawing diagrams, finding the right way to think about something was the craft. Maybe that's another way of saying: I was trained as a designer, and now the distinction between design (read: architecture, serv…

Heck yeah! Love that way of putting it. Agree. Now there’s more time to focus on making the right architecture and carrying it out. It’s no longer a days long task to do a big refactor to remove code smells.

Re: Grief and the AI split

#79
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…

I strongly disagree. There's always been two camps ... on everything! Emacs vs. vi. Command-line editor vs. IDE. IntelliJ vs. VS Code. I could do like twenty more of these: dev teams have always split on technology choices. But, all of those were rational separations. Emacs and vi, IntelliJ and VS Code ... they're all viable options, so they boil down to subjective preference. By definition, anything subjective will…

what about the fear is irrational?

Re: Grief and the AI split

#80

Earlier quoted context omitted.

Just out of the popularity of the claim, I’ll bite. Both big tech and startups are now full of people working at 10x, features are written as fast as PMs can think them, monoliths self heal with agents buzzing over them. 10x means 10 times the outcomes in a given amount of time, so did you see the last iOS version pack a decade worth of features in a single release? Do you remember when meta moved their backend to ru…

I didn't say anything about increased productivity or 10x. Feel free to revise your strawman.

Fair, let’s revise it then.

If not productivity, what’s the result AI is getting that is disruptive enough to make our previous work obsolete?

Post reply on HN