Software Engineers Coding AI May Code Themselves Out of a Job

"We know only two things about the future: It cannot be known and it will be different from what exists now and from what we expect." - Peter Drucker

The History of Computer programming can be traced back to 1801 when Joseph Marle Jacquard invented a mechanical, automated loom, the Jacquard Loom.  The Jacquard Loom used punchcards to control the operation of the loom. Today much of everyday life is controlled by the instructions typed into programs by Software Engineers that run computers of all sizes embedded into the fabric of our life.  We now have computers in our clocks that ring us awake, our showers that adjust our water temperature, our houses that know where we are and  turn our lights on and off, our cars that we drive to work and the toll scanners that track our drive. And at work most of what we do in the modern office is done using computers, including the copy machines, the telephones, our desktops and our security systems, computers are everywhere.  And these computers, no matter how tiny or big are run by programs typed in by a Software Engineer.

Artificial Intelligence (AI) describes a program written by a software engineer to enable computers to perform tasks commonly associated with intelligent beings. Tasks include the ability to learn, reason, discover meaning, generalize, or learn from past experience. This is much different from the static pre-AI programs that are stamped with a finite amount of intelligence and get smarter over time as new versions are released over time.  But pre-AI programs can't learn or reason or get smarter, or do anything they weren't programmed for and that is the big difference.  AI programs can actually update themselves.

AI will be the biggest wave of technology disruption the world has ever seen, dwarfing the Industrial Revolution.  In their paper "Artificial Intelligence: The Next Digital Frontier", the McKinsey Globlal Institute writes:

"Artificial intelligence is poised to unleash the next wave of digital disruption, and companies should prepare for it now. We already see real-life benefits for a few early adopting firms, making it more urgent than ever for others to accelerate their digital transformations. "

Although today, many repetitive manual tasks have been automated by computer programming there were still many repetitive manual tasks that required learning, reasoning, discovering meaning, generalizing, or learning from past experience, these tasks could not be automated by pre-AI programs.  The automation of these tasks using AI programming will start biggest wave of technology disruption the world has ever seen. Conner Forest in his article "The first 10 jobs that will be automated by AI and robots" list the following:

1. Assembly Line Worker
2. Field Technician
3. Call Center Worker
4. Sorter
5. Data Entry
6. Insurance Underwriter
7. Tax Preparer
8. Sales Representative
9. Translator
10. Fast Food Employee

In fact, as he reports in his article, the  Oxford Martin School in the UK estimates that roughly 47 percent of the total US jobs are at risk of computerization or automation.  

So what about the Software Engineers who are coding the AI programs that are automating all these jobs, is it possible that they might code an AI program that could in fact write and rewrite itself and automate the job of a Software Engineer.  This is in fact where AI is going.  Here are some example projects:

• Pliny - Autocomplete for software engineers. “Imagine the power of having all the code that has ever been written in the past available to programmers at their fingertips as they write new code or fix old code,” said Vivek Sarkar, Rice’s E.D. Butcher Chair in Engineering, chair of the Department of Computer Science and the principal investigator (PI) on the PLINY project. “You can think of this as autocomplete for code, but in a far more sophisticated way".
  
• ExCAPE - aims to change programming from a purely manual task to one in which a programmer and an automated program synthesis tool can collaborate to generate software that meets its specification.
  
• ai.codes - In our view, software engineering is about modeling and automating the real world. Coding, to a large extent, is the boring part of the job. Coding is not only tedious, but it's error-prone. Software bugs happen when we, human translators, fail to translate our ideas into codes correctly. We believe that AI is at a stage where it can help software engineers in writing code.
  
• AI Software learns to write AI Software - Google and others think software that learns to learn could take over some work done by AI experts.

The Enterprise Minimal Viable Product

'The MVP Paradox' good read, worth the time. In the article the authors define the Minimum Viable Product or MVP as a "reality check for founders so they don't end up wasting tons of time and money building something no one needs or will pay for".  The MVP is at the core of the Lean Startup movement but it's original design, to be customer-driven instead of being product-driven, has been cheated by Product Managers eager to get products out the door.  

The problem with the term Minimum Viable Product is that it doesn't have a hard and fast definition. The MVP has given Product Managers license to build things fast to save money, ship and repeat regardless of whether the product feature set is complete.  The goal of the MVP, to learn from customers to validate the business hypothesis, can't be achieved because customers won't spend time with a product that doesn't have a minimal set of features they need to do their work.  Instead of the sound of early adopters working through the product providing feedback we hear the sound of crickets, no one is using the product.  The next sprint starts and a list of features, unvalidated by the market, are tee'd for implementation in an attempt to provide enough value in the product to attract early adopters. This cycle continues iteration after iteration with little customer feedback, the process is broken.  As the authors state "Over pursuing your MVP this way can be the fastest way for your company to 'go broke saving money'".

The 'MVP Paradox' is particularly important to watch for in the Enterprise Market where product niches are relatively mature.  For example, introducing a new document management (DM) system would require the MVP have a feature set that at least competes with the entry level DM systems on the market, we call this the 'table stakes' to enter the market.  An MVP with anything less than the 'table stakes' would not be viable. After all, why would a customer struggle with your MVP if they could buy the entry level DM and have everything they need? Hopefully your MVP has some innovative feature or process but this would have to be in addition to the minimal feature set. So it's important to remember, especially in the Enterprise Market, that MVP's may take several sprints/iterations before they have the minimal feature set to ship to the market. I agree with the author's of 'The MVP Paradox', it would have served everyone better if we had named the 'Minimum Viable Product', the 'Minimum Awesome Product', than Product Owners would stop misunderstanding it as minimal features, laziness in user research, or unpolished experiences.