←back to thread

559 points Gricha | 5 comments | | HN request time: 0s | source
Show context
xnorswap ◴[] No.46233056[source]
Claude is really good at specific analysis, but really terrible at open-ended problems.

"Hey claude, I get this error message: <X>", and it'll often find the root cause quicker than I could.

"Hey claude, anything I could do to improve Y?", and it'll struggle beyond the basics that a linter might suggest.

It suggested enthusiastically a library for <work domain> and it was all "Recommended" about it, but when I pointed out that the library had been considered and rejected because <issue>, it understood and wrote up why that library suffered from that issue and why it was therefore unsuitable.

There's a significant blind-spot in current LLMs related to blue-sky thinking and creative problem solving. It can do structured problems very well, and it can transform unstructured data very well, but it can't deal with unstructured problems very well.

That may well change, so I don't want to embed that thought too deeply into my own priors, because the LLM space seems to evolve rapidly. I wouldn't want to find myself blind to the progress because I write it off from a class of problems.

But right now, the best way to help an LLM is have a deep understanding of the problem domain yourself, and just leverage it to do the grunt-work that you'd find boring.

replies(21): >>46233156 #>>46233163 #>>46233206 #>>46233362 #>>46233365 #>>46233406 #>>46233506 #>>46233529 #>>46233686 #>>46233981 #>>46234313 #>>46234696 #>>46234916 #>>46235210 #>>46235385 #>>46236239 #>>46236306 #>>46236829 #>>46238500 #>>46238819 #>>46240191 #
pdntspa ◴[] No.46233365[source]
That's why you treat it like a junior dev. You do the fun stuff of supervising the product, overseeing design and implementation, breaking up the work, and reviewing the outputs. It does the boring stuff of actually writing the code.

I am phenomenally productive this way, I am happier at my job, and its quality of work is extremely high as long as I occasionally have it stop and self-review it's progress against the style principles articulated in its AGENTS.md file. (As it tends to forget a lot of rules like DRY)

replies(12): >>46233446 #>>46233448 #>>46233642 #>>46233652 #>>46233782 #>>46234010 #>>46234898 #>>46235480 #>>46238997 #>>46241434 #>>46241981 #>>46242791 #
n4r9 ◴[] No.46233446[source]
I think we have different opinions on what's fun and what's boring!
replies(4): >>46233963 #>>46234282 #>>46234342 #>>46234495 #
Nemi ◴[] No.46234495[source]
You've really hit the crux of the problem and why so many people have differing opinions about AI coding. I also find coding more fun with AI. The reason is that my main goal is to solve a problem, or someone else's problem, in a way that is satisfying. I don't much care about the code itself anymore. I care about the thing that it does when it's done.

Having said that I used to be deep into coding and back then I am quite sure that I would hate AI coding for me. I think for me it comes down to – when I was learning about coding and stretching my personal knowledge in the area, the coding part was the fun part because I was learning. Now that I am past that part I really just want to solve problems, and coding is the means to that end. AI is now freeing because where I would have been reluctant to start a project, I am more likely to give it a go.

I think it is similar to when I used to play games a lot. When I would play a game where you would discover new items regularly, I would go at it hard and heavy up until the point where I determined there was either no new items to be found or it was just "more of the same". When I got to that point it was like a switch would flip and I would lose interest in the game almost immediately.

replies(7): >>46234628 #>>46235992 #>>46236149 #>>46236930 #>>46237085 #>>46239535 #>>46242499 #
pdntspa ◴[] No.46234628[source]
You are hitting the nail on the head. We are not being hired to write code. We are being hired to solve problems. Code is simply the medium.
replies(2): >>46234982 #>>46236018 #
agumonkey ◴[] No.46236018[source]
but do you solve the problem if you just slap a prompt and iterate while the LLM gathers diffs ?
replies(3): >>46236627 #>>46236892 #>>46237176 #
ben_w ◴[] No.46236892[source]
Depends what the problem is.

Sometimes you can, sometimes you have to break the problem apart and get the LLM to do each bit separately, sometimes the LLM goes funny and you need to solve it yourself.

Customers don't want you wasting money doing by hand what can be automated, nor do they want you ripping them off by blindly handing over unchecked LLM output when it can't be automated.

replies(1): >>46237608 #
1. agumonkey ◴[] No.46237608[source]
there are other ways: being scammed by lazy devs using AI to produce what devs normally do and not saving any money for the customer. i mentioned it in another thread, i heard first hand people say "i will never report how much time savings i get from gemini, at best i'll say 1 day a month"
replies(1): >>46241706 #
2. Dylan16807 ◴[] No.46241706[source]
If you produce the same product, then you get to ask for the same pay. That's not a scam.

If enough people can make the product faster, then competition will drive the price down. But the ability to charge less is not at all an obligation to charge less.

replies(1): >>46242445 #
3. agumonkey ◴[] No.46242445[source]
it's paradoxical, the llm is not helping consumers, it's not helping the experienced engineer, it's helping a new class of devs that just want the easy way out. and ultimately this wave will make the price go down to the point the skilled dev won't be able to sustain long term growth because learning more and more advanced will not be valued by the economy.. just a thought but i don't see a nice path ahead now
replies(1): >>46242984 #
4. Dylan16807 ◴[] No.46242984{3}[source]
Why is it not helping the experienced engineer? I don't fully understand your scenario.

If the experienced engineer is already faster than the LLM, their job is not at risk.

If the LLM is faster then the experienced engineer at making some kind of code product, then the experienced engineer can use it to save time. And in the short term they can spend even more time learning! Maybe it's a net negative because it helps the "new class of devs that just want the easy way out" more, but it's still helping the experienced engineer.

And if increased competition drops the price then the LLM's influence is helping customers.

replies(1): >>46243112 #
5. agumonkey ◴[] No.46243112{4}[source]
you may have a point, i'm fuzzy in my perception right now but there are non linear factor imo, here's how i see things

- a market needs a certain kind of product (feature set, complexity, performance)

- good engineer could apply skills to deliver that

- lazy engineers couldn't, but with llm they can, it gives them solutions without understanding much, which is irrelevant for them, they want to ship

- i myself don't enjoy having code spilled out for me, and the time savings from llm won't bring much more joy (unlike the lazy engineer who is happy)

- a llm might help me do more advanced things but the market might not care for it. say the average user wants a dashboard with a bunch of data points and a few actions. the llm answer will match that perfectly. I could ask the llm to produce a more complex dashboard with more customization, more feature.. but the user will not want it because it's beyond its needs

so yeah it's a matter of ratio, it seems that lazy devs will get a 10x improvement while a skilled one will only get 1.5 and might be squeezed out of the market