Hacker News Reader

Comment by ZYbCRq22HbJ2y7 | Hacker News Reader

We have members on my team that definitely feel empowered to wade into new territory, but they make so much misdirected code with LLMs, even when we make everyone use Claude 4 thinking agents.

It seems to me that if you have been pattern matching the majority of your coding career, then you have a LLM agent pattern match on top of that, it results in a lot of headaches for people who haven't been doing that on a team.

I think LLM agents are supremely faster at pattern matching than humans, but are not as good at it in general.

View on HN

> they make so much misdirected code with LLMs

just points to the fact that they've no idea what they're doing and would produce different, pointless code by hand, though much slower. this is the paradigm shift - you need a much bigger sieve to filter out the many more orders of magnitude of crap that inexperienced operators of LLMs create.

It'll be interesting if tools like Claude will end up being used to highlight the people who have no clue what they are doing.

I think you can do this already. If you do not know the underlying concepts, or have no idea about how you have to architecture your project and so forth, then you will have problems with LLMs. So I think many if not most people who have problems with LLMs, it is most likely due to their lack of knowledge and/or their expectation that you can just simply write two sentences and it will figure out what you want and how you want it.

You cannot outsource thinking to LLMs, at least not yet, if ever. You have to be part of the whole process. You need to have knowledge. If you have no idea what it is doing or what you want it to do, you are going to have a difficult time.

The thing is, is it slower to code with LLMs if you already have the knowledge? I think it is so. Coding is formal. There’s usually one correct way to tell the computer to do something (all the alternatives are equivalent through abstraction or transposition). The other ways are what we called bugs and there’s an infinty of them.

The programming language eliminates some (incorrect syntax) while the type system get rid of others (contract error). We also have linter that helps us with harmful patterns. But the range of errors is still enormous. So what’s the probability of having the LLMs be error free or as close as possible to the intended result?

We as humans have reduced the probability of error by having libraries of correct code (or outsourcing the correction of code), thus having a firmer and cognitively manageable foundation to create new code. As well as not having to rely on language to solve problems.

> The thing is, is it slower to code with LLMs if you already have the knowledge?

Maybe if all you do is code, but that’s not how most people work. Being able write I need these things done in this way and then attend a meeting or start researching the next thing is valuable. And because of my other obligations there’s no way I could do more without Claude.

> Coding is formal

I just don’t see it like this; code is craft, and there are ten ways to solve any given problem. Reasonable people can select different tradeoffs, and taste is also a big factor.

Maybe if you are working in very low-level algorithmic, compiler, or protocol development it’s less ambiguous. But almost all software is written many layers above that.

I’m sure if you already sat down and thought through every detail, you might find LLMs slow you down vs typing. Many people use the process of writing, or the process of iterating with customers, to flesh out the ambiguous detail; in which case improving cycle time can improve your time to PMF.

> is it slower to code with LLMs if you already have the knowledge? I think it is so.

In my case it is not slower, so it works for me. I cannot speak for others.

One of the things I’ve noticed is that those people are the same people who before would spend 3 weeks on something before coming out with a copy of the docs that doesn’t actually solve the problem at hand, but it spits out a result that almost matches what you asked for. They never understood the problem in the first place, they always just hammered until the nail went in - now they just have a different tool.

Everytime I have to mentor juniors, it’s more productive to get them to articulate the problem and their initial solution. It’s often sufficient to highlight (mostly for them) how little they actually know about the problem itself to actually rush to solve it.

Reply on news.ycombinator.com