Live data from Hacker News

I'm dialing back my LLM usage

zed.dev

61–70 of 252 posts

Re: I'm dialing back my LLM usage

#61
post #12

LLMs save me a lot of time as a software engineer because they save me a ton of time doing either boilerplate work or mundane tasks that are relatively conceptually easy but annoying to actually have to do/type/whatever in an IDE. But I still more-or-less have to think like a software engineer. That's not going to go away. I have to make sure the code remains clean and well-organized -- which, for example, LLMs can h…

> [LLMs] save me a ton of time doing either boilerplate work I hear this frequently from LLM aficionados. I have a couple of questions about it: 1) If there is so much boilerplate that it takes a significant amount of coding time, why haven't you invested in abstracting it away? 2) The time spent actually writing code is not typically the bottleneck in implementing a system. How much do you really save over the devel…

I don't know about the boilerplate part but when you are e.g. adding a new abstraction that will help simplify an existing pattern across the code base something like Copilot saves a ton of time. Write down what has to happen and why, then let the machine walk across the code base and make updates, update tests and docs, fix whatever ancillary breaks happen, etc. The real payoff is making it cheaper to do exploratory refactors and simple features so you can focus on making the code and overall design better.

Re: I'm dialing back my LLM usage

#62
post #11

Am I spending too much time on HN or is every post/comment section filled with this same narrative? Basically, LLMs are exciting but they produce messy code for which the dev feels no ownership. Managing a codebase written by an LLM is difficult because you have not cognitively loaded the entire thing into your head as you do with code written yourself. They're okay for one-off scripts or projects you do not intend t…

How is that that different than working in a large codebase with 25+ other devs.

My org has 160 engineers working on our e-commerce frontend and middle tiers. I constantly dive into repos and code I have no ownership of. The gitblame shows a contractor who worked here 3 years ago frequently.

Seems LLM does good in small, bad in medium, good again as small modules within big.

Re: I'm dialing back my LLM usage

#64
post #11

Am I spending too much time on HN or is every post/comment section filled with this same narrative? Basically, LLMs are exciting but they produce messy code for which the dev feels no ownership. Managing a codebase written by an LLM is difficult because you have not cognitively loaded the entire thing into your head as you do with code written yourself. They're okay for one-off scripts or projects you do not intend t…

Yes, it's very polarized. That being said, people have shown a lot of code produced by LLMs so I don't understand the dismissive argument you make at the end. Below is a link to a great article by Simon Willison explaining an LLM assisted workflow and the resulting coded tools. [0] https://simonwillison.net/2025/Mar/11/using-llms-for-code/ [1] https://github.com/simonw/tools

While I greatly appreciate all of Simon Willson's publishing, these tools don't meet the criteria of the OP's comment in my opinion. Willson's tools archive all do useful, but ultimately small tasks which mostly fit the "They're okay for one-off scripts or projects you do not intend to maintain" caveat from OP.

Meanwhile, it's not uncommon to see people on HN saying they're orchestrating multiple major feature implementations in parallel. The impression we get here is that Simon Willson's entire `tools` featureset could be implemented in a couple of hours.

I'd appreciate some links to the second set of people. Happy to watch YouTube videos or read more in-depth articles.

Re: I'm dialing back my LLM usage

#65
post #9

These seem like good checkpoints (and valid criticisms) on the road to progress. But it's also not crazy to think that with LLMs getting smarter (and considerable resources put into making them better at coding), that future versions would clean up and refactor code written by past versions. Correct?

Maybe. But there's also an argument to be made that an ounce of prevention is worth a pound of cure.

Maybe quite a few pounds, if the cure in question hasn't been invented yet and may turn out to be vaporware.

Re: I'm dialing back my LLM usage

#66
Can relate. I've also shifted towards generating small snippets of code using LLMs, giving them a glance, and asking to write unit tests for them. And then I review the unit tests carefully. But integrating the snippets together into the bigger system, I always do that myself. LLMs can do it sometimes but when it becomes big enough that it can't fit into the context window, then it's a real issue because now LLMs doesn't know what's going on and neither do you. So, I'll advise you to use LLMs to generate tedious bits of code but you must have the overall architecture committed into your memory as well so that when AI messes up, at least you have some clue about how to fix it.

Re: I'm dialing back my LLM usage

#67
post #11

Am I spending too much time on HN or is every post/comment section filled with this same narrative? Basically, LLMs are exciting but they produce messy code for which the dev feels no ownership. Managing a codebase written by an LLM is difficult because you have not cognitively loaded the entire thing into your head as you do with code written yourself. They're okay for one-off scripts or projects you do not intend t…

> The other side of it is people who seem to have 'gotten it' and can dispatch multiple agents to plan/execute/merge changes across a project and want to tell you how awesome their workflow is without actually showing any code.

This is a great read on the situation. Do you think these people are just making it up/generating baseless hype?

Re: I'm dialing back my LLM usage

#68
post #11

Am I spending too much time on HN or is every post/comment section filled with this same narrative? Basically, LLMs are exciting but they produce messy code for which the dev feels no ownership. Managing a codebase written by an LLM is difficult because you have not cognitively loaded the entire thing into your head as you do with code written yourself. They're okay for one-off scripts or projects you do not intend t…

Yes, it's very polarized. That being said, people have shown a lot of code produced by LLMs so I don't understand the dismissive argument you make at the end. Below is a link to a great article by Simon Willison explaining an LLM assisted workflow and the resulting coded tools. [0] https://simonwillison.net/2025/Mar/11/using-llms-for-code/ [1] https://github.com/simonw/tools

its really not that different.

"f you assume that this technology will implement your project perfectly without you needing to exercise any of your own skill you’ll quickly be disappointed."

"They’ll absolutely make mistakes—sometimes subtle, sometimes huge. These mistakes can be deeply inhuman—if a human collaborator hallucinated a non-existent library or method you would instantly lose trust in them"

"Once I’ve completed the initial research I change modes dramatically. For production code my LLM usage is much more authoritarian: I treat it like a digital intern, hired to type code for me based on my detailed instructions."

"I got lucky with this example because it helped illustrate my final point: expect to need to take over. LLMs are no replacement for human intuition and experience. "

Re: I'm dialing back my LLM usage

#69
post #9

These seem like good checkpoints (and valid criticisms) on the road to progress. But it's also not crazy to think that with LLMs getting smarter (and considerable resources put into making them better at coding), that future versions would clean up and refactor code written by past versions. Correct?

nope, there are limits to what next-token predictions can do, we we have hit those limits. cursor and the like are great for some usecases - for example a semantic search for relevant code snippets, and autocomplete. But beyond that, they only bring frustration in my use.

Arguably most of the recent improvement in AI coding agents didn't exactly come from getting better at next token prediction in the first place. It came from getting better at context management, and RAG, and improvements on the usable context window size that let you do more with context management and RAG.

And I don't really see any reason to declare we've hit the limit of what can be done with those kinds of techniques.

Re: I'm dialing back my LLM usage

#70

I think they are making me more productive in achieving my targets and worse in my ability to program. They are exactly like steroids - bigger muscles fast but tons of side effects and everything collapses the moment you stop. Companies don't care because they are more concerned about getting to their targets fast instead of your health. Another harmful drug for our brain if consumed without moderation. I won't entir…

Your steroids comparison made me think of Cal Newport's recent blog post[1] where he argues that AI is making us lazy. He quotes some researchers who hooked people up to EEG machines then had them work. The people working without AI assistance incurred more brain "strain" and that's probably a good thing.

But even he doesn't think AI shouldn't be used. Go ahead and use it for stuff like email but don't use it for your core work.

[1] https://calnewport.com/does-ai-make-us-lazy/

Post reply on HN