Live data from Hacker News

Don't be a meat proxy

gruhn.me

771–780 of 787 posts

Re: Don't be a meat proxy

#771

Earlier quoted context omitted.

So the answer was "What's going on with this account" was 10 pages of homework, with at least 1 mistake to correct? That doesn't seem like an improvement over a conversation.

It was 10 pages of relevant account history with one fuck up. Not sure how u got you u got from what I wrote

Did Claude write that top-level comment?

Re: Don't be a meat proxy

#772
I would say the fact so few people follow your advice and are meat-puppets generating enormous tomes intended for others read/understand may, in fact, save white collar job market.

"Who can understand your insurance plan better than a human who has done it for 25 years! You can just mail them your Claude response and they'll tell you what it means!"

Re: Don't be a meat proxy

#773
post #619

Earlier quoted context omitted.

I mean, we're just the neo-luddites in this case. Or maybe the rust belt when jobs moved elsewhere. The real question isn't if things are going to change around our jobs, its are we going to be able to move fast enough to avoid starving in the streets?

Yeah, the economy wants a dystopia, so we're just gonna have to let that happen industry by industry, calling each group that is exploited for maximal corporate gain a neo-luddite. Inevitability and whatnot. Hell, we're gonna die one day anyway, that's also inevitable, so we might as well all just drink the Kool-Aid too.

there are two things that people do to affect large scale society: things that don't work, and things that are illegal.

Re: Don't be a meat proxy

#774

Earlier quoted context omitted.

The ones who get more productive are either the very incompetent who get pulled up to the AI-floor level, or the very competent who know when and how to use it and for what. The midwits are too proud to use it and instead placate themselves that their precious skill is more special and immune to mechanization than it really is. Many many people have jobs where their contribution is granting access to deliberately und…

I would bet real cash money that many many people, including your coworkers, think that anyone who unironically uses the term "midwit" is completely and totally obnoxious.

Recently saw a podcast about the rise of "AI midwits". The guy's point was that it's good to become a midwit, because it's a stage between knowing nothing and knowing a lot, but an AI midwit just has the aesthetics of a midwit and none of the actual knowledge and is stuck there.

But I don't remember how he defined a midwit, because podcasts are a terrible way to convey knowledge. It might've been something like someone who acts like they know everything.

Re: Don't be a meat proxy

#775

Earlier quoted context omitted.

Some skills are easy re-pick-uppable, like bicycling. Mathematics is probably more challenging. Not sure about programming, especially "borint" business-like programming.

There's a reason games like Factorio or Exapunks are so popular among engineers! Especially if you get a little burned out and can't bring yourself to contribute to a side project, but still want to do programming-ish things that get your brain moving

Try the Factorissimo mod - it lets you make subroutines.

Re: Don't be a meat proxy

#776

Earlier quoted context omitted.

Some skills are easy re-pick-uppable, like bicycling. Mathematics is probably more challenging. Not sure about programming, especially "borint" business-like programming.

Nah. After you have those skills, they don’t go away. Math: the most important stuff is the biggest picture. If you learned it properly (not just memorizing), that’s the last to fade. With programming, the details change but the fundamental skill doesn’t. Or hadn’t as of a few years ago.

The fundamental skill can evolve. It used to be OOP mania as promoted by Uncle Bob, now it's Casey Muratori DOD. At least that's been my perception. I'm sure there was sometimes before Uncle Bob too, but I wasn't alive. I did however learn OOP in school, class collaboration cards or whatever they're called, and then learn why it all needs to be thrown out the window after finishing school.

Casey also pointed out three kinds of programmers: those who just want to get something done and will use an LLM because it's faster, those who actually like programming, and those who actually like LLMs. Last group always gets left out of these discussions.

(Just as importantly to note - Bob-style OOP was just fine on microprocessors of the 80s with no caches. The state of the industry has changed.)

Re: Don't be a meat proxy

#777
post #518

Earlier quoted context omitted.

> Far all we know, there is an amazing developer out there who without LLMs, might have been the single best developer in the country, but even this person might not be able to figure out how to effectively work with LLMs. And vice-versa too. If working with LLMs effectively means accepting subpar results or be a reverse centaur, then I’d be glad not to be able to work with them. I’ve never seen a good example where…

I think many people did argue against these things when they were new. Compilers, for instance, were seen as a waste of the computer's resources and produced less than optimal code.

They were right. Only after quite a lot of evolution did they start being wrong. And they're still not that good at SIMD. ffmpeg still uses assembly-code kernels.

Re: Don't be a meat proxy

#778

Earlier quoted context omitted.

I think people tend to forget that not only do we ourselves have different skillsets and can be amazing at one thing but horrible but another, but this also applies to other people in the world! Far all we know, there is an amazing developer out there who without LLMs, might have been the single best developer in the country, but even this person might not be able to figure out how to effectively work with LLMs. And…

> Far all we know, there is an amazing developer out there who without LLMs, might have been the single best developer in the country, but even this person might not be able to figure out how to effectively work with LLMs. And vice-versa too. If working with LLMs effectively means accepting subpar results or be a reverse centaur, then I’d be glad not to be able to work with them. I’ve never seen a good example where…

I'll argue against half that stuff because you probably don't need it. Do you need kubernetes or does "scp service.exe server: && ssh server systemctl restart service" work for you? GitHub Actions is the worst thing I've ever had to work with and I'd rather have a shell script. What is a task runner, is it an overcomplicated way to SSH?

Re: Don't be a meat proxy

#779

Earlier quoted context omitted.

I want to suggest you read https://www.amazon.com/Advantage-Disadvantage-History-Hacket... You can't just remember every conversation and ... something useful. Indiscriminate memory buries you. What you need is "monumental" memories, which is also known as documentation. AI can be very effective in helping you manage that. That should be kept tight, just like code. You want to keep enough of a record of how you got t…

Added to my reading list, thanks. I was not really thinking in terms of reusing all knowledge at once. It is useful to be able to see what was the reasoning behind a single PR to discriminate for effort. The difference between copy+paste+yes+yes+yes+open-pr and asking n relevant questions about the code is what tends to matter. Also, suppose after a few months you need to look at that code again. Having the possibili…

I think it might be more useful to store a summary of the key decisions, but with mistakes, AI fumbles, iterating on test failures, and all the noise boiled out. If you kept, maybe as part of the commit log a summary of the AI discussion leading to that commit I could set that as very valuable.

Re: Don't be a meat proxy

#780
post #518

Earlier quoted context omitted.

> Far all we know, there is an amazing developer out there who without LLMs, might have been the single best developer in the country, but even this person might not be able to figure out how to effectively work with LLMs. And vice-versa too. If working with LLMs effectively means accepting subpar results or be a reverse centaur, then I’d be glad not to be able to work with them. I’ve never seen a good example where…

I think many people did argue against these things when they were new. Compilers, for instance, were seen as a waste of the computer's resources and produced less than optimal code.

That argument still stands, and is still right. Compilers do allow for some programmers to remain uninformed about the actual behaviour of the code they write and this has allowed for a number of actual harms in the outcome of code. (see: Fujitsu computers floating point errors and the British Postal System's persecution of her own Postmasters as one example among many cases) Also, the most performant code either has to be written such that a compiler doesn't incorrectly unroll it's loops or otherwise mangle the intent, or it has to be fine tuned after the fact to correct such mangling. Even Linus does this for the kernel in some cases.

So, drawing the parallel, 'these are the new garbage' but 'old garbage became acceptable so we should accept the new garbage' as an argument in support of being a meat proxy for Markovian stochastic lossy compression-decompression chatbots is isn't very persuasive, especially among this community with a greater concentration of systems level programmers than the general population.

That being said, i think both chatbots and compilers have a specific level of utility; neither of them should have unrestricted access to production filesystems or networks. That way be dragons.

Post reply on HN