Live data from Hacker News

I'm dialing back my LLM usage

zed.dev

111–120 of 252 posts

Re: I'm dialing back my LLM usage

#111
post #45

Earlier quoted context omitted.

honestly my theory is part of it is people who are very caught up in the "craft" part of it and now hate these LLMs for producing shit that pretty much works but isn't like this "perfect specimen" of coding architecture that they now have to pour over. honestly, the vast majority of basically CRUD apps out there we are inflating our skills a bit too much here. even if the code is junk you can adapt your mindset to ac…

The fundamental limitation of LLMs writing code is that reading and understanding code is harder and slower than writing it. With other engineers that I work with there is an established level of trust where I do not need to deep dive into every PR. With LLMs it is like I am constantly doing code reviews for someone with whom I have zero trust. This is fundamentally a slow process, especially if you need to maintain…

which is weird to me because i'm using in prod? literally if i care about style and structure i just say, look at these other few files and figure it out and it's fine.

if i need to work on something mission critical or new i do it by hand first. tests catch everything else. or you can just run it so that you review every change (like in claude code) as it comes in and can still grok the entire thing vs having to review multiple large files at the end.

thus i literally wonder what people are working on that requires this 100% focused mission critical style stuff at all times. i mean i don't think it's magic or AGI, but the general argument is always 1) works for hobby projects but not "production" 2) the LLM produces "messy code" which you have to review line by line as if you wrote it yourself which i've found to not be true at all.

Re: I'm dialing back my LLM usage

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

It feels like a bell curve: - one big set of users who don't like it because it generates a lot of code and uses its own style of algorithms, and it's a whole lot of unfamiliar code that the user has to load up in their mind - as you said. Too much to comprehend, and quickly overwhelming. And then to either side - it unblocks users who simply couldn't have written the code on their own, who aren't even trying to load…

More often than not the "AI" generates a large block of code that doesn't work, that I still have to read and understand - and it's more difficult to understand because it doesn't work, which is a huge waste of my time. Then I just end up writing the damn code myself, which I should have done in the first place - but my boss wants me to try using the AI.

The only thing the "AI" is marginally good at is as a fancy auto-complete that writes log statements based on the variable I just wrote into the code above it. And even this simple use case it gets it wrong a fair amount.

Overall the "AI" is a net negative for me, but maybe close to break-even thanks to the autocomplete.

Re: I'm dialing back my LLM usage

#113

The problem with zed's narrative is that because he failed to use it in productive ways he wants to dial it back altogether but its not clear what he has actually attempted and people dogpiling here reminds me of artists who are hostile to AI tools, it doesn't accurately reflect the true state of the marketplace which actually puts a lot of value on successful LLM/AI tool use especially in the context of software dev…

so, this is not from a developer called zed, but instead a developer called Alberto. This is stated in the first line in the article.

Re: I'm dialing back my LLM usage

#114

Earlier quoted context omitted.

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 implem…

There's a third category I'd place myself in which is doing day to day work in shipping codebases with some history, using the tools to do a faster and better job of the work I'd do anyway. I think the net result is better code, and ideally on average less of it relative to the functionality because refactors are less expensive.

Re: I'm dialing back my LLM usage

#115

Earlier quoted context omitted.

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 techn…

I am sure they will continue to improve just as the static-analyzers and linters are improving. But, fundamentally, LLMs lack a theory of the program as intended in this comment https://news.ycombinator.com/item?id=44443109#44444904 . Hence, they can never reach the promised land that is being talked about - unless there are innovations beyond next-token prediction.

They do lack a theory of program. But also, if there's one consistent theme that you can trace through my 25 of studying and working in ML/AI/whateveryouwanttocallit, it's that symbolic reasoning isn't nearly as critical to building useful tools as we like to think it is.

In other words, I would be wrong of me to assume that the only way I can think of to go about solving a problem is the only way to do it.

Re: I'm dialing back my LLM usage

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

I've been saying this for a while. The issue is if you don't intimately know your code, you can't truly maintain it. What happens when the LLM can't figure out some obscure but that's costing you $$$,$$$ per minute? You think being unable to have the AI figure it out is an acceptable answer? Of course not. LLMs are good for figuring out bugs and paths forward, but don't bet your entire infrastructure on it. Use it as an assistant not a hammer.

Re: I'm dialing back my LLM usage

#117

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 you…

It's worth noting this is the exact argument people used against adopting electric calculators.

Re: I'm dialing back my LLM usage

#118
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

I've been experimenting with them quite a bit for the past two weeks. So far the best productivity i've found from them is very tight hand-holding and clear instructions, objectives, etc. Very, very limited thinking. Ideally none.

What that gets me though is less typing fatigue and less decisions made partly due to my wrists/etc. If it's a large (but simple!) refactor, the LLM generally does amazing at that. As good as i would do. But it does that with zero wrist fatigue. Things that i'd normally want to avoid or take my time on it bangs out in minutes.

This coupled with Claude Code's recently Hook[1] introduction and you can help curb a lot of behaviors that are difficult to make perfect from an LLM. Ie making sure it tests, formats, Doesn't include emojis (boy does it like that lol), etc.

And of course a bunch of other practices for good software in general make the LLMs better, as has been discussed on HN plenty of times. Eg testing, docs, etc.

So yea, they're dumb and i don't trust their "thinking" at all. However i think they have huge potential to help us write and maintain large codebases and generally multiplying out productivity.

It's an art for sure though, and restraint is needed to prevent slop. They will put out so. much. slop. Ugh.

[1]: https://docs.anthropic.com/en/docs/claude-code/hooks

Re: I'm dialing back my LLM usage

#119
I wish there was a browser addon that worked like ublock but for LLM talk. Like just take it all, every blog post, every announcement, every discussion and wipe it all away. I just want humanity to deal with some of our actual issues, like fascism, war in Europe and the middle east, the centralization of our lines of production, the unfairness in our economies.

Instead we're stuck talking about if the lie machine can fucking code. God.

Re: I'm dialing back my LLM usage

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

I think you described it much more succinctly than most people do. It's been my exact experience as well. The LLM can develop much faster than I can build a mental model. It's very easy to get to a point where you don't know what's going on, a bunch of bugs have been introduced and you can't easily fix them or refactor because you're essentially the new guy on your own project. I find myself adjusting by committing code very frequently and periodically asking the LLM to explain it to me. I often ask the LLM to confirm things are working the way it says they are and it tends to find its own bugs that way.

I use an LLM primarily for smaller, focused data analysis tasks so it's possible to move fast and still stay reasonably on top of things if I'm even a little bit careful. I think it would be really easy to trash a large code base in a hurry without some discipline and skill in using LLM. I'm finding that developing prompts, managing context, controlling pace, staying organized and being able to effectively review the LLM's work are required skills for LLM-assisted coding. Nobody teaches this stuff yet so you have to learn it the hard way.

Now that I have a taste, I wouldn't give it up. There's so much tedious stuff I just don't want to have to do myself that I can offload to the LLM. After more than 20 years doing this, I don't have the same level of patience anymore. There are also situations where I know conceptually what I want to accomplish but may not know exactly how to implement it and I love the LLM for that. I can definitely accomplish more in less time than I ever did before.

Post reply on HN