Why is everyone trying to replace Software Engineers?(toddle.dev)
toddle.dev
Why is everyone trying to replace Software Engineers?
https://toddle.dev/blog/why-is-everyone-trying-to-replace-software-engineers
144 comments
Good thing everybody hates Salesforce.
I dislike the company, I like the product - I have built several small apps on the platform and nothing has ever been "no code" as they like to advertise, but hot damn was I able to throw together something useful for the business in less than a day and have people using it as quickly. As an engineer I find it incredibly valuable for making these low-to-medium value LOB apps that don't justify the man-hours to build, deploy, and fight tech debt for a full-stack web application, at least when factoring in the tradeoff for license costs.
It's a valuable product. Salesforce knows this, and prices accordingly, which is why everybody hates salesforce but still pays them.
but still uses it
I agree with this. I think coder is even worse.
Software engineer or Software developer are much better terms.
Software engineer or Software developer are much better terms.
[deleted]
[deleted]
> Your job was never to write code, it is to solve problems for your users. They are why we have a job. You need to talk with the users, empathize with them, understand their problems and feel their pains. This is much too important to be left exclusively in the hands of product managers and designers. You are the problem solver, so you need to fully understand the problem.
Adding to this point, LLMs won't fully understand the problem, so they're simply incapable of developing complete solutions. I've had a lot of success with these tools in developing functions, but at that point I've already architected and designed the solution. Even so, it saves time. These should be regarded as developer productivity tools, not developer replacement tools.
Adding to this point, LLMs won't fully understand the problem, so they're simply incapable of developing complete solutions. I've had a lot of success with these tools in developing functions, but at that point I've already architected and designed the solution. Even so, it saves time. These should be regarded as developer productivity tools, not developer replacement tools.
Developer productivity tools are developer replacement tools. If the current paradigm is: principal/senior devs design system, implemented by more junior devs, and LLM tools enable the seniors to produce lots of code, then the juniors are the ones getting replaced. The next step up the stack is enabling the PMs and business people to design (and implement) the system. There is no reason to think LLM based tools are in principle incapable of that.
"Software development" will still exist, but if productivity tools become so capable that your PM can crank out a dozen variations and iterate on them solo, that will lead to developer replacement.
"Software development" will still exist, but if productivity tools become so capable that your PM can crank out a dozen variations and iterate on them solo, that will lead to developer replacement.
IDK, I've been developing software for 40 years now and have been through several of these "developer replacement" hype cycles. Every single time what ended up happening was even more developers were required. I see this as being the same, at least for the next few years. I do believe that the ultimate end point is quite different - developers will be replaced - but that's several years away and will require major changes to the approach currently being used for software development.
Yes this is honestly the silliest part of the whole conversation.
I am currently employing 6 software engineers in my company. If from tomorrow they were 10x more productive then I would employ 6 software engineers because that is the budget I have.
Their increased productivity would lead to a faster growth and I would then have budget for more.
If you increase the productivity of software engineers then people will hire more software engineers not fewer.
I am currently employing 6 software engineers in my company. If from tomorrow they were 10x more productive then I would employ 6 software engineers because that is the budget I have.
Their increased productivity would lead to a faster growth and I would then have budget for more.
If you increase the productivity of software engineers then people will hire more software engineers not fewer.
I've been through this cycle as well, but I don't think this works the same way. I mean the only way it would work the same is if AI never reaches its promises, and I don't mean AGI, but never reaches the level of the thinking of a software developer. Then yes, no replacement. But do you really think AI will never get smart enough? Because the second it gets, whoever works on that level flies out the window. A therapeut needs his hands to work, so a very complex hardware interface with a long way ahead to reproduce, but a developer's work happens directly in the computer, zero hardware replacement costs.
Do I see it happening in the next five years? No.
Ten years? Maybe. But our workflow will have changed to accommodate AI being the primary code generator.
Twenty years? The new workflow from ten years will be standard and AI will be able to competently do all code generation.
Will AI replace software developers? Yes, and many of those developers will have transitioned to new work driving the new workflow.
By the time AI is ready to replace the developers driving the new workflow, then there's very little at that point that humans can do, and AI can't, without assistance from humans. In other words, replacing software developers isn't our biggest problem because by the time AI can do that, nearly all humans are replaceable.
Ten years? Maybe. But our workflow will have changed to accommodate AI being the primary code generator.
Twenty years? The new workflow from ten years will be standard and AI will be able to competently do all code generation.
Will AI replace software developers? Yes, and many of those developers will have transitioned to new work driving the new workflow.
By the time AI is ready to replace the developers driving the new workflow, then there's very little at that point that humans can do, and AI can't, without assistance from humans. In other words, replacing software developers isn't our biggest problem because by the time AI can do that, nearly all humans are replaceable.
What do you mean by the AI "reaching a developers level of thinking" and if "it will get smart enough"? Because it doesn't do any thinking it predicts the statistically most likely token depending on the input.
I don't care about either wording. The moment when the form it generates based on the written requirements passes the QA.
I've honestly never had that success. LLMs for me more often get in the way than actually help anything. It may be that it's because I deal mostly in very large code bases with their own nuances.
Works much better on greenfield projects. Brownfield requires the LLM to have ingested your codebase and all the libraries you're using. That's why tools such as DeepSeek are exciting because that potentially opens up the door to much better brownfield development - which is where the real value lies!
Counter point though- what if it was trained on your specific code base? Wouldn't it be able to then help with those given nuances?
The code base I have I would love to be able to just give some AI free reign and learn the structure since a lot of it is fairly repetitive; I know it would be so easy to say "hey add X just like Y" and it would be able to do it easily.
The code base I have I would love to be able to just give some AI free reign and learn the structure since a lot of it is fairly repetitive; I know it would be so easy to say "hey add X just like Y" and it would be able to do it easily.
The rare times where I have no good idea what to do, it is faster to code with an LLM. The rest of the time, when I know just what I want, it takes longer for me to formulate it, query the LLM and discuss and validate its output.
My more experienced/senior colleagues all say roughly the same. It’s great help for our juniors though. They learn a lot and are more capable on their own with the AI assistance.
It’s improving all the time though, so I’m not writing it off at all. I am developing an evaluation suite so I can keep watching the progress in a systematic way..
My more experienced/senior colleagues all say roughly the same. It’s great help for our juniors though. They learn a lot and are more capable on their own with the AI assistance.
It’s improving all the time though, so I’m not writing it off at all. I am developing an evaluation suite so I can keep watching the progress in a systematic way..
> I am developing an evaluation suite so I can keep watching the progress in a systematic way..
Sounds like something that should be published on github
Sounds like something that should be published on github
Open benchmarks are vulnerable to saturation. I think benchmarks should have an embargo periodic, until which only 3% of the question-answer pairs is released, with an explicit warning not to use it 3 months after being released.
I think there are types of problems that AI will be great at solving. If you can pass in a whole codebase then we might have LLMs that can suggest refactoring etc to improve code quality.
Code mods like upgrading from python 2 -> 3 could also become possible.
Code mods like upgrading from python 2 -> 3 could also become possible.
Exactly!
Code is just a medium used to build software, the real value comes from analyzing problems and finding solutions.
Code is just a medium used to build software, the real value comes from analyzing problems and finding solutions.
They aren't trying to replace us in earnest, yet. They are using the threat to beat down wages, and to more generally tilt the power balance further in favor of ~capital~ employers.
"Replacement" is smoke and mirrors at this point; anyone who seriously tries it will quickly fail, with today's technology.
"Replacement" is smoke and mirrors at this point; anyone who seriously tries it will quickly fail, with today's technology.
It's very similar to offshoring.
We currently have an offshore dev team that is frankly just a money pit. Still, the C levels keep trying to make us use them and it's never been successful. Our offshore devs are simply incompetent because we hired for cheap and not quality.
We currently have an offshore dev team that is frankly just a money pit. Still, the C levels keep trying to make us use them and it's never been successful. Our offshore devs are simply incompetent because we hired for cheap and not quality.
I've been at a company that did hire overseas for competence. It was still very difficult, primarily because of the communication bottleneck imposed by timezone differences. At times, we had significant parts of these remote teams move to the US, and they were great contributors once they were in the same timezone. Low latency communication is a big deal.
Teams across communication divides like this must own their own piece of the system with a small, well-designed, well-documented interface. Conway's Law is in extreme force in these situations and must be respected if there is to be meaningful success.
I think you're right that LLMs have similar issues. There are no timezone issues, but communication is still very difficult on anything that isn't completely concrete. I think this is part of why they can be good on 1-10 line snippets, but get much worse if you try to get to dozens or hundreds of lines of code that aren't filled with boilerplate and redundancies. Taking that drudgery off our hands (where we can't eliminate it) is a real productivity win, but it's a far cry from replacing us.
Teams across communication divides like this must own their own piece of the system with a small, well-designed, well-documented interface. Conway's Law is in extreme force in these situations and must be respected if there is to be meaningful success.
I think you're right that LLMs have similar issues. There are no timezone issues, but communication is still very difficult on anything that isn't completely concrete. I think this is part of why they can be good on 1-10 line snippets, but get much worse if you try to get to dozens or hundreds of lines of code that aren't filled with boilerplate and redundancies. Taking that drudgery off our hands (where we can't eliminate it) is a real productivity win, but it's a far cry from replacing us.
> Scientist: Hurrah! We have created an algorithm that can mimic human speech!
> CEO: Fantastic! I've already fired all of the doctors and nurses, how soon can it start doing surgeries?
> Scientist: ...
> CEO: Fantastic! I've already fired all of the doctors and nurses, how soon can it start doing surgeries?
> Scientist: ...
I was part of a group people that tended towards artsy (and definitely not rationalist). This was when everyone had an idea for a new app, and I kept getting people trying to get me to work for equity. They seemed to have these same kinds of unrealistic expectations. I eventually came to the conclusion that they saw software as like painting. It seems to take about 8 - 24 hrs to create a work of art (assuming the idea is complete and you are working within your skill level), so their mental price and timeline was something similar.
A better metaphor for software is like writing a book. Everyone sees writing a book as borderline undoable, and the expectation is that it takes months and months. I think that software and writing have a lot in common (including lots of text, and even the verb used), and that explaining ourselves as book-writers would help set better expectations.
A better metaphor for software is like writing a book. Everyone sees writing a book as borderline undoable, and the expectation is that it takes months and months. I think that software and writing have a lot in common (including lots of text, and even the verb used), and that explaining ourselves as book-writers would help set better expectations.
Obviously this depends on _where_ you're working, but personally, I like the plumber metaphor -- nobody notices the plumber until things aren't working properly and by then you're in deep shit.
Software is working great: Everything's working great, why do we pay you again!?
Software is broken: Everything's broken, why do we pay you!?
Software is working great: Everything's working great, why do we pay you again!?
Software is broken: Everything's broken, why do we pay you!?
> Everyone sees writing a book as borderline undoable
I would think the opposite. Surely everyone thinks they could write a book?
I would think the opposite. Surely everyone thinks they could write a book?
One word: money.
They (CEOs and executives, shareholders, etc) don't like how much it costs to make software. They think software engineers make too much money.
You (a human) are always a cost they will try to reduce.
They (CEOs and executives, shareholders, etc) don't like how much it costs to make software. They think software engineers make too much money.
You (a human) are always a cost they will try to reduce.
Unfortunately I think this is exactly true. It essentially means that many executives are completely incompetent.
You product teams are where your company's value is generated. It is kinda scary to think that so many executives don't understand that.
You product teams are where your company's value is generated. It is kinda scary to think that so many executives don't understand that.
Unfortunately it seems like a large subset of execs can only think one quarter at a time.
They think software engineers make too much money and answer everything with it depends.
Yeah, this is pretty much the answer when it comes to jobs. I mean why do people do their own oil changes, instead of leaving the job to their mechanic? Why would anyone try to replace their mechanic? You might argue for trust, quality, or time reasons, but arguably only so because of how they relate to costs.
The same reason all companies try to reduce labor: cut costs, better returns for shareholders.
There's nothing special about SWEs vs any other class of worker. If they can be replaced or eliminated, they will be, just like any other worker.
There's nothing special about SWEs vs any other class of worker. If they can be replaced or eliminated, they will be, just like any other worker.
This is the sad truth. We like to think we're special but we're not. I'd argue a paramedic is more special. Those people save lives and get paid like shit compared to us.
I wish I realized what financial independence is earlier, even making good money I'm still poor/negative net worth due to my dumb decisions earlier on. Trying to be better this time around then I won't be so concerned/can just pivot.
You know what job is safer than a SWE? A barber.
Think about it -- what's the ROI on creating a robot so sophisticated that it can handle all the intricacies and special customer requests of hair cutting/styling? You're unlikely to save any money over hiring humans.
Think about it -- what's the ROI on creating a robot so sophisticated that it can handle all the intricacies and special customer requests of hair cutting/styling? You're unlikely to save any money over hiring humans.
Because:
1) We're expensive (at least for Poland, I can aim for ~6-8k PLN monthly after few years of experience. Other, even civil/mech engineers will have around 4-6k monthly with similar experience) [edit: and minimal wage is 3.5k after taxes]
2) It appears to be replaceable (you can replace us with LLMs to an extent, you can't do that with other jobs)
1) We're expensive (at least for Poland, I can aim for ~6-8k PLN monthly after few years of experience. Other, even civil/mech engineers will have around 4-6k monthly with similar experience) [edit: and minimal wage is 3.5k after taxes]
2) It appears to be replaceable (you can replace us with LLMs to an extent, you can't do that with other jobs)
This.
It's not software engineers per se. It's any labor component that is expensive and "automate"-able. Companies are always trying to optimize labor costs. The theoretical Holy Grail is a company that requires 0 labor input where all profits accrue to the owner of the business.
That's just business 101.
I'd anticipate a concerted effort to make LLMs better and batter at software development tasks until you only need the top 0.5% of developers and maybe a few technicians to support them. That's how you juice profitability.
It's not software engineers per se. It's any labor component that is expensive and "automate"-able. Companies are always trying to optimize labor costs. The theoretical Holy Grail is a company that requires 0 labor input where all profits accrue to the owner of the business.
That's just business 101.
I'd anticipate a concerted effort to make LLMs better and batter at software development tasks until you only need the top 0.5% of developers and maybe a few technicians to support them. That's how you juice profitability.
But the high salaries are just a question of supply and demand, because for 20 or so years there was always a need for more programmers (well, at least senior ones). Reduced demand should naturally be reflected by reduced salaries (or benefits).
> 1) We're expensive
I reckon we're cheap. Even with the current wages software engineers have, the margins in software companies/industry is large.
I reckon we're cheap. Even with the current wages software engineers have, the margins in software companies/industry is large.
the margins in software companies/industry is large.
Margins, are never large enough for a certain class of owners. That's the unfortunate reality. No one at an average board meeting is gonna say, "Hey guys, let's stay at this 40% margin level instead of going to 60%!"
Margins, are never large enough for a certain class of owners. That's the unfortunate reality. No one at an average board meeting is gonna say, "Hey guys, let's stay at this 40% margin level instead of going to 60%!"
"Not all programming problems can be solved with pattern matching"
Says who? How do you know if solving programming problems is not just advanced pattern matching?
The fact that we find most (if not all) of our solutions on SO or talking to colleagues points towards the pattern matching hypothesis quite strongly.
To be clear: I am talking about the programming aspect of the job only, not the other important things (talking to customers/product managers, crafting solutions, etc.)
Says who? How do you know if solving programming problems is not just advanced pattern matching?
The fact that we find most (if not all) of our solutions on SO or talking to colleagues points towards the pattern matching hypothesis quite strongly.
To be clear: I am talking about the programming aspect of the job only, not the other important things (talking to customers/product managers, crafting solutions, etc.)
AI is an existential threat to tech companies not software engineers.
In many domains, the scope and complexity of software systems goes beyond the ability of a single software engineer to manage. A coordination layer becomes necessary when the number of engineers required goes beyond a threshold (say 5 or so). When the development effort must be coordinated over extended periods (say several months or years), mechanisms to raise capital and manage risk become necessary. These functions are why companies exist.
Consider that a massive increase in software engineer productivity will make coordination unnecessary for many kinds of software. In the market that opens up, companies with expensive executives, middle management and coordination inefficiencies will not be competitive. Smaller shops with a solo engineer or a team of less than 5 will outcompete larger players because their costs will be significantly lower. Massive one-size-fits-all products will be harder to justify when a small dev shop can quickly build or customise software for the unique requirements of a business or niche.
Before the CEOs stop needing engineers, engineers will stop needing CEOs and managers to coordinate their efforts and raise capital.
In many domains, the scope and complexity of software systems goes beyond the ability of a single software engineer to manage. A coordination layer becomes necessary when the number of engineers required goes beyond a threshold (say 5 or so). When the development effort must be coordinated over extended periods (say several months or years), mechanisms to raise capital and manage risk become necessary. These functions are why companies exist.
Consider that a massive increase in software engineer productivity will make coordination unnecessary for many kinds of software. In the market that opens up, companies with expensive executives, middle management and coordination inefficiencies will not be competitive. Smaller shops with a solo engineer or a team of less than 5 will outcompete larger players because their costs will be significantly lower. Massive one-size-fits-all products will be harder to justify when a small dev shop can quickly build or customise software for the unique requirements of a business or niche.
Before the CEOs stop needing engineers, engineers will stop needing CEOs and managers to coordinate their efforts and raise capital.
It's a threat to many workers imo, just like autonomous machine were to the workers during the industry revolution, and later with the factories moving to China. Many people suffered from unemployment and the solution so far have been solved by creating new needs and new jobs, as well as policies such as social security.
But with the externalization of intelectual work (which happen without IA, for ex. India tech) I wonder if such solution is possible.
But with the externalization of intelectual work (which happen without IA, for ex. India tech) I wonder if such solution is possible.
Software developers are basically the only thing standing between the morons and profit at any cost to society, because some of us don't feel like playing that game and they couldn't do it without us if their life depended on it.
I realize they think they they finally can do it by themselves, or rather by hooking up a bunch of fresh bootcamp devs with AI; and I look forward to watching them crash, burn and come back begging for help.
I realize they think they they finally can do it by themselves, or rather by hooking up a bunch of fresh bootcamp devs with AI; and I look forward to watching them crash, burn and come back begging for help.
I don't think software engineers are any more resilient to the profit incentives than the rest of us.
More resilient than Elon, Zucker & co for sure; more human to begin with.
Both of them started as software developers.
They won’t come begging for help. They _want_ the crash and burn.
Where is the profit?
The less government services, the more dependent people are on having a job to earn money to survive. The less leverage people have to demand higher wages.
It’s the same battle since before the US was even founded. They want slavery, or as close it as they can get.
It’s the same battle since before the US was even founded. They want slavery, or as close it as they can get.
There we agree, slavery and total control was always the goal for these people.
this comment
I'm a software developer. I've been trying to replace myself with code since I started writing code in the early 80s.
Because the rich would rather spend money on things they can own than spending on people. If I spend a million dollars on an AI cluster to replicate my programmer, it'll never need another vacation, never complain about conditions, never argue, never balk at unethical requests, etc.
Bean counters don't like specialists, because they can't evaluate the value of specialists without having that specialist knowledge themselves...
Disagreed, competent businesses analyze this stuff at least a high level. Its why many of us spend so much time classifying various projects and efforts into capital expenditures. Large corps understand the value of a lawyer these days, who are highly specialized, because they can see the sort of returns it gets them. But at the end of the day they need to see why any effort is either earning them more money or costing them less money.
I've been predicting for some time that if AI makes it much easier and faster to write software, this will increase software engineer employment.
It will grow the sector and massively inflate the combinatorial explosion of system X system X system. Programmers will use AI as a tool in their tool box -- I already do for boilerplate and tests and explaining code -- and they'll use it to write ever more software to work with ever more systems.
What it may do though is cut the bottom off the field. Very junior programming jobs could vanish, creating more of a learning cliff to really get into it. This is happening in every discipline and has been for a while. It's a real problem for our traditional method of school followed by entry level job. I think the future's going to be some kind of school integrated with apprenticeship followed by internship followed by a real job. Unfortunately that may suck in a lot of ways. Fields that are like that require too much 'paying your dues.'
It will grow the sector and massively inflate the combinatorial explosion of system X system X system. Programmers will use AI as a tool in their tool box -- I already do for boilerplate and tests and explaining code -- and they'll use it to write ever more software to work with ever more systems.
What it may do though is cut the bottom off the field. Very junior programming jobs could vanish, creating more of a learning cliff to really get into it. This is happening in every discipline and has been for a while. It's a real problem for our traditional method of school followed by entry level job. I think the future's going to be some kind of school integrated with apprenticeship followed by internship followed by a real job. Unfortunately that may suck in a lot of ways. Fields that are like that require too much 'paying your dues.'
I think the more realistic long term victims will be implementation specialists and business analysts. The middlemen who sit between product (developer) and customer.
Giving your product the ability to talk & work directly with the customer seems to me a much more valuable activity than covering all the edge cases that would arise during the development of such a solution with an LLM.
Remember, everything is a function [0] and LLMs support calling them. The trick is having the skill and domain expertise to establish bounded contexts and prompts that align with realistic product use cases and transition between them cleanly.
I know there is a lot of doubt that users would enjoy using a chat interface, but I strongly believe it would be popular as long as it actually works. If it's not well designed and the GUI tools are faster even for a novice, you will have wasted a lot of time/money for nothing.
[0] https://youtu.be/zHU1xH6Ogs4
Giving your product the ability to talk & work directly with the customer seems to me a much more valuable activity than covering all the edge cases that would arise during the development of such a solution with an LLM.
Remember, everything is a function [0] and LLMs support calling them. The trick is having the skill and domain expertise to establish bounded contexts and prompts that align with realistic product use cases and transition between them cleanly.
I know there is a lot of doubt that users would enjoy using a chat interface, but I strongly believe it would be popular as long as it actually works. If it's not well designed and the GUI tools are faster even for a novice, you will have wasted a lot of time/money for nothing.
[0] https://youtu.be/zHU1xH6Ogs4
I have my own side projects, which I hoped I could make much faster progress with LLMs. Didn't work... Actually, it decreased progress. LLMs don't code themselves and explaining things to them takes an enormous amount of time and they misunderstand things so much. How could somebody think a statistical parrot can replace any kind of knowledge work?
My view is that Ai companies saw there was a huge volume of code online and decided coding was a text generation problem and easy to replace.
I don't buy it. I also don't think it'll replace writers or artists. Just the low brow, chum bucket stuff which in programming terms is a todo app or web form.
I don't buy it. I also don't think it'll replace writers or artists. Just the low brow, chum bucket stuff which in programming terms is a todo app or web form.
Just the low brow, chum bucket stuff
I think, as software devs, we sometimes kid ourselves with respect to how many of us are working on low brow, chum bucket stuff.
Most of us are not working on GPU based real time physics engines. What most of us do is, well, not rocket science. Even people working in "hard" areas are not really doing the "hard" work. Most game engine developers are using libraries, they aren't developing shaders. Most AI developers are, in actuality, TF or PyTorch monkeys, not real AI experts.
I think devs who move to writing code in areas where problems have not yet been solved will still be necessary. But yeah, not sure devs pushing out another web app will be all that necessary over the next decade.
I think, as software devs, we sometimes kid ourselves with respect to how many of us are working on low brow, chum bucket stuff.
Most of us are not working on GPU based real time physics engines. What most of us do is, well, not rocket science. Even people working in "hard" areas are not really doing the "hard" work. Most game engine developers are using libraries, they aren't developing shaders. Most AI developers are, in actuality, TF or PyTorch monkeys, not real AI experts.
I think devs who move to writing code in areas where problems have not yet been solved will still be necessary. But yeah, not sure devs pushing out another web app will be all that necessary over the next decade.
While I agree we're not all implementing physics engines, there is a spectrum of complexity that is both business and technical between a todo app and a banking system.
Developer brains are still much more efficient at holding the different layers of context involved to build systems.
Developer brains are still much more efficient at holding the different layers of context involved to build systems.
You need strong guys to move things around because you don't have a pneumatic crane.
Now you have pneumatic crane, you can move stacks and stacks of things around with ease. You need less strong guys around and instead there is a new need for fewer people that are well-trained on how to operate this pneumatic crane safely. You'll get more work done with less people.
That's what's happening with software engineering and LLM copilots; it's an industrialization of coding. You don't need 20 engineers to get that product out. You need a few that are really good operators of the machinery. Adept at prompting and reviewing code instead of writing code.
Now you have pneumatic crane, you can move stacks and stacks of things around with ease. You need less strong guys around and instead there is a new need for fewer people that are well-trained on how to operate this pneumatic crane safely. You'll get more work done with less people.
That's what's happening with software engineering and LLM copilots; it's an industrialization of coding. You don't need 20 engineers to get that product out. You need a few that are really good operators of the machinery. Adept at prompting and reviewing code instead of writing code.
If there's one thing employers hate more than unskilled labor, it's skilled labor.
Oh, now instead of ten unskilled laborers carrying shit, each being paid $N, you can have one crane operator getting paid $5N? Wait, why can't we pay him $N? What do you mean, if he fucks up it costs us millions? What do you mean, his skill or lack thereof can double or halve the time it takes to move shit around? Ok, what if we pay him $1.1N?
Oh, now instead of ten unskilled laborers carrying shit, each being paid $N, you can have one crane operator getting paid $5N? Wait, why can't we pay him $N? What do you mean, if he fucks up it costs us millions? What do you mean, his skill or lack thereof can double or halve the time it takes to move shit around? Ok, what if we pay him $1.1N?
> it's an industrialization of coding
That's a fantastic insight. There's a popular metaphor comparing software developers to blacksmiths, emphasizing the craft and trade aspects of the profession. Historically, blacksmiths were largely automated out of existence, replaced by highly skilled metallurgists and industrial automation engineers, albeit in much smaller numbers. As we look toward the future, we must consider what the equivalents for software development might be.
That's a fantastic insight. There's a popular metaphor comparing software developers to blacksmiths, emphasizing the craft and trade aspects of the profession. Historically, blacksmiths were largely automated out of existence, replaced by highly skilled metallurgists and industrial automation engineers, albeit in much smaller numbers. As we look toward the future, we must consider what the equivalents for software development might be.
Yes, I think the blacksmith metaphor is also an excellent one because a single die stamping machine can produce thousands (if not tens or hundreds of thousands) of times the same output as a single blacksmith.
You still need people, but you need them to: 1) operate and maintain the machine, 2) check for quality, 3) do some fine, detailed work, 4) do the things that the machine is not good at. The skillsets are just different now and you need less people while producing significantly more output.
Whereas a 4'10", 100lb woman probably wouldn't have been a productive blacksmith, she can be adept at building fine metal parts with the industrial tools.
You still need people, but you need them to: 1) operate and maintain the machine, 2) check for quality, 3) do some fine, detailed work, 4) do the things that the machine is not good at. The skillsets are just different now and you need less people while producing significantly more output.
Whereas a 4'10", 100lb woman probably wouldn't have been a productive blacksmith, she can be adept at building fine metal parts with the industrial tools.
The problem with this analogy is that the hard part of writing software isn’t about bulk jobs that are easily specified with cut and dried success criteria. It’s about designing and implementing things where many tiny details matter and are connected to real world outcomes in ways that can not be fully deduced from the symbols present in code. If you get these things subtly wrong than programming is net negative because you now have more mess to wade through than if you were starting from scratch. LLMs in the hands of weak engineers will actually be net negative. I do think jobs will be lost because there are currently a lot of net negative programmers out there simply because knowing syntax and algorithms has historically been enough to get a lot of jobs even if higher level systemic thinking and communication is lacking. That will cause a reduction in overall numbers, but I would argue that was already an existing inefficiency and it will be interesting to see how much it impacts the big picture as ultimately we still need people to understand and debug all the biz critical code out there.
> LLMs in the hands of weak engineers...
If you have a press that can produce 600 copies of some die and you are hiring a blacksmith, you're probably not going to get good results.
I'm not "thinking about it wrong", I'm saying that I don't like the analogy. Of course all analogies are imperfect, and I get that LLMs greatly accelerate the production of code, but here's the gap: code is not the product. Code is the instruction for the actual machines, and crucially, code is already repeatable and replicable.
In the software world a blacksmith is analogous someone crunching numbers in a spreadsheet. Programmers (combined with hardware engineers) are the ones that are creating the hydraulic presses. LLMs are analogous to CAD, a better tool-building tool to be sure, but at the end of the day if you're stamping out code in a way that an LLM can do it reliably, then you already have a problem that was automatable without an LLM, which code can already do.
In the software world a blacksmith is analogous someone crunching numbers in a spreadsheet. Programmers (combined with hardware engineers) are the ones that are creating the hydraulic presses. LLMs are analogous to CAD, a better tool-building tool to be sure, but at the end of the day if you're stamping out code in a way that an LLM can do it reliably, then you already have a problem that was automatable without an LLM, which code can already do.
>Adept at prompting and reviewing code instead of writing code.
Don't you need to write your own fair share of code (especially bad code) to judge what gets shipped? LLMs solve the problem of "producing code," but I don't think it necessary follows that LLMs solve the more important problem of "delivering value."
If you're Organization X and are in partnership with Organization Y to produce an integrated solution, an LLM might know how to call some bespoke API between the orgs. But you probably need to have skilled humans to know those APIs' inevitable weirdnesses: unintentional rate limits, resource-constraint edge cases, race conditions, etc.
Don't you need to write your own fair share of code (especially bad code) to judge what gets shipped? LLMs solve the problem of "producing code," but I don't think it necessary follows that LLMs solve the more important problem of "delivering value."
If you're Organization X and are in partnership with Organization Y to produce an integrated solution, an LLM might know how to call some bespoke API between the orgs. But you probably need to have skilled humans to know those APIs' inevitable weirdnesses: unintentional rate limits, resource-constraint edge cases, race conditions, etc.
> Don't you need to write your own fair share of code
Do you need to be good at making films to be a good critic of films? (Roger Ebert)
Do you need to be a great chef to be a Michelin reviewer or food critic?
Do you need to be a great singer to be a good judge of musical talent? (Simon Cowell)
I think you can tell if some output is "good" without being expert at the doing part. You need to understand the domain, the inputs, the outputs, the range, but not necessarily be expert at the doing part.
In fact, many, many more of us can tell "this book is good", but relatively few of us could write a very good novel. We have a sense that "this show or movie is entertaining", but few of us could produce one!
One of the teams I worked with, our support engineer was extremely adept at reading code. He would trace defect reports to the lines of code and write excellent tickets that deeply understood the root cause of the error because he had a good conceptual model of the design and he was skilled at reading code. However, when it came to fixing the error, he had no clue!
Good point, but maybe a little incomplete. Can you read a contract and tell whether the courts will accept it? No, you need a lawyer for that. Can you look at a bridge or dam and tell how long it will last and under what loads? No, you need an engineer for that. You can, of course, wait for a court to rule on a challenge to a contract and judge how well it was written that way, but by then it's too late, and you've wasted money. Programming can be like that too. You judge a program by throwing it in front of users and accepting the financial (or, worse, human) consequences, but usually it's more economical to hire someone who knows what they're doing.
> Can you read a contract and tell whether the courts will accept it
Erik Spoelstra is a great example. Played basketball and had a short professional stint in lower leagues in Europe. Started off reviewing tape for the Miami Heat and went on to be a very successful coach. He doesn't make the plays, but he knows which players and which plays he needs. He knows when a player makes a good play and when a player makes a bad play. He substitutes players as needed for each situation. He deeply knows the domain, even if he can't himself play at that level.
When the LLM can code 100x faster than you, your job isn't to be a better coder, it's to be a better coach.
We need to think next level. Not just prompting and reviewing code but debugging code.
( Side note: why does everyone overlook debugging from code automation to new languages etc )
( Side note: why does everyone overlook debugging from code automation to new languages etc )
Unfortunately the new LLM stack is one hell of a dependency. I somewhat like what I've seen from it but its no guarantee it doesn't start to turn the screws back on you (in fact I expect it will turn out that way).
The industrialization of coding is not a new thing though, all sorts of tooling and standardisation could be described in the same terms. An LLM is just another gizmo that may or may not make the assembly line move faster.
Very different.
I'm sure it was brought up before with things like IDEs, UML, etc., etc.
But now these tools are actually competent at generating code and improving fast.
Coding up until now has still mostly been a craft or an art and less of a true engineering discipline.
I'm sure it was brought up before with things like IDEs, UML, etc., etc.
But now these tools are actually competent at generating code and improving fast.
Coding up until now has still mostly been a craft or an art and less of a true engineering discipline.
They are trying one last gamble to keep the bubble from popping. Most of the software companies don't make sense unless you can fire half your staff.
The idea that this is possible justifies the AI bubble and the software bubble at the same time.
The idea that this is possible justifies the AI bubble and the software bubble at the same time.
I don't know. Why are you software engineers always trying to replace everyone else?
I think this is a mischaracterization. In my decades of writing software I have seen it replace some job descriptions but typically (and especially for skilled labor tasks) the person enjoys more capability with less effort.
I've seen hardware replace people. I've seen software upend industries. But I haven't yet seen software replace people.
I've seen hardware replace people. I've seen software upend industries. But I haven't yet seen software replace people.
Translators, transcriptionists, bookkeepers, CAD draft engineers, studio musicians -- that's just off the top of my head.
Hasn't eliminated those professions completely, but greatly reduced the need for them.
Hasn't eliminated those professions completely, but greatly reduced the need for them.
I looked up statistics from the Dept of Labor, those jobs still pay decently well and haven't seen a significant decline in available positions in the past decade or more.
How has software reduced the need for these roles? From where I'm looking at it, the jobs still exist but more people have access to automatic versions in software. While the software has gotten good enough for hobbyist or solo-venture needs, commercial enterprise and governments still use humans.
Translators and bookkeepers may use software to help them do their job faster or easier but it hasn't replaced them. CAD designers and studio musicians are still much better than their software counterparts. Transcriptionist is a weird one, though the office typist has been outmoded as basic computer skills (including typing) have become minimum expectations for any office job, the specialist versions of the role (especially in medical records and court stenography) are still in demand, and aren't likely to be replaced by software either.
How has software reduced the need for these roles? From where I'm looking at it, the jobs still exist but more people have access to automatic versions in software. While the software has gotten good enough for hobbyist or solo-venture needs, commercial enterprise and governments still use humans.
Translators and bookkeepers may use software to help them do their job faster or easier but it hasn't replaced them. CAD designers and studio musicians are still much better than their software counterparts. Transcriptionist is a weird one, though the office typist has been outmoded as basic computer skills (including typing) have become minimum expectations for any office job, the specialist versions of the role (especially in medical records and court stenography) are still in demand, and aren't likely to be replaced by software either.
because everyone else has a tough and boring job and being replaced by computer program and some device they will be free from this tedious jobs and have more time to do what they like instead. World will be a better place.
> have more time to do what they like instead
With what money?
With what money?
Money is only needed for paying taxes. with full automation taxes make no sense - no need to force people to work for government. Basic MMT.
That's a puzzling statement. What makes you think money is only for taxes
state money is. You can use bitcoin for rest.
... Where are you going to get the Bitcoin without a job.
It's pretty simple if you take the view that there are only two classes in a capitalist society: those who profit from owning capital and those whose only capital is their bodies and thus profit from their labour.
The former own land, companies, and such assets that they profit from the difference in value between what is sold and the wages they pay labourers to produce that value.
Those people profit from wages going down.
One way to do that is to gain leverage over the job market by threatening to remove access to labourers. Unless those labourers are willing to accept a lower wage they can be replaced by AI and nobody will need them anymore.
Another way they can increase their profits is to force labourers to use GenAI tools to produce their work. There's constant pressure from the capital class to, "always improve productivity!" This is just another example of that.
I suspect there will come a point, perhaps, where some companies will decide to let developers go who refuse to use GenAI (or simply not hire them to begin with).
I don't know that we will see the technology become sophisticated enough to replace human developers entirely.
The former own land, companies, and such assets that they profit from the difference in value between what is sold and the wages they pay labourers to produce that value.
Those people profit from wages going down.
One way to do that is to gain leverage over the job market by threatening to remove access to labourers. Unless those labourers are willing to accept a lower wage they can be replaced by AI and nobody will need them anymore.
Another way they can increase their profits is to force labourers to use GenAI tools to produce their work. There's constant pressure from the capital class to, "always improve productivity!" This is just another example of that.
I suspect there will come a point, perhaps, where some companies will decide to let developers go who refuse to use GenAI (or simply not hire them to begin with).
I don't know that we will see the technology become sophisticated enough to replace human developers entirely.
Software Engineers build the tools, so I feel it shouldn't be surprising that one of the first areas it's being applied is the domain it's inventors are most familiar with.
SWE happens to have a massive training corpus readily available online, and is something that is done entirely with text.
For other engineering disciplines, the data is much thinner and the methods tend to be heavily visual, i.e. mechanical drawings or electronic schematics.
SOTA vision LLMs cannot read a schematic to save their life. The accuracy is <5%.
For other engineering disciplines, the data is much thinner and the methods tend to be heavily visual, i.e. mechanical drawings or electronic schematics.
SOTA vision LLMs cannot read a schematic to save their life. The accuracy is <5%.
"Why is everyone trying to replace software engineers?" – Is this an oxymoron?
Companies will always look for ways to save money, and headcount is usually the biggest cost
Companies will always look for ways to save money, and headcount is usually the biggest cost
I think it's just software engineers that are making the ai software. They make it do what they know how to do. It's fun in a hacker kind of way to make the computer write code.
Well slowly see more Ai intersect with other jobs as people with hobbies that can engineer make things.
Assuming Ai actually delivers what it promises in the first place
Well slowly see more Ai intersect with other jobs as people with hobbies that can engineer make things.
Assuming Ai actually delivers what it promises in the first place
Software engineering is exactly the skill needed to think of, design, and debug large valuable systems. AI will become a better and better tool to give us more leverage to make a dent in the world. We’re just going to do much bigger things. Much much bigger
The job won’t last forever, but it will outlive almost every other job
The job won’t last forever, but it will outlive almost every other job
The frequency of AI cope posts appears set to keep increasing until the very last one of us is fired. The reality is that users simply don't care about any concern to be found discussed in the church of software engineering, they want an app with a pink button, and very shortly we will be a much higher friction means to achieve that than the sloppy text generator. It's the same force behind why you can't buy high quality furniture any more or consumer devices that survive more than a few years: the vast majority of people simply don't care, they want to click "Buy" at a price level they don't have to think about and get on with their lives, only now it applies to knowledge economy work and entire industries are trying their hardest to ignore the transition we're so painfully obviously already in.
Even were it not the case for disposable CRUD Android/web apps that represent the bread and butter for half the industry, the effect on the structure of popular media is alarming in ways I don't think anyone has a hope of understanding yet. I imagine kids coming up now will not be glued to their phones anywhere nearly like the current batch are, or if they are glued to something, perhaps it is a conversational agent prompting them through an earpiece or similar.
Hand-wringing about the quality of LLM-driven app development really misses the point of all of this. We're currently using an extremely novel technology to emulate aspects of our now-defunct technology (which I believe includes the web), in much the same way fax gateways at one time were a popular application for email.
Even were it not the case for disposable CRUD Android/web apps that represent the bread and butter for half the industry, the effect on the structure of popular media is alarming in ways I don't think anyone has a hope of understanding yet. I imagine kids coming up now will not be glued to their phones anywhere nearly like the current batch are, or if they are glued to something, perhaps it is a conversational agent prompting them through an earpiece or similar.
Hand-wringing about the quality of LLM-driven app development really misses the point of all of this. We're currently using an extremely novel technology to emulate aspects of our now-defunct technology (which I believe includes the web), in much the same way fax gateways at one time were a popular application for email.
> The most recent generation of LLMs are already trained on all the code ever written.
This can't possibly be true. But if it were it would be highly illegal.
This can't possibly be true. But if it were it would be highly illegal.
AI will not replace software engineers.
But it will most likely lower their pay into "normal" engineering compensation territory.
But it will most likely lower their pay into "normal" engineering compensation territory.
Obvious point: we're the most expensive kind of non-finance individual-contributor employee.
Equally obvious: nobody is going to replace the most expensive kind of employee, the CEO.
Less obvious point: software engineers sometimes say no. LLMs don't. They'll always give you something, even if it doesn't work or has security holes. The idea of shipping worse products at higher speed is incredibly tempting to sales types.
If you think the app store is bad now, wait until you see what level of AI sloppification is possible when anyone can turn out hundreds of clones of any popular apps.
Equally obvious: nobody is going to replace the most expensive kind of employee, the CEO.
Less obvious point: software engineers sometimes say no. LLMs don't. They'll always give you something, even if it doesn't work or has security holes. The idea of shipping worse products at higher speed is incredibly tempting to sales types.
If you think the app store is bad now, wait until you see what level of AI sloppification is possible when anyone can turn out hundreds of clones of any popular apps.
> The current AI hype might not actually pose a real threat to engineers but the fact that most of our colleagues do not understand the value that we bring is a serious problem that we need to address.
> We need to start meeting our colleagues where they are and explain what we do in ways that make sense to them. The goal is not to turn them into engineers but to help them get a high level understanding of what it takes to build a software product.
See, why stop at software engineers? Because coding is text based? There is a whole class of IT middle managers in non-tech companies making good money due to "responsibility" and "team supervision". How about they start explaining the value that they bring?
If it is not more than the usual
- check a list of incoming jobs to be done submitted by other departments
- assign the jobs to be done to someone on their team, mostly the person who worked in the same area before
- ask every person (daily/weekly) for status updates and an estimated completion date for the jobs assigned
- ask if the job was done sufficiently and can be reported as completed
- report the weekly/monthly completion rate and hours spent to their supervisor.
- every now and then review contractor bids for open RFPs
then the current state of LLMs can do this just fine.
Is there a good reason not to eliminate most of the little kingdoms in a large org and instead invest the money saved into more AI supervision, better QA and a lot more marketing?
> We need to start meeting our colleagues where they are and explain what we do in ways that make sense to them. The goal is not to turn them into engineers but to help them get a high level understanding of what it takes to build a software product.
See, why stop at software engineers? Because coding is text based? There is a whole class of IT middle managers in non-tech companies making good money due to "responsibility" and "team supervision". How about they start explaining the value that they bring?
If it is not more than the usual
- check a list of incoming jobs to be done submitted by other departments
- assign the jobs to be done to someone on their team, mostly the person who worked in the same area before
- ask every person (daily/weekly) for status updates and an estimated completion date for the jobs assigned
- ask if the job was done sufficiently and can be reported as completed
- report the weekly/monthly completion rate and hours spent to their supervisor.
- every now and then review contractor bids for open RFPs
then the current state of LLMs can do this just fine.
Is there a good reason not to eliminate most of the little kingdoms in a large org and instead invest the money saved into more AI supervision, better QA and a lot more marketing?
Economically, everbody is friction from someone else's perspective.
we are expensive to employ
I think it's mostly a lack of ideas.
If I sold you a device for $1 and it minted $5 using $2 of electricity then you'd buy absolutely as many as you could as fast as you can.
However, if the devices stopped working when you had 100 of them you'd buy exactly 100 and if somebody made ones that only needed 50 cents of electricity you'd be looking to switch to those ones.
A company that is looking to downsize it's employee count is saying we are out of growth ideas and we're just going to do the same thing but more efficiently. Nothing really wrong with this except then your stock price shouldn't be like 100 P/E since there's no growth.
If I sold you a device for $1 and it minted $5 using $2 of electricity then you'd buy absolutely as many as you could as fast as you can.
However, if the devices stopped working when you had 100 of them you'd buy exactly 100 and if somebody made ones that only needed 50 cents of electricity you'd be looking to switch to those ones.
A company that is looking to downsize it's employee count is saying we are out of growth ideas and we're just going to do the same thing but more efficiently. Nothing really wrong with this except then your stock price shouldn't be like 100 P/E since there's no growth.
SaaS and consultants are also expensive to rent.
They hate us and despise the fact they're forced to compensate us for our education and experience.
Left to their own devices, software engineering would be just as abusive and exploitative as truck driving or automotive repair. They've already made great strides in this direction in terms of how people are hired (asking ACM/"Leet" code questions) and managed ("agile" nonsense).
Left to their own devices, software engineering would be just as abusive and exploitative as truck driving or automotive repair. They've already made great strides in this direction in terms of how people are hired (asking ACM/"Leet" code questions) and managed ("agile" nonsense).
Because Devs are expensive and incomprehensible to most people.
Capitalism is always looking for ways to make complex, expensive work simpler and cheaper. Why wouldn't it?
The thing is it doesn't really matter what tools you use. The problems are complex and they don't become simpler just because you use an LLM. We will gain a bit of efficiency and then spend that gain on whatever new problems LLMs throw up plus the constant stream of new problems the world generates.
Software engineers are not getting replaced by LLMs any more than they are by UML, visual programming tools, RPA, MDD, code generators or any of the other fads that have come and gone over the years.
The thing is it doesn't really matter what tools you use. The problems are complex and they don't become simpler just because you use an LLM. We will gain a bit of efficiency and then spend that gain on whatever new problems LLMs throw up plus the constant stream of new problems the world generates.
Software engineers are not getting replaced by LLMs any more than they are by UML, visual programming tools, RPA, MDD, code generators or any of the other fads that have come and gone over the years.
I mean.. they're a big cost center that operates slowly and takes a lot of effort to keep functioning. Not to mention, you often need the engineers more than you, given how much time it takes them to ramp up, and how hard it is to find quality ones, so they get to demand high wages (often while not really doing that great of a job---looking at you, average college hire who's not aspiring to be any sort of leader or expert in their field). If you ran a company you'd want to replace them also.
(None of that has anything to do with whether it's just for the world to operate this way. Personally I'd like to see all engineer wages go down and owner/shareholder returns go down and all that money go to lesser-paid roles or cheaper prices. But we lived in a version of capitalism that doesn't presently seem to present a way to do that...)
Personally I think programming will be 10x as efficient in the not-so-distant future (25 years maybe), and that everyone vaguely understands this: that what we're doing today is in some sense a waste of effort. Similar to building a road or railroad with hundreds of manual laborers instead of a few big machines.
(None of that has anything to do with whether it's just for the world to operate this way. Personally I'd like to see all engineer wages go down and owner/shareholder returns go down and all that money go to lesser-paid roles or cheaper prices. But we lived in a version of capitalism that doesn't presently seem to present a way to do that...)
Personally I think programming will be 10x as efficient in the not-so-distant future (25 years maybe), and that everyone vaguely understands this: that what we're doing today is in some sense a waste of effort. Similar to building a road or railroad with hundreds of manual laborers instead of a few big machines.
>big cost center that operates slowly and takes a lot of effort to keep functioning
This is pretty much the reason why companies want to replace their IT teams with business analysts who can use low-code/no-code. I understand why, they don't see IT as their core function. It's not how they make money, and in many cases, IT is where they lose money.
If a company can have its own business people create reports, automate tasks, etc., using tools like Power BI and Power Automate, why would they need to hire a separate IT team just for that?
This is pretty much the reason why companies want to replace their IT teams with business analysts who can use low-code/no-code. I understand why, they don't see IT as their core function. It's not how they make money, and in many cases, IT is where they lose money.
If a company can have its own business people create reports, automate tasks, etc., using tools like Power BI and Power Automate, why would they need to hire a separate IT team just for that?
This is either delusional, or trying to sell a course.
That aside, it's interesting that software engineering will probably be among the first to be destroyed by ASI. This is simply because it's easy to do reinforcement learning on.
That aside, it's interesting that software engineering will probably be among the first to be destroyed by ASI. This is simply because it's easy to do reinforcement learning on.
Just like robotic cars, the first 90% of the effort will come easy and the remaining 10% will take decades to perfect. They're going to need AGI to fully replace the intuition and knowledge integration of a dev.
Exactly, self driving for example on paper seems like an easy task to automate, you only need to make a decision for the upcoming 2 seconds, and still sucks at it, because it needs 100% accuracy, 90% is fatal and useless
It's easy to compile and run a program. It's hard to accurately simulate driving.
Because people suck? Everyone trying to replace everyone.
What's with this assumption that software engineers are some special breed of worker immune to capitalism?
because employees produce the most overhead, software engineers more than most non-execs
we're living in times where enshittification is a reliable strategy to make money and the people doing it don't care about long-term outcomes as long as they can cash out before they happen
this is almost the entire american business landscape today
we're living in times where enshittification is a reliable strategy to make money and the people doing it don't care about long-term outcomes as long as they can cash out before they happen
this is almost the entire american business landscape today
its completely over for this field. anyone that doesnt think so has their head in the sand, we are 18 months out from the value proposition of a 50-85th percentile software engineer dropping to the floor
Not without some major advancements in the technology. As good as Claude 3.5 Sonata v2 is, it still can't do more than a quarter of what I do on a day to day basis, and still makes tons of mistakes.
I guess if you spin up fresh CRUD apps or greenfield web apps for a living, you might be in danger, because they are really good at doing that. On an established codebase, especially with more than the low tens of thousands of lines of code, their usefulness is mostly relegated to writing boilerplate that can be explained in plain English. I'd be surprised if 85% of programmers were spending their days doing that, though.
Even if it was that serious, I don't see software engineers who can leverage LLMs and keep learning with the rest of their field being in much danger. The average software shop that I'm familiar with has a massive backlog of things to be done, and more direction than they have steam. We're pretty far from the point where almost any professional programmer will be saying "We finished all our work and there's nothing left to do".
I guess if you spin up fresh CRUD apps or greenfield web apps for a living, you might be in danger, because they are really good at doing that. On an established codebase, especially with more than the low tens of thousands of lines of code, their usefulness is mostly relegated to writing boilerplate that can be explained in plain English. I'd be surprised if 85% of programmers were spending their days doing that, though.
Even if it was that serious, I don't see software engineers who can leverage LLMs and keep learning with the rest of their field being in much danger. The average software shop that I'm familiar with has a massive backlog of things to be done, and more direction than they have steam. We're pretty far from the point where almost any professional programmer will be saying "We finished all our work and there's nothing left to do".
Code monkeys can essentially be replaced by GenAI (that is, a competent SWE team needs fewer or zero low-skill code monkeys going forward) but the "field" goes way beyond code monkeys.
Replacing piles of expensive crappy SaaS with a small team of expert SWE will continue to be a massive arbitrage opportunity for many mid/large orgs.
Replacing piles of expensive crappy SaaS with a small team of expert SWE will continue to be a massive arbitrage opportunity for many mid/large orgs.
And then the thing is, how do you train new employees? Any juniors will be useless.
Year, or two of unpaid internships? It's nothing new. In my country it works like this for doctors or pharmacists - they have to do half a year of unpaid work if they want to get diploma (and I use work and not internship for reason) Because as a junior you don't bring anything of value to company, you're a loss to them.
Year, or two of unpaid internships? It's nothing new. In my country it works like this for doctors or pharmacists - they have to do half a year of unpaid work if they want to get diploma (and I use work and not internship for reason) Because as a junior you don't bring anything of value to company, you're a loss to them.
I think the field will mature into a traditional specialist field like doctor/pharmacist. Well-paid junior positions may cease to exist, because we just don't need an army of juniors pumping out low-quality code anymore. But experts remain essential.
The GenAI economy transition will be very weird. The (US) education system isn't remotely prepared for it. Why pay a bunch of money for a 4-yr CS degree?
The GenAI economy transition will be very weird. The (US) education system isn't remotely prepared for it. Why pay a bunch of money for a 4-yr CS degree?
I’ll believe it when I can page an AI at 3AM, go back to sleep, and have it autonomously root-cause and fix a production outage no matter the cause.
What percentage of human software engineers would you guess pass this bar?
I'd say most of my teammates could do this. It's not a unique skill to debug a prod error.
I would say 0% of AI does? What AI can even read production environment vars, find logs in arbitrary parts of the file system, measure usage statistics, and fix the code without causing another bug?
I would say 0% of AI does? What AI can even read production environment vars, find logs in arbitrary parts of the file system, measure usage statistics, and fix the code without causing another bug?
Irrelevant. It's greater than the AI's percentage.
Envy. Digital nomads, compradors of capitalism should die.
Have you met any software engineers?
Nope. Tons of programmers, though.
I have an EE degree. Pleasure to meet you.
That's nice. Electrical engineering is engineering and "software engineering" is not.
Yet I write software 3:
3:
I had no idea there was an emoticon for "butthead." I'm going to start using this.
I had no idea there was an emoticon for "butthead." I'm going to start using this.
If an MD writes software, does that make it "software medicine"?
Did you choose not to give the reverse analogy upon discovering that EEs working on medicine are already called medical engineers?
Either they're doing medicine, or they're building medical equipment.
The former case is unlikely, since, unlike writing software (but like many forms of actual engineering), there are actually formally defined standards for what you have to know before you're allowed to practice medicine. If they are doing medicine, then the word "engineer" is being abused. Medicine is not engineering. Programming isn't engineering either. Programming isn't even much like engineering.
In the latter case, they are of course acting as engineers and the name makes sense. It's not clear what the software counterpart to, say, an artificial heart would be, though, so software engineers in that sense can't exist. I suppose there are software counterparts to medical tools, like stethoscopes and X-ray machines. We usually call the people who design them "electrical engineers" or "computer engineers".
Oh, and other things I might have considered for the analogy were things like "If a philosopher writes software, does that make it software philosophy?" I picked medicine as a random vaguely technically credential.
The former case is unlikely, since, unlike writing software (but like many forms of actual engineering), there are actually formally defined standards for what you have to know before you're allowed to practice medicine. If they are doing medicine, then the word "engineer" is being abused. Medicine is not engineering. Programming isn't engineering either. Programming isn't even much like engineering.
In the latter case, they are of course acting as engineers and the name makes sense. It's not clear what the software counterpart to, say, an artificial heart would be, though, so software engineers in that sense can't exist. I suppose there are software counterparts to medical tools, like stethoscopes and X-ray machines. We usually call the people who design them "electrical engineers" or "computer engineers".
Oh, and other things I might have considered for the analogy were things like "If a philosopher writes software, does that make it software philosophy?" I picked medicine as a random vaguely technically credential.
0 - https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...