Live data from Hacker News

LLMs can be exhausting

tomjohnell.com

221–230 of 232 posts

Re: LLMs can be exhausting

#221

Earlier quoted context omitted.

I spent more time correcting LLMs or agentics systems than just learning the domain and doing the coding myself. I mainly leave LLM to the boring work of doing tedious repetitive code. If I give it anything resembling anything that I'm not an expert on, it will make a mess of things.

Yeah the old adage "what you put in is what you get out" is highly relevant here. Admittedly I'm knowledgable in most of the domains I use LLMs for, but even so, my prompts are much longer now than they used to be. LLMs are token happy, especially Claude, so if you give it a short 1-2 sentence prompt, your results will be wildly variable. I now spend a lot of mental energy on my prompting, and resist the urge to use…

Yup, it makes me think that the whole bubble/marketing about how AI is going to revolutionize business and managers can just fire or make redundant 80% of their developers because they can replace them with a single Claude subscription to be hyperbolic, and very short sighted. Even from a Business standpoint - most of the cost that is associated with running a business isn't in the people but in the marketing and material cost - developers are probably the least costly part of a business. This is just due to the fact that developer have such a high ROI that it is silly to make the case that your developers are such a significant cost factor for running your business.

That being said, I may get to that stage. How-ever there is still a lot more growing pains to be had with LLM/AI before it reaches that point - if it ever does.

Re: LLMs can be exhausting

#222
post #217

I've found LLMs to be liberating and energizing, not at all exhausting. I can finally do my preferred workflow: Research, (design, critique), (plan, critique, design), implement. Design and planning has a quick enough turnaround cycle to not get annoying. By the time the agent is writing code, I have no involvement anymore. Just set it and forget it, come back in half an hour or so to see if it's done yet. Meanwhile,…

I ran go's deadcode against your repo, it says there are 44 unreachable functions. If you add guardrails like static analysis tools to a pre-commit you can make LLMs tighten things up.

Unfortnately, deadcode flags library API functions as "dead" if they're not consumed by the cmd.

yoloAI is intended to be consumed both as a library and as a standalone binary, and the public 80/20 API surface isn't yet mature enough to make a -filter list worthwhile.

This did give me ideas for some other checks I can add, though! :)

Re: LLMs can be exhausting

#223
post #3

I find LLMs so much more exhausting than manual coding. It’s interesting. I think you quickly bump into how much a single human can feasibly keep track of pretty fast with modern LLMs. I assume until LLMs are 100% better than humans in all cases, as long as I have to be in the loop there will be a pretty hard upper bound on what I can do and it seems like we’ve roughly hit that limit. Funny enough, I get this feeling…

[dead]

Re: LLMs can be exhausting

#224
post #3

I find LLMs so much more exhausting than manual coding. It’s interesting. I think you quickly bump into how much a single human can feasibly keep track of pretty fast with modern LLMs. I assume until LLMs are 100% better than humans in all cases, as long as I have to be in the loop there will be a pretty hard upper bound on what I can do and it seems like we’ve roughly hit that limit. Funny enough, I get this feeling…

I imagine code reviewing is a very different sort of skill than coding. When you vibe code (assuming you're reading teh code that is written for you) you become a coder reviewer... I suspect you're learning a new skill.

Any programmer needs to be able to approach a foreign code base and navigate through it to identify ab issue. Reading code and understanding what is going on is an essential skill.

Re: LLMs can be exhausting

#225

Earlier quoted context omitted.

Who says you can't iterate on a design just because an LLM does the manual typing?

I meant to write “tactile”, not “tactical”, but missed it before the edit window expired. Anecdotally, ask people who knit whether their brain is stimulated. Physically engaging with the thing you are making is part of the process that makes it actually good.

Yet someone who knits can do so without spinning the yarn themselves, or shaving the sheep.

Re: LLMs can be exhausting

#227
post #11

I have always enjoyed the feeling of aporia during coding. Learning to embrace the confusion and the eventual frustration is part of the job. So I don’t mind running in a loop alongside an agent. But I absolutely loathe reviewing these generated PRs - more so when I know the submitter themselves has barely looked at the code. Now corporate has mandated AI usage and is asking people to do 10k LOC PRs every day. Review…

Claude has a built-in /simplify command

I think you just need to add a /complexify one with the same pattern, ask the AI to make everything as complex and long-winded as possible, LOC over clarity

Re: LLMs can be exhausting

#228
post #45

Earlier quoted context omitted.

> The velocity is up AND the quality is up. This is not my experience on a team of experienced SWEs working on a product worth 100m/year. Agents are a great search engine for a codebase and really nice for debugging but anytime we have it write feature code it makes too many mistakes. We end up spending more time tuning the process than it takes to just write the code AND you are trading human context with agent cont…

Whenever actual studies are made about LLM coding they always show that LLM coding is a net loss in quality and delivery speed. (They are good as coder psychotherapy tho.)

One of the "actual studies" was pretty much grabbing developers off the street and telling them to "use AI to make things go fast".

And to no-one's surprise there was no increase in velocity.

I'd really like to see a study using people of similar skill level where one group doesn't use AI and never has and the other have been working with AI tooling for a year or more.

Re: LLMs can be exhausting

#229
I think they are good productivity tools in that they essentially shorten the research loop. Imagine having Google and stack overflow right inside your IDE. On top of that, imagine scaffolding/generators for a lot more "boilerplate" code.

If you look at them through that lens then they are less exhausting in my opinion, but I hear ya.

I feel the burn out too. It's because of all the hype and people out there (most of whom have no programming experience at all mind you) believing these tools can do something they cannot. Then everyone seems to intent on doing better here that they start trying to run multiple agents, etc. Ultimately this results in less productivity.

I'm going to be honest. At work, I've seen the team begin to build custom internal apps and dashboards that literally do the same thing as Jira and observability tools that we already pay for. It just happens to...OMG...put the data that used to be on two different browser tabs onto the same one! Woah! Amazing! It only took two weeks to build too! Jira is so cooked! Except. It's not. Because this little reporting app doesn't do anything and it has bugs to maintain. Oh right and it didn't go through the regular SDLC or follow any code review process so it's a violation of SOC 2. But you know what? They get a pat on the back.

This industry is as the kids like to say - cooked.

Re: LLMs can be exhausting

#230

Earlier quoted context omitted.

Whenever actual studies are made about LLM coding they always show that LLM coding is a net loss in quality and delivery speed. (They are good as coder psychotherapy tho.)

One of the "actual studies" was pretty much grabbing developers off the street and telling them to "use AI to make things go fast". And to no-one's surprise there was no increase in velocity. I'd really like to see a study using people of similar skill level where one group doesn't use AI and never has and the other have been working with AI tooling for a year or more.

> you just need AI certification and over five years experience in AI coding stacks to make use of this

The trillions of dollars of capitalization wasn't based off a promise of "a new IDE that lets you write code slightly faster once you get over the learning curve".

Post reply on HN