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.
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?
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.
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.
> 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.
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!
( Side note: why does everyone overlook debugging from code automation to new languages etc )
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.
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.
"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.
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.
Code is just a medium used to build software, the real value comes from analyzing problems and finding solutions.
0 - https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...
Software engineer or Software developer are much better terms.
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 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".
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.
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.
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.
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.
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)
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.
I reckon we're cheap. Even with the current wages software engineers have, 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%!"
I've seen hardware replace people. I've seen software upend industries. But I haven't yet seen software replace people.
Hasn't eliminated those professions completely, but greatly reduced the need for them.
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.
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.
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.
"Replacement" is smoke and mirrors at this point; anyone who seriously tries it will quickly fail, with today's technology.
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.
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.
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.
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!?
I would think the opposite. Surely everyone thinks they could write a book?
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 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.
Developer brains are still much more efficient at holding the different layers of context involved to build systems.
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.
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.
But with the externalization of intelectual work (which happen without IA, for ex. India tech) I wonder if such solution is possible.
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%.
(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.
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?
> CEO: Fantastic! I've already fired all of the doctors and nurses, how soon can it start doing surgeries?
> Scientist: ...
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.)
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.'
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.
The idea that this is possible justifies the AI bubble and the software bubble at the same time.
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.
Companies will always look for ways to save money, and headcount is usually the biggest cost
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
The job won’t last forever, but it will outlive almost every other job
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.
This can't possibly be true. But if it were it would be highly illegal.
But it will most likely lower their pay into "normal" engineering compensation territory.
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.
> 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?
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).
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.
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