alt Hacker NewsAlthough obviously I wouldn't like it happening to me, if the offshoring quality was as good as the original -- and I'm sure sometimes it was -- I can't find any valid objection to it. It is, after all, just a different bunch of people being paid to do some work. Why must it be "us" who get that work? Why can't it be "them"?
Being replaced by a machine is different -- but still, not in a way that I can authoritatively say ought not to happen. If you could get your shirt made by a woman, or the same shirt made by a machine that costs 5% of what it would cost to pay the woman, you will pick the machine 99% of the time. Almost anyone would.
Being replaced by other people, or by a machine, is a very sad thing for the person being replaced. But I can't persuade myself that all by itself it is morally wrong in any sense.
The bottleneck in software engineering has always been communication, whether that is engineers communicating amongst themselves or clients communicating what they want, or client's customers communicating to clients who communicate to management who communicate to middle management who communicate to engineers.
Every step introduces misunderstanding and miscommunication, and minds change, and when you go down the wrong path it is hard to alter course or start over while avoiding blame and ill feeling.
Offshoring quality was not as good as the original, because the original was being produced by developers who were close to the clients and steeped in the same assumptions.
With offshoring, all of the weight was borne by the specification - if something was not captured, it did not exist. It doesn't matter how much it was just a basic assumption that something would work that way - if you didn't say precisely what you wanted, you didn't get anything even close.
So someone close to a product could implement something in a week for x money. Management would see that "week" as a fixed unit of work that could be given to someone who would work for less - but that other person would require an order of magnitude more "prompting" in order to produce what you really wanted, because they didn't have the same knowledge and assumptions.
So their calculus was, well, it might actually take 5 weeks to get the same output, but it was still cheaper. But that completely overlooks the local overhead of 5 failed iterations, and the cost to client relations, or the cost to internal staff burning out in frustration at what was once simple becoming multiple needless failures, or the additional cost of documenting the spec to such a degree nothing gets left out. And the latter, you can't do until you've failed enough to know both sides different assumptions and knowledge gaps.
(Edit: also my point wasn't don't do it or that this can never work - it was that in this case management simply didn't care about the demonstrable quality problem because the cost of reiterating was so low they could afford to write off the first couple of failed attempts, and this is exactly the attitude we'll get with AI. If you can get something that's superficially most of the way there in an hour with a prompt all by yourself, there's no cost to just changing your mind, retrying, trying other things, all with no pesky engineers slowing things down)