[dead]
At Amazon, some coders say their jobs have begun to resemble warehouse work
591–600 of 897 posts
Re: At Amazon, some coders say their jobs have begun to resemble warehouse work
#592As a software dev I always felt like working warehouse - sprints, strony points being held on productivity metrics. people think all devs work FAANG like companies when there is loads of companies where devs are treated like dirt only now one FAANG company catches up with reality. Where business people seem to never be measured in any way. If requirements were shitty - well dev team did a bad job - not that business…
Amazon is a well known sweatshop -- instead of producing clothes they produce code.
Re: At Amazon, some coders say their jobs have begun to resemble warehouse work
#593Earlier quoted context omitted.
This made the rounds recently: https://harper.blog/2025/02/16/my-llm-codegen-workflow-atm/ That quote really misrepresents his writing.
Then one wonders what the agenda of the NYT is here. Does this also misrepresent Willison's writing? And just as the proliferation of factories abroad has made it cheap and easy for entrepreneurs to manufacture physical products, the rise of A.I. is likely to democratize software-making, lowering the cost of building new apps. “If you’re a prototyper, this is a gift from heaven,” Mr. Willison said. “You can knock som…
Probably because the author's main focus was about potential change in working conditions and not the veracity of the AI hype. But disappointing nonetheless.
To be clear, I'm sure some critical software engineering jobs will be replaced by AI though. Just not in the way that zealots want us to think. From the looks of it right now, AI is far from replacing software engineers in terms of competence. The utter incompetence was in full public display just last week [1]. But none of that will matter to greedy corporate executives, who will prioritize short-term cost savings. They will hop from company to company, personally reaping the benefits while undermining essential systems that users and society rely on with AI slop. That's part of the reason why the C-suites are overhyping the technology. After all, no rich executive has faced consequences for behaving this way.
Re: At Amazon, some coders say their jobs have begun to resemble warehouse work
#594Earlier quoted context omitted.
> Since I started in the 90s, SW dev has become more and more tightly controlled and feels more like an assembly line. When I started, you could work for weeks and months without much interruption. You had plenty of time for experimentation and creativity. Now everything is ticked based and you constantly have to report status and justify what you are doing Yeah the consistent "reporting" of "status" on "stand-ups" w…
> you say some filler to get someone incapable of understanding what it is that you're doing off your back for 24 more hours has consistently been one of the most useless and unpleasant parts of the job This sucks for the 50% or so who are like you, but there's another 50% who won't really get much done otherwise, either because they don't know what to do and aren't self-motivated or capable enough to figure it out (…
Those people should not have been hired, or should have been let go at 6 months when that became obvious. The real solution to this problem doesn't fit with most management methodology though.
Re: At Amazon, some coders say their jobs have begun to resemble warehouse work
#595> [Harper Reed] cautioned against being overly precious about the value of deeply understanding one’s code, which is no longer necessary to ensure that it works. That just strikes me as an odd thing to say. I’m convinced that this is the dividing line between today’s software engineers and tomorrow’s AI engineers (in whatever form that takes - prompt, vibe, etc.) Reed’s statement feels very much like a justification…
The whole auto factory thing sounds completely misinformed to me. Just because a machine made it does not mean the output isn't checked in a multitude of ways. Any manufacturing process is subject to quality controls. Machines are maintained. Machine parts are swapped out long before they lead to out-of-tolerance work. Process outputs are statistically characterised, measured and monitored. Measurement equipment is r…
Additionally production lines are all about doing the same thing over and over again, with fairly minimal variations.
Software isn't like that. Because code is relatively easy to reuse, novelty tends to dominate new code written. Software developers are acting like integrators in at least partly novel contexts, not stamping out part number 100k of 200k that are identical.
I do think modern ML has a place as a coding tool, but these factory like conceptions are very off the mark imo.
Re: At Amazon, some coders say their jobs have begun to resemble warehouse work
#596An 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…
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.
Re: At Amazon, some coders say their jobs have begun to resemble warehouse work
#597Earlier quoted context omitted.
I already imagine future devs wide-eyed saying things like: "He/She can _debug_!!"
I mean I already heard comments about myself when I went and RTFM'd "You read manuals?!?" "... Yeah? (pause) Wait, you don't ?!?!?"
(Anecdote) Best job I ever had, I walked in and they were like "yeah, we don't have any training or anything like that", but we've got a fully setup lab and a rotating library of literature. "Yeah I'm not going to be around, but here are the office keys" don't blow up the company pretty much.
Re: At Amazon, some coders say their jobs have begun to resemble warehouse work
#598Earlier quoted context omitted.
“I instead put in a hacky solution because I’m not a programmer and didn’t understand the solution or why it might be better”
Explain to us non-programmers why a 60" request (the default nginx timeout) is ok, but a 61" request is not.
lol it’s funny you have to ask.
Out of curiosity I asked Claude.
“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.
Re: At Amazon, some coders say their jobs have begun to resemble warehouse work
#599Earlier quoted context omitted.
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 wh…
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.
Re: At Amazon, some coders say their jobs have begun to resemble warehouse work
#600Earlier quoted context omitted.
> Who's filling that role in this brave new world? Us? (Yeah, we’re fucked)
In a world of vibe coders, those who can still debug on their own, will have quite a valuable skill.
Are least for a few more generations of model.
I just finished creating a multiplayer online party game using only Claude Code. I didn't edit a single line. However, there is no way someone who doesn't know how to code could get where I am with it.
You have to have an intuition on the sources of a problem. You need to be able to at least glance at the correct and understand when and where the AI is flailing, so you know to backtrack or reframe.
Without that you are as likely to totally mess to you app. Which also means you need to understand source control and when to save and how to test methodically.