←back to thread

925 points dmitrybrant | 4 comments | | HN request time: 0.256s | source
Show context
theptip ◴[] No.45163517[source]
A good case study. I have found these two to be good categories of win:

> Use these tools as a massive force multiplier of your own skills.

Claude definitely makes me more productive in frameworks I know well, where I can scan and pattern-match quickly on the boilerplate parts.

> Use these tools for rapid onboarding onto new frameworks.

I’m also more productive here, this is an enabler to explore new areas, and is also a boon at big tech companies where there are just lots of tech stacks and frameworks in use.

I feel there is an interesting split forming in ability to gauge AI capabilities - it kinda requires you to be on top of a rapidly-changing firehose of techniques and frameworks. If you haven’t spent 100 hours with Claude Code / Claude 4.0 you likely don’t have an accurate picture of its capabilities.

“Enables non-coders to vibe code their way into trouble” might be the median scenario on X, but it’s not so relevant to what expert coders will experience if they put the time in.

replies(16): >>45163642 #>>45163857 #>>45163954 #>>45163957 #>>45164146 #>>45164186 #>>45165282 #>>45165556 #>>45166441 #>>45166708 #>>45167115 #>>45167361 #>>45168913 #>>45169267 #>>45178891 #>>45193900 #
ZYbCRq22HbJ2y7 ◴[] No.45163957[source]
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.

replies(2): >>45165258 #>>45166266 #
baq ◴[] No.45165258[source]
> 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.

replies(1): >>45166299 #
matwood ◴[] No.45166299[source]
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.
replies(1): >>45166962 #
johnisgood ◴[] No.45166962[source]
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.

replies(1): >>45167261 #
1. skydhash ◴[] No.45167261[source]
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.

replies(3): >>45167453 #>>45176245 #>>45186415 #
2. matwood ◴[] No.45167453[source]
> 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.

3. theptip ◴[] No.45176245[source]
> 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.

4. johnisgood ◴[] No.45186415[source]
> 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.