Oh man! Our entire team has been replaced by Vietnam developers.
old.reddit.com
old.reddit.com
There’s always a marginalized group to exploit.
That human may become less and less technically skilled over time as the models become better.
But costs for AI could be similar to developer wages in emerging markets for a while... I think nobody is currently charging the real cost of their AI stuff to end users yet.
I don't understand this thing where people know the future before it's been proven to happen. It's wrong. It's a 'maybe' at best.
Not too long ago, the near future was supposed to have self-serving cars everywhere and that is still hobbling along instead.
Add "legal obligations" and the "cost of a pilot license" to the list.
For fixed wing private flying you are looking at at least hundred hours fully dedicated to new knowledge and skills at an expensive rate. That's assuming you are proficient at learning and able-bodied enough to pass medical.
Unlike driving, when flying you can't just safely pull off to shoulder and stop to figure out whatever problem you are having. So there's a lot effort spent on ensuring whoever is flying is able to prevent known issues and handle emergencies in a non-tragic way.
The vast majority of development work isn't creating slightly modified boilerplate.
More like 'language models can kinda build 5% of a CRUD app somewhat correctly sometimes'.
Would love to be proven wrong tho.
Yes. Claude 3.5 Sonnet is able to do those things when you ask for them.
Said who, exactly? A bunch of media websites that try to catch a hype?
Uber, the ride-hailing app?
They've been claiming this for at least 10 years, if not more.
So, almost never when it really matters.
It's not a matter of an AGI system getting it wrong, there is no AGI system. There are only multi-modal ML systems, which are not the same.
Like with self driving cars, they are delayed but Waymo is doing 50k driverless rides a week and expanding. And apparently the latest Tesla FSD is a big improvement if still not robotaxi safe yet.
It's not like driverless is "theoretically impossible". But when people confidently they know what the near future is going to be, they're just... wrong. And it's really tedious having to deal with that kind of attitude when we're all here for productive conversation.
But I often get answers faster this way, compared to doing a plain search, so they've been useful for me.
Useful, but not useful enough to do my job for me, as most of the hard work is fitting into an existing large codebase with its own style, architecture, private libraries etc., or where I'm making a UI fit a design doc that the AI can't really see despite having some textual representation of the design as well as the UI code.
Fortunately for me, 128k token context windows aren't enough to fit a 120 kloc project, and the haystack demos don't fully reflect the needs.
But 5 years ago, the best we had was GPT-2 / AI Dungeon, so I'm just going to keep saving and plan around not being able to get a next job — even if I'm being fooled by a Clever Hans, I'd still get early retirement.
It looks to work fine on a one-off single script thing. Which is marginally useful sometimes. I did create my company single page html site with it because I didn’t really care about it and just needed it for a bank to believe I’m selling services.
That can't happen while the complexity of basic living keeps sharply increasing.
Between my kids' generation and mine, the number of factors tied to gaining employment, housing, transportation and all basic needs is massively higher. And those factors brought their own factors that also need weighing and evaluating.
My job definitely can be largely replaced by AI, if a human reviews the code. I'm sure in my domain(data engineering) many positions are not safe.
I need to drill deeper into a tech skill other than just doing ETL. I'm thinking about system programming.
AI is useful for getting started in some cases where you can clearly describe going in what you want. Therein lies the rub: no one knows what they want with total fidelity starting out. If we could, then we’d probably be able to give an accurate time estimate. It’s rarely that simple however. There’s always some complexity that hasn’t been accounted for. Something that an AI, lacking any kind of real understanding will be able to help with much less automatically fix.
A well-paid First World developer uses LLM to get a basic app, then tweaks it until it works to the customer's satisfaction. This person speaks excellent local language and is a full-time employee who knows how the company works.
The alternative just replaces the "LLM" part with "large team of Third or Fourth World developers."
Maybe this time it's different, but by now I'll only believe it when I see it.
In other words, a human to do all the hard parts.
Remember when auto-generated code from diagrams was all the rage? All that was needed, according to the hucksters of the day, was a business person to draw some boxes and lines, then press a button and out pops an application.
I'm adding your comment to my list of "thing people say AI will SOON™ be able to do"
Not realizing this is a mistake many enterprise IT shops make.
The boring crud-thingie that someone hacks together will sooner rather than later have to be integrated in a distributed system of state - this is where it gets hairy and most enterprises get stuck.
It’s good for me but it’s all terrible.
By the way; no way I mean VN or IN developers are inherently bad, but these cheap sweat shops, who pile on work in just pushing through tasks for multiple clients as much as possible is maybe even worse than current LLMs code.
This is highly misleading.
" boring enterprise apps " have the HIGHEST level of complexity, complication, dependencies, INTER-dependencies, tech debt, totally uncontrollable requirements (the gov demands to implement, nationwide...) than ANY OTHER APP.
It is FAR easier to build an OS than a barely decent ERP. (and this means, Linux became rock solid faster than the custom ERP that most companies started in 1980. You bet, they have not finished it. And is currently broken. And it has many restarts, iterations, etc)
I know, I work on the side building an RDBMS, and that is how I relax. RDBMS are a serious beast, but nothing, nothing, nothing like the complexity of working in " boring enterprise apps ".
I started doing a kind of `small`, hyperfocused niche, ERP around 2004. Is still halfway.
Look for example:
https://news.ycombinator.com/item?id=39371339
ERPs are a beast that eventually incorporates anything and everything you can imagine, and even then, so coupled to a particular kind of business (or just ONE of them) that there is NO way to make a semi-universal solution.
Life is a cycle. Karma is a bitch. So be nice and diversify your skillset.
I suspect some tight number crunching - of money and bits - is necessary for this to work. I could see a joblord popping up who provides the (not cheap) Starlink connection and sells the local labor at a profit. I wager the arrangement will be as exploitive as possible.
More thoughts: A system programmer in a non-cost center is the best pick. A game engine programmer is better than a devops in that perspective.
That was my hope with my trajectory, but I suppose I underestimated corporate greed/incompetence and overestimated how much people care about a proper engine programmer. Had people connections but 90% of them were also laid off or on the cusp. Some simply had the entire studio shut down.
I probably wouldn't feel too bad if, despite all this, the industry is pretending that they are still hiring as some facade to investors. Many aren't, based on what loose contacts I had remaining.
But as an engine programmer I'm sure you can find some other places, maybe other than studios? I know Unity is hiring, and ARM is also hiring (checkout Felipe lira on LinkedIn).
Haven't looked into ARM, so I'll check that out. Thanks. I could use any leads at this point.
When this happens get out. The shitty developers will taint your own skills eventually.
What happens when Vietnam runs out too?
I believe there was some other kind of added value involved, perhaps they hired a more competent team or with a broader skillset.
By te way, I love the negative comments about the level of English proficiency in the Vietnamese team in a post riddled with mistakes.
Same company, different oursourcing situation - needed some critical low level (assembler) code written. Outsourced to a different region, the developers understood what was needed and turned things around much faster than expected. A small consultancy instead of one of the body shops.
Interestingly the post mentioned English language as a skill. Wonder how much of a barrier that is for Vietnamese devs?
The culture gap with India is huge and difficult to manoeuvre (my own culture and the culture of India are basically on opposite end of the tolerance to conflict scale) and if you work with one of the largest Indian consulting companies you are very likely to end up with very junior developers, high turnover and management which mostly focus on billing you the most they can.
Once you factor all that, you quickly come to a point where India doesn’t look that interesting if you don’t want to commit and open a branch there (apparently a game changer). For us, it’s awkwardly placed between countries a bit more expensive but with a far smaller cultural gap and cheaper place where we would encounter similar difficulties.
Developers from LATAM and South East Asia are much easier to work with.
The constantly smiling Americans will seem like idiots to central Europeans.
The Indians who answer yes to every question won't be trusted by the American idiots.
And so on.
Make @dang's job easier.
If there really is no discernible advantages to on-site working, the jobs are going to go to the countries where employees are paid the least.
My last couple of roles, I dealt with timezones around the world - AUS, CET, IST, across the US, etc. When working with others that aren't in the same office, there is no need for "on site".
Management and infrastructure has to cater to it. Now, face time with quarterly/etc meetings for planning and design could be useful.