Comment by rozap | Hacker News Reader

Comment by rozap | Hacker News Reader

Parent Full thread

It would write incorrect code and then you'd need to go debug it, and then you would have to come to the same conclusion that you would have come to had you written it in the first place, only the process would have been deeply frustrating and would feel more like stumbling around in the dark rather than thinking your way through a problem and truly understanding the domain.

In the instance of getting claude to fix code, many times he'll vomit out code on top of the existing stuff, or delete load bearing pieces to fix that particular bug but introduce 5 new ones, or any number of other first-day-on-the-job-intern level approaches.

The case where claude is great is when I have a clear picture of what I need, and it's entirely self contained. Real life example, I'm building a tool for sending CAN bus telemetry from a car that we race. It has a dashboard configuration UI, and there is a program that runs in the car that is a flutter application that displays widgets on the dash, which more or less mirror the widgets you can see on the laptop which has web implementations. These widgets have a simple, well defined interface, and they are entirely self contained and decoupled from everything else. It has been a huge time saver to say "claude, build a flutter or react widget that renders like X" and it just bangs out a bunch of rote, fiddly code that would have been a pain to do all at once. Like, all the SVG paths, paints, and pixel fiddling is just done, and I can adjust it by hand as I need. Big help there. But for the code that spans multiple layers of abstraction, or multiple layers of the stack, forget about it.

I have been seeing this sort of mindset frequently in response to agentic / LLM coding. I believe it to be incorrect. Coding agents w Claude 4 Opus are far more useful and accurate than these comments suggest. I use LLMs everyday in my job as a performance engineer at a big company to write complex code. It helps a ton.

The caveat is that user approach makes all the difference. You can easily end up with these bad experiences if you use it incorrectly. You need to break down your task into manageable chunks of moderate size/complexity, and then specify all detail and context rigorously, almost to the level of pseudocode, and then re-prompt any misunderstandings (and fail fast and restart if LLM misunderstands). You get an intuition for how to best communite with the LLM. There’s a skill and learning curve to using LLMs for coding. It is a different type of workflow. It is unintuitive that this would be true, (that one would have to practice and get better at using them) and that’s why I think you see takes waving off LLMs so often.

I didn't wave off Claude code or LLMs at all here. In fact, I said they're an incredible speedup for certain types of problem. I am a happy paying customer of Claude code. Read the whole comment.

(I'm critical of LLMs but mean no harm with this question) Have you measured if this workflow is actually faster or better at all? I have tried the autocomplete stuff, chat interface (copy snippets + give context and then copy back to editor) and aider, but none of these have given me better speed than just a search engine and the occasional question to ChatGPT when it gets really cryptic.

I find it also really depends on how well you know the domain. I found it incredibly helpful for some Python/tensorflow stuff which I had no experience with. No idea what the API looks like, what functions exist/are built in, etc. Loosely describe what I want even if it ends up being just a few lines of code saves time shifting through cryptic documentation.

For other stuff that I know like the back of my hand, not so much.

I agree. Sonnet 4 has been a breeze to work with. It makes mistakes, but few.

At least for the CRUDs that I make, I really don't think I need a better model. I just wanted it to get much cheaper.

I'm like 60% there with you:

* When it gets the design wrong, trying to talk through straightening the design out is frustrating and often not productive.

* I've learned to re-prompt rather than trying to salvage a prompt response that's complicatedly not what I want.

* Exception: when it misses functional requirements, you can usually get a session to add the things it's missing.

Here's the thing, though. When working with a human programmer, I'm not interested in their code and I certainly don't want to see it, let alone carefully review it (at least not in the early stages, when the design is likely to change 3 or 4 times and the code rewritten); I assume their code will eventually be fine. What I want from a programmer is the insight about the more subtle details of the problem that can only be gained by coding. I want them to tell me what details I missed when I described an approach. In other words, I'm interested in their description of the problems they run into. I want their follow-up questions. Do coding assistants ask good questions yet?

No, they don't, but our preferences differ sharply there! I definitely do want to read code from teammates.

You can ask it to critique a design or code to get some of that - but generally it takes a “plough on at any cost” approach to reaching a goal.

My best experiences have been to break it into small tasks with planning/critique/discussion between. It’s still your job to find the corner cases but it can help explore design and once it is aware they exist it can probably type faster than you.

Get Coderabbit or Sourcery to do the code review for you.

I tend to do a fine tune on the reviews they produce (I use both along with CodeScene), but I suspect you'll probably luck out in the long term if you were to just YOLO the reviews back to whatever programming model you use.

> * When it gets the design wrong, trying to talk through straightening the design out is frustrating and often not productive.

What I have learned is that when it gets the design wrong, your approach is very likely wrong (especially if you are doing something not out of ordinary). The solution is to re-frame your approach and start again to find that path of least resistance where the LLM can flow unhindered.

>It would write incorrect code and then you'd need to go debug it, and then you would have to come to the same conclusion that you would have come to had you written it in the first place, only the process would have been deeply frustrating

A. I feel personally and professionally attached.

B. Yea don’t do that. Don’t say “I want a console here”. Don’t even say “give me a console plan and we’ll refine it”. Write the sketch yourself and add parts with Claude. Do the iiital work yourself, have Claude help until 80%, and for the last 20% it might be OK on its own.

I don’t care what anyone claims there are no experts in this field. We’re all still figuring this out, but that worked for me.

> Yea don’t do that. Don’t say “I want a console here”. Don’t even say “give me a console plan and we’ll refine it”. Write the sketch yourself and add parts with Claude.

Myself, I get a good mileage out of "I want a console here; you know, like that console from Quake or Unreal, but without silly backgrounds; pop out on '/', not '~', and exposing all the major functionality of X, Y and Z modules; think deeply and carefully on how to do it properly, and propose a plan."

Or such.

Note that I'm still letting AI propose how to do it - I just give it a little bit more information, through analogy ("like that console from Quake") or constraints ("but without silly backgrounds"), as well as hints at what I feel I want ("pop out on '/'", "exposing all major functionality of ..."). If it's a trivial thing I'll let it just do it, otherwise I ask for a plan - that in 90%+ cases I just wave through, because it's essentially correct, and often better than what I could come up with on the spot myself! LLMs have seen a lot of literature and production-ready code, so usually even their very first solution already accounts for pitfalls, efficiency aspects, cross-cutting concerns and common practice. Doing it myself, it would likely take me a couple iterations to even think of some of those concerns.

> I don’t care what anyone claims there are no experts in this field. We’re all still figuring this out, but that worked for me.

Agreed. We're all figuring this out as we go.

Reply on news.ycombinator.com