The Robots That Will Put Coders Out of Work
snydeq writes Researchers warn that a glut of code is coming that will depress wages and turn coders into Uber drivers, InfoWorld reports. "The researchers — Boston University's Seth Benzell, Laurence Kotlikoff, and Guillermo LaGarda, and Columbia University's Jeffrey Sachs — aren't predicting some silly, Terminator-like robot apocalypse. What they are saying is that our economy is entering a new type of boom-and-bust cycle that accelerates the production of new products and new code so rapidly that supply outstrips demand. The solution to that shortage will be to figure out how not to need those hard-to-find human experts. In fact, it's already happening in some areas."
The robot doesn't have to debug anything. All it needs to be able to do is write code like:
Problem solved!
This is nothing new. For instance, word processing consultants were put out of business by Word Perfect. If those former word processing consultants wanted to stay relevant, they had to retrain themselves. In software development, we're constantly trying to automate our own work and replace ourselves, until one day we're actually successful at it, and then we have to find a new problem to solve if we want to stay relevant on the open market.
I'm not sure why those guys are taking a jab at Uber thought. Uber isn't replacing Taxis. It's meeting the demands of the open market during peak hours, which Taxis are incapable of filling by themselves (at least, not in places like San Francisco or New York where it's absolutely impossible to get a taxi during the time when you most need one).
It's trying to figure out how to do things that no one else has actually done before, and doing it with very demanding constraints of size and speed
The demanding constraints are constantly getting less, though. I remember spending days to squeeze the code into 1024 instructions into a small microcontroller. Nowadays, I can get 1MB flash for the same price, and use maybe 40kB of it.
The article does not have anything even worthy of consideration. It is just bloat with a snappy headline. The story goes like this: we know there is technical progress, software developers are in as high demand as never before, with wages 70% above other 'induatrial workers'. In the past, such high skilled workforce lead to investment into automation, and that's already happening. Case in point: standardized sports events are written by computers, not journalist. See? If you can replace journalists, sure developers are in immediate danger. After all, not much difference, developers and journalists alike type on keyboards and sit in offices and are good at exressing their thoughts in words. Developers beware!!
Again, just plain and utter BS. Makes me wonder if that article was written by a bot, too.
You are about right. Considering there is actually many jobs even higher paid than tech and programmers' jobs, then why this exact rational from TFA hasn't yet been applied to these jobs since the savings will be much greater? Many diagnostics and prescriptions from omnipraticians doctors could be replaced by automated systems with higher success rate and lower error rate in prescriptions and much lower price than the average or even expert doctor these days. These doctors essentially measure a small amount of physical characteristics, pulse, blood pressure, temperature and ask few questions to finally reach a diagnostic. This can be automated for the vast majority of common diseases. And when the application cannot reach a diagnostic because the case is too complex it could even ask for more information, blood analysis, CT-scan, bacteriological culture, etc. Which a nurse can take a sample as required of the tissus needed or the blood sample to be sent to a lab for analysis and the results being returned back to the automated system for further analysis. If at the end, the program cannot reach a diagnostic with a high probability, then the case can be refered to human doctors and probably to a panel of experts because at this point it is very likely the regular average doctor will not be able to do better.
Achille Talon
Hop!
What is happening is companies are farming our their dev to Indian agencies (while they are so cheap). What comes back is buggy, badly designed but mostly done. The company's dev start then bang it into shape. I've worked both sides of the Atlantic freelance and I'm seeing this outsourcing all the time, as have associates in my field. It's not as complete outsourcing like we saw in the late 80s early 90s, it's just bulk code generation. You would be surprised who is doing this, even very big names in finance are doing it. The next time you swipe your card, you are probably using dirt cheap code from an Indian code center.
There's so much work to do that I doubt our tools will ever "displace" us.
I find it so strange when otherwise seemingly intelligent people use the word 'never' regarding artificial intelligence. If our brains operate according to the known laws of the universe, then why would you suppose that the piece of meat between our ears could never be improved upon. Really?! Never?
Look where all this talking got us, baby.
Most of the time, economics is simply various economists or think tanks pushing policies advantageous to their patron's ideological or financial goals. So it's not even pseudoscience, but flat-out astrology.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
We will have self driving cars long before we have robots that write code.
But we already have robots that write code. Almost no one actually writes machine code anymore, depending instead on assemblers, compilers, templates, or interpreters to do it for them. Those 'robots' have gotten progressively more complex and progressively better at figuring out what the programmer means by larger language constructions. The languages have moved closer to natural languages.
Already, it seems like the difficult part is getting the managers to properly specify the desired functionality. It's not a huge leap to imagine that one might construct a formal language for program specification that would allow you to automate translation of the spec into a code skeleton.