Hacker News Reader

Comment by rafaelmn | Hacker News Reader

You didn't specify how you asked Claude to fix it here so hard to evaluate if it's giving you what you asked for or just choosing the wrong approach. It's one of the things these models will do - they will narrow down on what you asked them to do - so for example if you just gave it your code without the deployment and said fix it on code level that would bias it to go in that direction, etc.

Disclaimer: not one of those "you didn't prompt right whenever LLMs fail" people, but just something I've noticed in my use of LLMs - they usually don't have the problem context so can't really tell you "should we even be going down this path"

View on HN

I am pretty sure that if I hinted the direction of the solution the model would come up with the simple proxy config fix. I will try it for fun.

But I was trying to simulate the vibe coding experience where you are completely clueless and rely exclusively on the LLM. It works, but it creates even more work (we call it debt) for the future.

PS I was using Claude within Copilot, so it could definitely see the docker & nginx configuration.

Sounds like you asked Claude for a fix and it gave you a proper fix to your badly designed api endpoint. If it's an operation that's taking that long then yes, implementing it asynchronously is a good idea.

If what you wanted was a simple ductape quick fix I'm sure you could have asked for that and Claude would have recommended what you did, increasing the timeout window which I guess "fixes" the problem.

So would you revamp your entire stack to accommodate one single endpoint and solve a fictional problem?

What is the risk introduced by a long request that requires you to increase to your code complexity by 100x?

Sure I could also dump completely Django and build from scratch with the provision for 10B concurrent users.

My point is that when coding, business context is needed. I was expecting to see from the model what the root cause was and clear statement of the assumptions used when providing the solution. Instead, what I got was "this is a long request, here is the most likely solution for long requests, enjoy your new 1000 loc and dependencies"

Nobody knows if it is a fictional problem. You didn't say what your CPU usage is like, how many users you have, what your UI looks like while your user is waiting. In any serious application, running it asynchronously is the correct solution 99 of 100 times. There is nothing wrong with updating your stack -- you have a business need, and you need to update your architecture, this happens all the time.

"Business context is needed." Then why don't you provide that context? You expect Claude to read your mind? What are we talking about here?

Dude, be humble. If all you want to do is to argue instead of having a productive discussion, this is not the place for you.

I think you’ve nailed it: which fix is better depends on how bulletproof the solution needs to be. If a few people (not paying customers) call the api a few times a week and everyone’s on good WiFi or fiber, it’s probably fine. If you start hearing complaints from your users about failed requests, probably time to switch to polling.

I wonder if this is something you could get Claude to think about by adding some rules about your business context, how it should always prefer the simplest solution no matter what.

Reply on news.ycombinator.com