←back to thread

576 points Gricha | 2 comments | | HN request time: 0.009s | 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(23): >>46233156 #>>46233163 #>>46233206 #>>46233362 #>>46233365 #>>46233406 #>>46233506 #>>46233529 #>>46233686 #>>46233981 #>>46234313 #>>46234696 #>>46234916 #>>46235210 #>>46235385 #>>46236239 #>>46236306 #>>46236829 #>>46238500 #>>46238819 #>>46240191 #>>46243246 #>>46243719 #
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 #
FeteCommuniste ◴[] No.46233448[source]
Maybe I'm weird but I enjoy "actually writing the code."
replies(6): >>46233475 #>>46233559 #>>46233598 #>>46233879 #>>46234180 #>>46236874 #
pdntspa ◴[] No.46233475[source]
Me writing code is me spending 3/4 of my time wading through documentation and google searches. It's absolutely hell on my ADD. My ability to memorize is absolutely garbage. Throughout my career I've worked in like 10 different languages, and in any given project I'm usually working in at least 3 or 4. There's a lot of "now what is a map operation in this stupid fucking language called again?!"

Claude writing code gets the same output if not better in about 1/10 of the time.

That's where you realize that the writing code bits are just one small part of the overall picture. One that I realize I could do without.

replies(3): >>46233530 #>>46233646 #>>46234192 #
1. n4r9 ◴[] No.46233530[source]
May be a domain issue? If you're largely coding within a JS framework (which most software devs are tbf) then that makes total sense. If you're working in something like fintech or games, perhaps less so.
replies(1): >>46233603 #
2. pdntspa ◴[] No.46233603[source]
My last job was a mix of Ruby, Python, Bash, SQL, and Javascript (and CSS and HTML). One or two jobs before that it was all those plus a smattering of C. A few jobs before that it was C# and Perl.