To give an example from a field where LLMs started causing employment worries earlier than software development: translation. Some translators made their living doing the equivalent of routine, repetitive coding tasks: translating patents, manuals, text strings for localized software, etc. Some of that work was already threatened by pre-LLM machine translation, despite its poor quality; context-aware LLMs have pretty much taken over the rest. Translators who were specialized in that type of work and too old or inflexible to move into other areas were hurt badly.
The potential demand for translation between languages has always been immense, and until the past few years only a tiny portion of that demand was being met. Now that translation is practically free, much more of that demand is being met, though not always well. Few people using an app or browser extension to translate between languages have much sense of what makes a good translation or of how translation can go bad. Professional translators who are able to apply their higher-level knowledge and language skills to facilitate intercultural communication in various ways can still make good money. But it requires a mindset change that can be difficult.
1. No one cares about quality. Even in fields you'd expect to require the 'human touch' (e.g. novel translation), publishers are replacing translators with AI. It doesn't matter if you have higher-level knowledge or skills if the company gains more from cutting your contract than it loses in sales.
2. Translation jobs have been replaced with jobs proofreading machine translations, which pays peanuts (since AI is 'doing most of the work') but in fact takes almost as much effort as translating from scratch (since AI is often wrong in very subtle ways). The comparison to PR reviews makes itself.
After all, this has been Apple strategy since the 80's, and, even though there were some up's and down's, overall it's a success.
Maybe, but it probably requires a very strong and opinionated leader to pull off. The conventional wisdom in American business leadership seems to be to pursue the lowest level of quality you can get away with, and focus on cutting costs. And you'll have to fight that every second.
I don't think that's true at the individual-contributor level (pursing quality is very motivating), but they people who move up are the ones who sound "smart" by aping conventional wisdom.
> After all, this has been Apple strategy since the 80's, and, even though there were some up's and down's, overall it's a success.
I might give you that "since the late 90s," but there have been significant periods where that wasn't true (e.g. the early mid-90s Mac OS was buggy and had poor foundations).
A) how old the product is: Twitter during its first 5 years probaby had more work to do compared to Twitter after 15 years. I suspect that is why they were able to get rid of so many developers.
B) The industry: many b2c / ecommerce businesses are straightforward and don't have an endless need for new features. This is different than more deep tech companies
I’ve built several of such tools where I work. We don’t even have a dev team, it’s just IT Ops, and all of what I’ve built is effectively “done” software unless the business changes.
I suspect there’s a lot of that out there in the world.
On a macro level, if you were in a rising economic tide, you would still be hiring, and turning those productivity gains into more business.
I wonder what the parallels are to past automations. When part producing companies moved from manual mills to CNC mills, did they fire a bunch of people or did they make more parts?
- AI tools are expensive so until the increased productivity translates to increased revenue we need to make room in the budget
- We expect the bottlenecks in our org to move from writing code to something else (PM or design or something) so we're cutting SWEs in anticipation of needing to move that budget elsewhere.
- We anticipate the skillsets needed by developers in the AI world to be fundamentally different from what they are now that it's cheaper to just lay people off, run as lean as possible, and rehire people with the skills we want in a year or two than it is to try and retrain.
I don't necessarily agree with those arguments (especially the last one), but I think they're somewhat valid arguments
> rehire people with the skills we want in a year or two than it is to try and retrain.
before that future comes your company might become obsolete already, because you have lost your market share to new entrants
> We expect the bottlenecks in our org to move from writing code to something else
I would love to tell them, hey lets leverage current momentum and build, when those times come, we offer existing people with accumulated knowledge to retrain to a new type of work, if they think they're not good fit, they can leave, if they're willing, give them a chance, invest in people, make them feel safe and earn trust and loyalty from them
> AI tools are expensive so until the increased productivity translates to increased revenue we need to make room in the budget
1. Its not that expensive: 150$/seat/month -> 5 lunches? or maybe squeeze it from Sales personnel traveling with Business class?
2. By the time increased productivity is realized by others, company who resisted could be so far behind, that they won't be able to afford hiring engineers with those skillsets, if they think 150$ is expensive now, I am sure they will say "What??? 350k$ for this engineer?, no way, I will instead hire contractors"
However AI definitely is capable of lower end software tasks and really well trodden ground, especially when managed by a developer, so perhaps what we will see is a bigger gap in pay and talent not too different from the off-shore vs on-shore market comparisons.
The key for me though for me is that, if AI makes your employees 20% more valuable, that will either get priced into their wage or captured by the business, but it still doesn't replace the need for good talent (software engineer, agent handler, whatever it will get called).
Jobs where a machinist is in charge of large chunks of the process are rarer. Large shop will have one person setting up many machines to maximize throughput.
If it is truly because of AI, then it's still a losing strategy long term in my opinion.
AI needs documentation, automation, integration tests... It works very well for remote first company, but not for in-face informal grinding approach.
Just year ago, client told me to delete integration tests, because "they ran too long"!
Why are you surprised customers don't like spending money on the items that don't add business value. Add to that QA, documentation, security audits, etc.
They want to ship stuff that brings in customers and revenue day one, everything else is a cost.
They absolutely do add value / prevent loss, but you need some understanding in order to see that. Not seeing it is a marker of not understanding.
Not to the non-technical bean counters. When they allocate money they want to see you prove how that extra money translates to an immediate ROI, and it's difficult to prove that in an Excel sheet exactly what the ROI will be without making stuff up on vibes and feels.
Like at one German company i was at ~15 years ago, all the devs wanted a second 19" monitor on our workstations for increased productivity, and the bean counters wouldn't approve that because they wanted proof of how that expense across hundreds of people will increase our productivity and by how much %, to see if that would offset the cost.
This is how these people think. If you don't bring hard numbers on how much their "line will go up", they won't give you money.
I know this is difficult to understand from the PoV of SV Americans where gazillions of dollars just fall from the sky at their tech companies.
It might not be about bringing more revenues but retaining market share.
If, and it's a big if, AI models really boost productivity by an order of magnitude (I personally, while being skeptical a year or two ago, am leaning towards this idea) then engineers have a chance to realize their ideas, improve current system design patterns and build successful companies, which will inevitably (hopefully) require hiring personnel to keep competing, bringing entire software engineering market to a newly balanced state.
Once you get to a certain size company, this means a lot of bloat. Heck, I've seen small(ish) companies that had as many managers and administrators as ICs.
But You're not wrong, I'm just pointing out how an org that has 4k people can lay off a few hundred with modest impact of the financials (though extensive impact on morale).
It’s refreshing to see the same sentiment from so many other people independently here.
Doesn't exclude the possibility of short term distribution, though.
That's one of the reasons why I am terrified, because it can lead to burn out, and I personally don't like to babysit bunch of agents, because the output doesn't feel "mine", when its not "mine" I don't feel ownership.
And I am deliberately hitting the brake from time to time not to increase expectations, because I feel like driving someone else's car while not understanding fully how they tuned their car (even though I did those tunings by prompting)
It's not going to be written exactly like you would do it, but that's ok - because you care about the results of the solution and not its precise implementation. At some point you have to make an engineering decision whether to write it yourself for critical bits or allow the agent/junior to get a good enough result.
You're reviewing the code and hand editing anyway, right? You understand the specs even if your agent/junior doesn't, so you can take credit even if you didn't physically write the code. It's the same thing.
Yes, yes!
And this is problem for me, because of the pace, my brain muscles are not developing enough compared to when I was doing those things myself.
before, I was changing my mind while implementing the code, because I see more things while typing, and digging deeper, but now, because juniors are doing things they don't offer me a refactoring or improvements while typing the code quickly, because they obey my command instead of having "aha" moment to suggest better ways
The engineer who worked with you took ownership of the code! Have you forgotten this?
If you look at my post history I'm essentially saying the same stuff lol.