Software Developers Worry They Will be Replaced by AI (Press Release at 03/08/2016):
Developers fear that their own obsolescence will be spurred by artificial intelligence, according to a new survey of over 550 software developers to be released this week by Evans Data Corp. When asked to identify the most worrisome thing in their careers, the largest plurality, 29.1%, cited “I and my development efforts are replaced by artificial intelligence.” This was significantly more worrisome than platform issues, such as their targeted platforms becoming obsolete which was the second most cited worry at 23%, or that the new platform they're targeting doesn't catch on (14%).
The thought of obsolescence due to AI was also more threatening than becoming old without a pension, being stifled at work by bad management, or by seeing their skills and tools become irrelevant. While the developers who worried about AI were found across industries and platforms, one strong correlation was that they were more likely to self-identify with being loners rather than team players.
Dev Bootcamp is a 19-week accelerated coding program designed to teach people how to become web developers. Graduates to this program are then invited to an "alumni Slack", where they can talk with other alumni about their future career in programming. (Disclosure: I have graduated from this program and was invited to this chat.)
On February 1st 2017, a discussion took place in the "alumni Slack" about the future of automation in software development..sparked by a off-hand comment in a separate conversation. I lightly edited the transcript below after getting permission from those who participated in this discussion. To protect the identities of the people involved in this discussion, their names have been changed.
daphney.cronin - "Coding is a commodity these days and so while you do need to be competent, the thing that's going to win the offer is your ability to click with the interviewers and your genuine desire to be part of the team and contribute to the product."
This statement makes me dread for the future of my current profession. It's true, of course, but commodification of skillsets will ultimately lead to automation of those same skillsets.
adaline_stracke - I think the automation of development is pretty far off though. There are only so many things that a WYSIWYG editor can do, and the code isn't very maintainable. The main challenge that I see in programming isn't writing code, it's writing code that is human readable because computers are dumb and AI hasn't progressed far enough to debug the way a human can.
The WYSIWYG is a “for instance” BTW.
kallie - I dunno, I think making a computer drive a car is a lot harder than making it write code.
adaline_stracke - I disagree. Making a computer drive a car is a series of concrete decisions where as writing code is a series of decisions that have opinion behind them
skittles_mcbangbang - I see things like ‘serverless infrastructure' has a harbinger. take a look at aws lambda, you put code on a webpage, and it gives you an endpoint to hit.
How long before someone writes some sort of adapter that takes business logic and written text and turns it into behaviour. I mean, we already have testing frameworks that sort of do that (cucumber).
adaline_stracke - But that's okay. Because it takes someone who knows how to create the business logic. I can learn a new syntax fairly easily, but that's not what programming is.
Actually, isn't that what Ruby is? We write logic in Ruby and it compiles to C.
kallie - Yes higher level language abstraction is already semi-automated code. It all becomes machine code in the end. There's no reason to believe this trend won't continue.
skittles_mcbangbang - Non-programmers are also capable of logic, and one might argue have a better grasp of what the intended product is supposed to look like. And if you provide them a quick enough feedback loop between them writing an english sentence and seeing app behavior change...
kallie - Yeah that would arguably be better than your normal development pipeline. Hyper-rapid development and testing.
adaline_stracke - I guess what I'm trying to say is that the leap from writing code as we do now to full natural language processing and translation into behavior is very big.
kallie - It's big but I don't think it's as insurmountable as many people would assume it to be.
adaline_stracke - Agreed.
skittles_mcbangbang - Agreed. We might not need the natural language processing bit either. It wouldn't be hard to train people to write their english in a certain structure. it would just be part of the job training.
1: Feature: Some terse yet descriptive text of what is desired
2: Textual description of the business value of this feature
3: Business rules that govern the scope of the feature
4: Any additional information that will make the feature easier to understand
5:
6: Scenario: Some determinable business situation
7: Given some precondition
8: And some other precondition
9: When some action by the actor
10: And some other action
11: And yet another action
12: Then some testable outcome is achieved
13: And something else we can check happens too
adaline_stracke - Where I work, we tried doing something similar for testing, but it wasn't successful.
I guess I fail to see the difference between teaching someone to express logic in one structure (like a programming language) vs another (such as what you pasted there). Fundamentally, it comes down to specific training which is what was talked about above.
skittles_mcbangbang - It's extremely helpful in microservice envs, IME. It was an easy way abstracting the several different calls by simply stating the prerequisites needed for the actual tests to run.
daphney.cronin - The difference is that another human (with no training of how to express logic in that formal fashion) can read the specs and understand exactly what is occurring.
adaline_stracke - @daphney.cronin, I get the idea of readability, but we were talking about the automation of WRITING code.
daphney.cronin - Yeah, this type of approach really wouldn't help in automating code (since you're replacing one type of formalization with another). A corporation that wants to automate code would be better off trying to improve code generators (like Rails) or CMSes (like RailsAdmin, ActiveAdmin, or Wordpress)...
skittles_mcbangbang - That doesn't remove the need for a dev though, since in using those frameworks, you're still creating and maintaining servers. If you can type gherkin into something like Lambda or OpenWhisk, then you start to get closer to replacing developers.
adaline_stracke - I think that's the real rub here. Until AI is as good at debugging and maintaining as humans are, there will still be needs for devs.
I think it's the same idea as self-replicating robots. Until robots are good enough to fix and rebuild themselves we need people to maintain them. Until software is good enough to fix and write itself, we will still need people to fix and write software.
skittles_mcbangbang - No doubt, but it's still possible to replace a LOT of devs with the scenario above. You still need people to build and maintain those types of infrastructures, but waay less.
Commentary - Computer scientists have conducted research into the automation of bug fixes -- the most promising program at the moment is GenProg, a program that uses genetic programing to mutate existing codebases to fix bugs. According to an interview by its developers, GenProg is very cheap ($8/hour) and speedy, but the computer-generated code is not as maintainable as human-generated code. GenProg also is heavily dependent on the specifications to determine whether it has fixed the bugs, so the software engineers using GenProg would switch from writing code to writing tests. The "formalization" of business logic would still remain in human hands.
The discussion assumed that the needs for software will stay constant. This may not be true -- instead, software is increasingly required to be made more complex and to handle more stuff. This leads to the Complexity Paradox, based on Tog's Law of Commuting:
"The time of a commute is fixed. Only the distance is variable." Translation? People will strive to experience an equal or increasing level of complexity in their lives no matter what is done to reduce it. Make the roads faster, and people will invariably move further away.
... Given that people will continue to want the same level of complexity in their lives, given that we will continue to reduce the proportion of complexity of any given function that we expose to the user, we may expect that the difficulty and complexity of our own tasks, be they at the application or OS level, will only increase over time. That has certainly been the case so far--we've gone from simple memo writers and sketchpads to document processors and PhotoShop. And we may assume that's only the beginning.
So when we build higher-level languages, code generators, and CMSes, we merely encourage users of those tools to do more "work" with those tools. This increases the complexity of the resulting software, which would require more maintenance work. Software is constantly being asked to be changed and upgraded, and the field must keep up with the demands.
This would seem to suggest that programmers would have high job security (and Tog would make that very assertion at the end of his essay). However, the goal of all automation is cost-savings and greater efficiencies. There is cost-savings involved when you fire programmers and replace them with cheaper "specs writers". And as software becomes more complex and convoluted, we will probably rely less on very-fallible humans and more so on less-fallible machines.
Therefore, it is safe to say that many developers will still remain afraid of automation/AI for quite some time, and so the debate will still rage on...
Top comments (8)
Guys, not technically but philosophically speaking doesn't this Law cancels (to some degree) automation downsides like so called 'mass unemployment'?
Tog's Law of Commuting:
"The time of a commute is fixed. Only the distance is variable." Translation? People will strive to experience an equal or increasing level of complexity in their lives no matter what is done to reduce it. Make the roads faster, and people will invariably move further away.
My point – we'll find stuff to do and create new ways of spending of lives – space exploration, huge projects, advanced gaming etc.
It could, but only if that Law holds true. If, at any point, people stop worrying about the preservation of complexity, then problems might arise.
In addition, automation downsides like "mass unemployment" can still be a problem because it may take time for society to slowly compensate for the reduced complexity of its actions. This "mass unemployment" might be temporary (for some definition of "temporary"), but it would still cause social turmoil and chaos. It also doesn't help that there's no "end-state" to strive for...automation isn't going to stop. As soon as we develop new jobs and new work, those new jobs are in danger of also being automated away (for us to worry about even newer jobs and even newer work) . Society could quickly cycle between "mass unemployment" and "full employment", depending on the speed of our technological progress.
EDIT: "Retraining" and "retooling" existing people for new jobs would also become very expensive, especially when those new jobs can quickly become obsolete thanks to automation (forcing another round of "retraining" and "retooling"). If people are complaining about JavaScript Fatigue now, what do you think is going to happen when all fields start experiencing churn?
This comment is better than the article itself.
High level programmers, who have never programmed for an actual hardware target, but play around in sandboxes created with software designed "platforms" could be replaced with automation. The mental modeling of that kind of code is so robotic already, we are just taking the next step by finally removing the frailty of flesh and blood components.
Someone has to write and maintain the automated programmers ;)
Someone else has to write and maintain other low-level hardware centric code, and jeer the programmers programming automated programmers for essentially the same reasons they mocked the predecessors they replaced. :P
Not only does the automated systems need to be maintained but the these systems would need highly specific requirements to generate the code properly and test that it is complete.
So in my view programming would simply transfer to a much higher level language. It might mean it is easier, but it may get even more complex espically when you have a bug in this computer generated code, and then you can't reproduce it with a spec test. Would the computer understand why the bug is happening? Some times the users what something changed, but is it even feasible or even advisable to do it? As developers big part of the job is dealing with complexity so others in the business don't need to. Automation may make it easier but it may also make things much more complex. We often have the tendancy to fool ourselfs into thinking things are much more simipler then what they really are.
Yes! Code will be automated too! Check out Wolfram Language, it is the highest level language I know about. You can ask stuff like "GDP from USA by population", "apple, ibm, oracle stocks comparison" and it gives you a good answer...
But I don't think a general code robot will come up soon. I think it gonna be such as robots in factories, they do specific jobs, for example, soldering, painting and so on... there are many robots in a factory for very specific tasks, and humans too (but just some of them). And in additional, there is Engineer to fix robots!
Take a look at Oracle APEX, or Spring Roo those tools automate a lot of programming job, if you use it in the appropriate way, you can save a lot of coding time!
You are right. This comment is better than the article itself.
I mean, there is Scratch...