[whatever1]

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"

[physicles]

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.

[rs186]

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.