111–120 of 145 posts
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).
> 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?
Earlier quoted context omitted.
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.
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.
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?
Earlier quoted context omitted.
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 ch…
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 therap…
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.
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), mechan…
But with the externalization of intelectual work (which happen without IA, for ex. India tech) I wonder if such solution is possible.
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 a…
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 beca…
> 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.
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.
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.
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.