Brutal that software engineering went from one of the least automatable jobs to a job that is universally agreed to be "most exposed to automation".
Was good while it lasted though.
replies(15):
I think you could find 10,000 quotes from HN alone why SDEs were immune to labor market struggles that would need a union
Oh well, good luck everyone.
That said, I’m still sceptical it isn’t simply a reflection of an overproduction of engineers and a broader economic slowdown.
Either way, there are layoff provisions with union agreements.
Other fields will get their turn once a baseline of best practices is established that the consultants can sell training for.
In the meantime, memes aside, I'm not too worried about being completely automated away.
These models are extremely unreliable when unsupervised.
It doesn't feel like that will change fundamentally with just incrementally better training.
The goal of the industry has always been self-replacement. If you can't automate at least part of what you're working on you can't grow.
... unfortunately, as with many things, this meshes badly with capitalism when the question of "how do you justify your existence to society" comes up. Hypothetically, automating software engineering could lead to the largest open-source explosion in the history of the practice by freeing up software engineers to do something else instead of toil in the database mines... But in practice, we'll probably have to get barista jobs to make ends meet instead.
For a recent example:
> Volkswagen has an agreement with German unions, IG Metall, to implement over 35,000 job cuts in Germany by 2030 in a "socially responsible" way, following marathon talks in December 2024 that avoided immediate plant closures and compulsory layoffs, according to CNBC. The deal was a "Christmas miracle" after 70 hours of negotiations, aiming to save the company billions by reducing capacity and foregoing future wage increases, according to MSN and www.volkswagen-group.com.
Unionization kind of worked for mines and factories because the company was tied to a physical plant that couldn't easily be moved. But software can move around the world in milliseconds.
AI is still used in Hollywood but nobody is proud of it. No movie director goes around quoting percentages of how many scenes were augmented by AI or how many lines in the script were written by ChatGPT.
Hell, they're even (successfully) pushing back against automated gates! [1]
[0] https://www.cnn.com/2024/10/02/business/dock-workers-strike-...
[1] https://www.npr.org/2024/10/03/nx-s1-5135597/striking-dockwo...
Similarly, a lot of non-cutting edge SW jobs will also leave the US as tooling becomes more standardized, and other nations upskill themselves to deliver similar value at less cost in exchange for USD.
Not really. If it’s overproduction, the solution is tighter standards at universities (and students exercising more discretion around which programmes they enroll in). If it’s overproduction and/or outsourcing, the solutions include labour organisation and, under this administration, immigration curbs and possibly services tariffs.
Either way, if it’s not AI the trend isn’t secular—it should eventually revert. This isn’t a story of junior coding roles being fucked, but one of an unlucky (and possibly poorly planning and misinformed) cohort.
> It doesn't feel like that will change fundamentally with just incrementally better training.
I could list several things that I thought wouldn't get better with more training and then got better with more training. I don't have any hope left that LLMs will hit a wall soon.
Also, LLMs don't need to be better programmers than you are, they only need to be good enough.
"Model collapse" is a popular idea among the people who know nothing about AI, but it doesn't seem to be happening in real world. Dataset quality estimation shows no data quality drop over time, despite the estimates of "AI contamination" trickling up over time. Some data quality estimates show weak inverse effects (dataset quality is rising over time a little?), which is a mindfuck.
The performance of frontier AI systems also keeps improving, which is entirely expected. So does price-performance. One of the most "automation-relevant" performance metrics is "ability to complete long tasks", and that shows vaguely exponential growth.
Software isn't eating the world. Software ate the world. New use cases have basically not worked out (metaverse!) or are actively harmful.
There is a lot of handwaving around the definition of intelligence in this context, of course. My definition would be actual on the job learning and reliability i don't need to second guess every time.
I might be wrong, but those 2 requirements seem not compatible with current approach/hardware limitations.
> There is an important sense, however, in which chess-playing AI turned out to be a lesser triumph than many imagined it would be. It was once supposed, perhaps not unreasonably, that in order for a computer to play chess at grandmaster level, it would have to be endowed with a high degree of general intelligence.
The same thing might happen with LLMs and software engineering: LLMs will not be considered "intelligent" and software engineering will no longer be thought of as something requiring "actual intelligence".
Yes, current models can't replace software engineers. But they are getting better at it with every release. And they don't need to be as good as actual software engineers to replace them.
Sure, you can view an LLM as a lossy compression of its dataset. But people who make the comparison are either trying to imply a fundamental deficiency, a performance ceiling, or trying to link it to information theory. And frankly, I don't see a lot of those "hardcore information theory in application to modern ML" discussions around.
The "fundamental deficiency/performance ceiling" argument I don't buy at all.
We already know that LLMs use high level abstractions to process data - very much unlike traditional compression algorithms. And we already know how to use tricks like RL to teach a model tricks that its dataset doesn't - which is where an awful lot of recent performance improvements is coming from.
Often the results will be great.
Sometimes the hallucinated details will not match the expectations.
I think this applies fundamentally to all of the LLM applications.
That's pretty much what we're experiencing currently. Two years ago code generation by LLMs was usually horrible. Now it's generally pretty good.
I'm arguing that the category of the problem matters a lot.
Chess is, compared to self-driving cars and (in my opinion) programming, very limited in its rules, the fixed board size and the lack of "fog of war".
LLMs show it plain and clear: there's no magic in human intelligence. Abstract thinking is nothing but fancy computation. It can be implemented in math and executed on a GPU.
Your stance was the widely held stance not just on hacker news but also by the leading proponents of ai when chatgpt was first launched. A lot of people thought the hallucination aspect is something that simply can't be overcome. That LLMs were nothing but glorified stochastic parrots.
Well, things have changed quite dramatically lately. AI could plateau. But the pace at which it is improving is pretty scary.
Regardless of real "intelligence" or not.. the current reality is that AI can already do quite a lot of traditional software work. This wasn't even remotely true if if you were to go 6 months back.
I have a feeling language models will be good at virtually every "sit at a desk" job in a virtually identical capacity, it's just the act of plugging an AI into these roles is non-obvious.
Like every business was impacted by the Internet equally, the early applications were just an artifact of what was an easy business decision.. e.g. it was easier to start a dotcom than to migrate a traditional corporate process.
What we will see here with AI is not the immediate replacement of jobs, but the disruption of markets with offerings that human labor simply can't out-compete.
Model collapse is something demonstrated when models are recursively trained largely or entirely on their own output. Given most training data is still generated or edited by humans or synthetic, I'm not entirely certain why one would expect to see evidence of model collapse happening right now, but to dismiss it as something that can't happen in the real world seems a bit premature.
It’s still horrible btw.
They do have the ability to fool people and exacerbate or cause mental problems.
I think the labs will be crushed by the exponent on their costs faster white-collar work will be crushed by the 5% improvement exponent.
I don't know. It seems pretty friendly to automation to me.
When was the last time you wrote assembly? When was the last time you had map memory? Think about blitting memory to a screen buffer to draw a square on a screen? Schedule processes and threads?
These are things that I routinely did as a junior engineer writing software a long time ago. Most people at that time did. For the most part, the computer does them all now. People still do them, but only when it really counts and applications are niche.
Think about how large code bases are now and how complicated software systems are. How many layers they have. Complexity on this scale was unthinkable not so long ago.
It's all possible because the computer manages much of the complexity through various forms of automation.
Expect more automation. Maybe LLMs are the vehicle that delivers it, maybe not. But more automation in software is the rule, not the exception.
Unrelated to the discussion, but I love these kinds of backup plans. I've found that most guys I talk to have one. Just a few days ago a guy was telling me that, if his beloved wife ever divorces him, then he'd move to a tropical island and become a coconut seller.
(My personal plan: find a small town in the Sonoran Desert that has a good library, dig a hole under a nice big Saguaro cactus, then live out my days reading library books in my cool and shady cave.)
Now you get can't around that this might not be the case.
You're like that beetle going extinct mating with beer bottles.
https://www.npr.org/sections/krulwich/2013/06/19/193493225/t...
The labor cost of implementing a given feature is going to dramatically drop. Jevons Paradox paradox will hopefully still mean that the labor pool will just be used to create '10x' the output (or whatever the number actually is).
If the cost of a line of code / feature / app becomes basically '0', will we still hit a limit in terms of how much software can be consumed? Or do consumers have an infinite hunger for new software? It feels like the answer has to be 'it's finite'. We have a limited attention span of (say) 8hrs/person * 8 billion.
Well yes , now we know they make kids kill themselves.
I think we've all fooled ourselves like this beetle
https://www.npr.org/sections/krulwich/2013/06/19/193493225/t...
for thousands of years up until 2020 anything that conversed with us could safely be assumed to be another sentient/intelligent being.
No we have something that does that, but is neither sentient or intelligent, just a (complex)deterministic mechanism.
We've already found that LLMs implement the very same type of abstract thinking as humans do. Even with mechanistic interpretability being in the gutters, you can probe LLMs and find some of the concepts they think in.
But, of course, denying that is much less uncomfortable than the alternative. Another one falls victim to AI effect.
Software development at its core can be done anywhere, anytime. Unionization would crank the offshoring that already happens into overdrive.
I think I have a pretty good idea of what AI can do for software engineering, because I use it for that nearly every day and I experiment with different models and IDEs.
The way that has worked for me is to make prompts very specific, to the point where the prompt itself would not be comprehensible to someone who's not in the field.
If you sat a rando with no CS background in front of Cursor, Windsurf or Claude code, what do you suppose would happen?
It seems really doubtful to me that overcoming that gap is "just more training", because it would require a qualitatively different sort of product.
And even if we came to a point where no technical knowledge of how software actually works was required, you would still need to be precise about the business logic in natural language. Now you're writing computer code in natural language that will read like legalese. At that point you've just invented a new programming language.
Now maybe you're thinking, I'll just prompt it with all my email, all my docs, everything I have for context and just ask it to please make my boss happy.
But the level of integrative intelligence, combined with specialized world knowledge required for that task is really very far away from what current models can do.
The most powerful way that I've found to conceptualize what LLMs do is that they execute routines from huge learnt banks of programs that re-combine stored textual information along common patterns.
They're cut and paste engines where the recombination rules are potentially quite complex programs learnt from data.
This view fits well with the strengths and weaknesses of LLMs - they are good at combining two well understood solutions into something new, even if vaguely described.
But they are quite bad at abstracting textual information into a more fundamental model of program and world state and reasoning at that level.
I strongly suspect this is intrinsic to their training, because doing this is simply not required to complete the vast majority of text that could realistically have ended up in training databases.
Executing a sophisticated cut&paste scheme is in some ways just too effective; the technical challenge is how do you pose a training problem to force a model to learn beyond that.
Also there are different metrics that are relevant like dollar count vs pure headcount. Cost cutting targets dollars. E.g. entry level developers are still expensive compared to other jobs.
Inevitably, people remember that the hard part of programming isn't so much the code as it is putting requirements into maintainable code that can respond to future requirements.
LLMs basically only automate the easiest part of the job today. Time will tell if they get better, but my money is on me fixing people's broken LLM generated businesses rather than being replaced by one.
Like, the grill of a car. If we know the make and year, we can add detail with each zoom by filling in from external sources
Is there a visa for that? Doesn't seem feasible unless he lives in a country that has a tropical island already.
There are two possibilities:
a) This is a large scale administrative coordination problem
b) We don't need as many software engineers.
Under (a) unionizing just adds more administrators and exacerbates the problem, under (b) unions are ineffective and just shaft new grads or if they manage to be effective, kills your employer (and then no one has a job.)
You can't just administrate away reality. The reason SWEs don't have unions is because most of us (unlike blue collar labor) are intelligent enough to understand this. I think additionally there was something to be said about factory work where the workers really were fungible and it was capital intensive, software development is almost the polar opposite where there's no capital and the value is the theory the programmers have in their head making them a lot less fungible.
Finally we do have legal tools like the GPL which do actually give us a lot of negotiating power. If you work on GPL software you can actually just tell your employer "behave or we'll take our ball and leave" if they do something stupid.
I don't think LLMs alone are going to get there. They might be a key component in a more powerful system, but they might also be a very impressive dead end.
Any abstraction you're noticing in an LLM is likely just a plagiarized one
People have been arguing this is not the case for at least hundreds of years.
Better our children never have to work because the robots do everything and they inherited some ownership of the robots.
Chess was once thought to require general intelligence. Then computing power became cheap enough that using raw compute made computers better than humans. Computers didn't play chess in a very human-like way and there were a few years where you could still beat a computer by playing to its weaknesses. Now you'll never beat a computer at chess ever again.
Similarly, many software engineers think that writing software requires general intelligence. Then computing power became cheap enough that training LLMs became possible. Sure, LLMs don't think in a very human-like way: There are some tasks that are trivial for humans and where LLMs struggle but LLMs also outcompete your average software engineer in many other tasks. It's still possible to win against an LLM in an intelligence-off by playing to its weaknesses.
It doesn't matter that computers don't have general intelligence when they use raw compute to crush you in chess. And it won't matter that computers don't have general intelligence when they use raw compute to crush you at programming.
The proof that software development requires general intelligence is on you. I think the stuff most software engineers do daily doesn't. And I think LLMs will get continously better at it.
I certainly don't feel comfortable betting my professional future on software development for the coming decades.
Its not really an intelligence thing. You could have the most intelligent agent, but if the structural incentives for that agent are for example, "build and promote your own library for X for optimal career growth.", you would still have massive fragmentation. And under the current rent-seeking capitalist framework, this is a structural issue at every level. Firefox and Chrome? Multiple competing OSes? How many JS libraries? Now sure, maybe if everyone was perfectly intelligent _and_ perfectly trusting, then you could escape this.
There is an unimaginable amount of freely accessible training data out there. There aren't for example many transcribed therapy sessions out there.
The only thing that matters about software is that it's cheap and it sort of works. Low-quality software is already common. Bugs aren't usually catastrophic in the way structural failures would be.
Software engineers are expensive compared to many other white-collar workers.
Software engineering is completely unregulated and there is no union or lobby for software engineers. The second an LLM becomes good enough to replace you, you're gone.
Many other "sit at desk" jobs have at least some tasks that can't be done on a computer.
Software engineering feels like an extremely uncertain career right now.
But I as a chess player can easily be replaced by a chess engine and I as a programmer might soon be replaceable by a next token predictor.
The only reason programmers think they can't be replaced by a next token predictor is that programmers don't work that way. But chess players don't work like a chess engine either.
I'm not saying that LLMs will positively replace all programmers next year, I'm saying that there is a lot of uncertainty and that I don't want that uncertainty in my career.
Frankly, any time I see research indicating software engineering is at a high risk of being automated, I outright dismiss it as pseudo science. It ain’t happening with current tech.
Then you said:
a) This is a large scale administrative coordination problem
Pray tell: what is it a union does other than the latter?
Or is your position that “union” is some narrowly defined, undifferentiated structural artifact of a specific legal system?
My experience aligns largely with your excellent comment.
>But the level of integrative intelligence, combined with specialized world >knowledge required for that task is really very far away from what current >models can do.
Where LLMs excel are to put out large templates of what is needed, but they are frayed at the edges. Imagine programming as a jigsaw puzzle where the pieces have to fit together. LLMs can align the broader pieces, but fail to fit them precisely.
>But they are quite bad at abstracting textual information into a more >fundamental model of program and world state and reasoning at that level.
The more fundamental model of program is a "theory" or "mental-model" which unfortunately is not codified in the training data. LLMs can put together broad outlines based on their training data, but lack the precision in modeling at a more abstract level. For example, how concurrency could impact memory access is not precisely understood by the LLM - since it lacks a theory of it.
> the technical challenge is how do you pose a training problem to force a model > to learn beyond that.
This is the main challenge - how can an LLM learn more abstract patterns. For example, in the towers of hanoi problem, can the LLM learn the recursion and what recursion means. This requires LLM to learn abstraction precisely. I suspect LLMs learn abstraction "fuzzily" but what is required is to learn abstraction "precisely". The precision or determinism is largely where there is still a huge gap.
LLM-boosters would point to the bitter lesson and say it is a matter of time before this happens, but I am a skeptic. I think the process of symbolism or abstraction is not yet understood enough to be formalized.