An example from today: I have some scientific calculations that run in a Django app.
One specific endpoint has a function that takes 2-3 minutes to execute. When I was hitting the endpoint I was getting a timeout error. I asked Claude to fix it, and it came up with a huge change in the front end (polling) and backend (celery) to support asynchronous operations.
I instead increased the nginx timeout from 1 minute to 5 minutes. Problem solved without introducing 100x the complexity.
Sounds like Claude is doing the right thing, at least for the general problem.
You are just waiting for this to deteriorate, and at some point that 5min timeout is not long enough, and you'll have to come up with something else again.
And more generally, there are multiple issues with properly handling long running actions -- you want a good UX for these actions in your app, they may need to be queued or be allowed to cancel etc. I don't know the exact situation, but I assume this is a small app so you don't care much about it. But in any serious application where UX is important and you don't want someone to submit 10000 such requests (or 10000 users submitting at the same time) to blow up your backend, the sane design is to do this asynchronously with other mechanism to manage the actions.
> Sounds like Claude is doing the right thing, at least for the general problem.
No not really. The engineer’s job is work within the constraints first and when a big change is really warranted, pursue it.
It’s having a structural issue that can be fixed with a reinforcement, and an automated system suggests to demolish and rebuild part of the most structure altogether. It’s not that clear cut. You maybe right but I wouldn’t jump into conclusions like this.
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"
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"
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.
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've read previously that certain parts of the software industry at one point was all in on move fast and break things, but then after a while the quality of their code was so bad that they took a different course. Maybe some people didn't get their fill the first time round. I can see that LLMs are going to be quick, I can't see how their code bases are going to do anything but turn into a very bad state, probably much more so this time round.
“I have an application, it only has a few users, hosted on nginx. There is 1 endpoint which can take up to 5 minutes to execute. What’s the best way to fix this?”
Response:
“Immediate fix…
Increase nginx timeout settings explains how”
I happen to have a php project here hosted on nginx with docker locally for running and testing. So I asked cursor the exact same question. It suggested refactoring to make the call async, or changing nginx. I said change nginx. It updated the config and rebuilt docker compose to make sure the change happened.
It’s always a user issue when it comes to using AI.
One specific endpoint has a function that takes 2-3 minutes to execute. When I was hitting the endpoint I was getting a timeout error. I asked Claude to fix it, and it came up with a huge change in the front end (polling) and backend (celery) to support asynchronous operations.
I instead increased the nginx timeout from 1 minute to 5 minutes. Problem solved without introducing 100x the complexity.