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

AI doesn’t reduce work, it intensifies it

simonwillison.net

Post reply on HN
Print view View original

291–300 of 329 posts

Re: AI doesn’t reduce work, it intensifies it

#291

Post by bckr »

co_king_3 wrote: post #98
bckr wrote: post #65

Earlier quoted context omitted.

Labor organization yes! I don't quite know how to achieve it. I also worry that my desire to become a manager is in direct conflict with my desire to contribute to labor organization. On a separate note, I have the intensification problem in my personal work as well. I sit down to study, but, first, let me just ask Claude to do some research in the background... Oh, and how is my Cursor doing on the dashboard? Ah, ri…

> I don't quite know how to achieve it. Definitely not by posting on right-wing social media websites. > I also worry that my desire to become a manager is in direct conflict with my desire to contribute to labor organization. It is.

not a very helpful response tbh

Re: AI doesn’t reduce work, it intensifies it

#292

Post by jmalicki »

cedws wrote: post #285
rybosworld wrote: post #283

Earlier quoted context omitted.

AI's can self-critique via mechanisms like chain of thought or user specified guard rails like a hook that requires the test suite to pass before a task can be considered complete/ready for human review. These can and do result in higher quality code. Agree that "good code" is vague - it probably always be. But we can still agree that code quality is going up over time without having a complete specification for what…

Unfortunately I can only give anecdotes, but in my experience the LLM's 'thinking' does not lead to code quality improvements in the same way that a programmer thinking for a while would. In my experience having LLMs write Go, it tends to factor code in not so great way from the start, probably due to lacking the mental model of pieces composing together. Furthermore, once a structure is in place, there doesn't seem…

> A programmer might write a function, notice it becoming too long or doing too much, and then decide break it down into smaller subroutines. I've never seen an LLM really do this, they seem biased towards being additive.

The nice thing is a programmer with an LLM just steps in here, and course-corrects, and still has that value add, without taking all the time to write the boilerplate in between.

And in general, the cleaner your codebase the cleaner LLM modifications will be, it does pick up on coding style.

Re: AI doesn’t reduce work, it intensifies it

#293

Post by jmalicki »

ikr678 wrote: post #216
rybosworld wrote: post #206

Earlier quoted context omitted.

We've gone from "it's glorified auto-complete" to "the quality of working, end-to-end features, is average", in just ~2 years. I think it goes without saying that they will be writing "good code" in short time. I also wonder how much of this "I don't trust them yet" viewpoint is coming from people who are using agents the least. Is it rare that AI one-shots code that I would be willing to raise as a PR with my name o…

Is there a big enough dataset of 'good' code to train from though?

There is a lot of RLHF effort around this.

Re: AI doesn’t reduce work, it intensifies it

#294

Post by jmalicki »

rybosworld wrote: post #218
ikr678 wrote: post #216

Earlier quoted context omitted.

Is there a big enough dataset of 'good' code to train from though?

I (and lots of people) used to think the models would run out of training data and it would halt progress. They did run out of human-authored training data (depending on who you ask), in 2024/2025. And they still improve.

They ran out of passively collected data. RLHF allows them to gather deeper more targeted data.

Re: AI doesn’t reduce work, it intensifies it

#295

Post by phendrenad2 »

falloutx wrote: post #29

I am becoming more and more convinced that AI cant be used to make something better than what could have built before AI. You never needed 1000s of engineers to build software anyway, Winamp & VLC were build by less than four people. You only needed 1000s of people because the executive vision is always to add more useless junk into each product. And now with AI that might be even harder to avoid. This would mean the…

You need 1000 engineers because you have poor engineering leadership, or no engineering leadership, and engineering is a black hole that management shovels money into where it falls directly onto a huge plane of middle managers who do the best they can with their limited power and understanding. Meanwhile your sales team is writing specifications for the next version of the product, which they already promised to customers, and they hired an outside consultant to transform it into 500 spec documents written in damn near legalese, which will appear one day on the lead engineer's desk with no foreshadowing. It turns out that throwing more engineers at the problem helps here because you'll run out of tasks to assign to all of them and some will roam the halls and accidentally connect distributed knowledge back together.

Re: AI doesn’t reduce work, it intensifies it

#296

Post by kaffekaka »

m_fayer wrote: post #102
localhoster wrote: post #19

TBH, I have found AI addictive, you use it for the first time, and its incredible. You get a nice kick of dopamine. This kick of dopamine, is decreasing with every win you get. What once felt incredible, is just another prompt today. Those things don't excite you any more. Plus, the fact that you no longer exercise your brain at work any more. Plus, the constant feeling of FOMO. It deflates you, faster.

What felt incredible was getting the setup and prompting right and then producing reasonable working code at 50x human speed. And you're right, that doesn't excite after a while. But I've found my way to what, for me, is a more durable and substantial source of satisfaction, if not excitement, and that is value. Excuse the cliche, but its true. My life has been filled with little utilities that I've been meaning to p…

I can only speak for myself of course, but injecting software into all those processes to me seems like a source of stress more than something calming.

The best technology is the one we don't even need to use.

Re: AI doesn’t reduce work, it intensifies it

#297

Post by xhevahir »

jillesvangurp wrote: post #271
FeteCommuniste wrote: post #131

Earlier quoted context omitted.

> That's why I'm not worried about losing my job. The whole notion is based on a closed world assumption, which is always a bad assumption. You might be right, but some of us haven't quite warmed to the idea that our new job description will be something like "high-level planner and bot-wrangler," with nary a line of code in sight.

Change can be upsetting. Compilation used to be done by people. People used to write assembler for a living. Entire languages like Cobol, Fortran, Smalltalk came and went. You might still find paid (well paid even) work doing these things of course but it's a bit niche at this point. Things like Cobol are not likely to be picked for new projects. And unless you work in a museum, anything involving punch cards is prob…

Your attitude is Panglossian, and even your concession that these changes are "going to impact the job market quite a bit" massively underestimates the danger we could be facing. As opposed to what happened in any previous era, we're talking about the replacement of workers across practically all white-collar career fields, all happening over the course of a few years. There will be nowhere for these workers to go but down, into low-paid and precarious service work—assuming they can still find work even in these industries, which will have become more crowded with workers of all sorts; the skilled trades are likely to face a frightful race to the bottom as well. How many years of such creative destruction do you think our economic and political systems can weather before something truly disastrous happens?

Re: AI doesn’t reduce work, it intensifies it

#298

Post by cedws »

jmalicki wrote: post #292
cedws wrote: post #285

Earlier quoted context omitted.

Unfortunately I can only give anecdotes, but in my experience the LLM's 'thinking' does not lead to code quality improvements in the same way that a programmer thinking for a while would. In my experience having LLMs write Go, it tends to factor code in not so great way from the start, probably due to lacking the mental model of pieces composing together. Furthermore, once a structure is in place, there doesn't seem…

> A programmer might write a function, notice it becoming too long or doing too much, and then decide break it down into smaller subroutines. I've never seen an LLM really do this, they seem biased towards being additive. The nice thing is a programmer with an LLM just steps in here, and course-corrects, and still has that value add, without taking all the time to write the boilerplate in between. And in general, the…

>The nice thing is a programmer with an LLM just steps in here, and course-corrects

This does not seem to be the direction things are going. People are talking about shipping code they haven't edited, most notably the author of Claude Code. Sometimes they haven't even read the code at all. With LLMs the path of least resistance is to take your hands off the wheel completely. Only programmers taking particular care are still playing an editorial role.

When the code is constructed by an LLM, the human in the driving seat doesn't get a chance to build the mental models that they usually would writing it manually. This stifles the ability to see opportunities to refactor. It is widely considered to be harder to read code than to write it.

>And in general, the cleaner your codebase the cleaner LLM modifications will be

Whilst true, this is a kind of "you're holding it wrong" argument. If LLMs had model of what differentiates good code from bad code, whatever they pull into their context should make no difference.

Re: AI doesn’t reduce work, it intensifies it

#299

Post by jmalicki »

cedws wrote: post #298
jmalicki wrote: post #292

Earlier quoted context omitted.

> A programmer might write a function, notice it becoming too long or doing too much, and then decide break it down into smaller subroutines. I've never seen an LLM really do this, they seem biased towards being additive. The nice thing is a programmer with an LLM just steps in here, and course-corrects, and still has that value add, without taking all the time to write the boilerplate in between. And in general, the…

>The nice thing is a programmer with an LLM just steps in here, and course-corrects This does not seem to be the direction things are going. People are talking about shipping code they haven't edited, most notably the author of Claude Code. Sometimes they haven't even read the code at all. With LLMs the path of least resistance is to take your hands off the wheel completely. Only programmers taking particular care ar…

> Whilst true, this is a kind of "you're holding it wrong" argument. If LLMs had model of what differentiates good code from bad code, whatever they pull into their context should make no difference.

Good code is in the eye of the beholder. What reviewers in one shop would consider good code is dramatically different than another.

Conforming to the existing code base style is good in and of itself, if the context it pulls in makes no difference that makes it useless.

Re: AI doesn’t reduce work, it intensifies it

#300

Post by upboundspiral »

co_king_3 wrote: post #112
rkomorn wrote: post #95

Earlier quoted context omitted.

I find it hard to disagree with this (sadly). I do feels things in general are more "snappy" at the OS level, but once you get into apps (local or web), things don't feel much better than 30 years ago. The two big exceptions for me are video and gaming. I wonder how people who work in CAD, media editing, or other "heavy" workloads etc, feel.

> I wonder how people who work in CAD, media editing, or other "heavy" workloads etc, feel. I would assume (generally speaking) that CAD and video editing applications are carefully designed for efficiency because it's an important differentiator between different applications in the same class. In my experience, these applications are some of the most exciting to use, because I feel like I'm actually able to leverag…

The problem with CAD is that mechanical engineering is still deeply proprietary, especially up and including the software stacks.

There is basically no "open source" in mechanical engineering. So you are relegated to super heavy legacy applications that coast by through their integrations with other proprietary tools. Solidworks is much heavier then FreeCAD but FreeCAD didn't have integrations with simulation tools, with CAM software, used a different geometry engine than industry standard, etc, so when a company tried to turn FreeCAD into a product they failed.

The only open source one sees in mechanical engineering comes out of academia, which while interesting, faces the problem that once the research funds dry up or the project finishes the software is dumped into the open in hard to find places, and is not further developed.

I remain hopeful in the potential for open source, I believe that to have a truly accessible and innovative industry a greater level of openness is needed, but it is yet coming.

I think CAD is a good place to start, as it is not a space where lots of hidden and closely guarded tricks are needed like in Finite Element Analysis. For personal uses FreeCAD is getting there. Snappier than Solidworks, but the workflow layout needs some work.

I am also looking at projects such as https://zoo.dev. In mapping the design 1to1 to code (while keeping gui workflow as well) I think they have a real chance of offering enough value that new companies will be interested in trying out their approach. It opens the doors to automation analysis, and generation that while possible with something like Solidworks is cumbersome and not well documented.

Post reply on HN