Comment by treis

This is short-sighted. The problem with offshore Indian devs is the communication friction/overhead. You're 9 hours offset, with people who have decent-but-not-great English skills and wildly different cultural priors. If the product people/decision makers are in the US, you're getting a ~50% savings to suffer all those issues, while the cost of tokens remains unchanged. That 50% savings doesn't look very impressive when you're taking a 20% productivity hit from comms friction and crossed wire, and 35% of your total cost is from tokens anyhow. Then it comes out to be a very marginal savings, at the cost of a VASTLY worse hiring experience and VERY high variance of outcomes.

Offshore Indian devs make sense when you can have a large Indian division so you can amortize communication infrastructure/process management over a lot of heads, and you're building for international customers so you're not paying an English -> X tax inherently.

"They will hire 1 software architect in US to write specs and 10 software developers in India" is exactly what everyone said was going to happen in 2004 as software engineering outsourcing really started to gain traction. Malcolm Gladwell's The Earth Is Flat basically made the argument that software engineering in the US was going the way of manufacturing.

And outsourcing certainly became a thing though not in the way everyone predicted. There are far more software engineers in the US today than there were in 2004.

Obviously this is just anecdotal but over my 20+ year career I've worked with a lot of outsourced teams in India and my experience has nearly always been that they require a frustratingly specific degree of direction to product anything of quality.

Just recently I asked a dev there for a POC of a feature with decent specificity and ended up with about 8k LOC of spaghetti. I re-wrote it later in a few hundred. This is about in-line with my career experience.

I've had a few standout devs there but it does feel like a lot are putting in the bare minimum or are just working really far outside of their abilities.

While people will do what they need for money, that is a miserable type of role and the quality of architect will suffer from that.

At least some, but let me give an example.

Request: “manual step X should not be part of the automated build script”

Fulfilled as: build script is now split in two. X is still done as a manual step in between. Rather than prompting and waiting for it to be done, the documentation and scripts no longer mention X.

Part poorly written requirements, part implementing under pressure, and part lack of engineering discipline.

The main issue is catching stuff like this early enough to course-correct. Differences in time zone, language and cultural norms can make that a challenge, all of which LLMs have the advantage in.

There's always wtf, why did we add this feature, but at least in my experience, once a week or so I run into something in this category. Me: "AI, please cleanup/refactor/improve this thing" AI: "Roger that! I deleted the file so now it's perfectly clean" ... insert W.T.F.