The Intersection of AI and Software Engineering
“Last stop, Doraville Station, doors open on your left.” There I sit, one of the last people on Marta, as it pulls into its final resting place. I had just finished the first day of the rest of my life, my first day at Flatiron School studying Software Engineering. While scrolling through Twitter I see a post by Andrew Yang talking about the rise of automation. He lists out a multitude of jobs that will be impacted by AI shortly. The list covered everything from truck/taxi drivers to retail clerks to paralegals to call center support; I assume I (and the rest of my classmates) are in the clear. Then I scroll down in the same thread and see him say, “some low-level coding jobs will also be automated.” Obviously nobody wants to be a “low-level” software engineer and it wasn’t the first time I’d pondered the notion but it still gave me pause…
Now, mind you, Andrew Yang is no software or AI expert but he is connected with many of them through his business ventures. Okay, enough about Andrew Yang. What many don’t realize about the software engineering profession is that we have been using automation to write code since its infancy. Examples can be seen in external libraries, attribute accessors, active record, scaffolding, generators, test extradition, mass instructors, loop statements and gems. Anything that allows the engineer to focus on higher-level logic instead of writing a hundred if…else statements is a welcome advancement. Great, so what does the future hold?
In May of 2018, with funding from Google and the US Military, Rice University released a project called Bayou. It was designed to take “neural sketches” of every Java file on Github (it can only read and write Java). It would then compile these hundreds of thousands of sketches and compile them to start pattern matching lines of code to see what is happening within the program. The user then gives Bayou a few keywords and it builds a neural sketch of its best guess. In this case, an API call:
In the same way that scaffolding has its pitfalls due to unnecessary files, Bayou has the same burden. It just returns the only three APIs it can and has no way of assigning logic once received.
Here is another snippet returned from Bayou. Here we can see an IF statement comparing identical variables equal to each other. To add insult to injury, the variable is never defined in the entire neural sketch and Bayou cannot interpret wildcards.
Holes could be poked in Bayou’s code all day but it will improve with time. API calls are considered a pretty low-level task in software engineering. When it comes to making business decisions of feature rollouts and UI/UX design, Bayou has lightyears to go. The next step will be installing Bayou in an IDE, much like a snippet generator.
April 10th, 2014 a woman in Seattle hears a rustling at her front door and calls 9–1–1. The line is busy. 9–1–1 is…BUSY?!?! She proceeds to call 36 more times, busy every time. She ended up scaring him off with a kitchen knife but it could have been worse. She’s not the only one either, it rang busy for a duration of 6 hours for 11 million Americans. Nobody knew where to turn, everybody pointing their finger at somebody else. The issue ended up being on a server in Englewood, CO ran by a company called Intrado. One of their engineers had set a function to increment every 9–1–1 call so they would have a unique instance holding info like a timestamp and GPS coordinates. The engineer also set a max number in the millions thinking it would never be hit. They were wrong. The issue took so long to pinpoint because no tests were written to flag the function on the assumption that they weren’t necessary.
In 2015 United Airlines had to ground their entire fleet worldwide because of a problem with their “departure-management system.” Examples of software failures are endless. We’re humans, after all. Now imagine a software system failing and nobody in the world can decipher the code. That wouldn’t be a system that would be safe to install with any lives at stake. We must be able to debug our code when it inevitably fails.
Software systems are always increasing in complexity. If no one can decipher the program then it simply can’t be rolled out. For that reason alone, automation isn’t coming for software engineers. Add it currently not being where close to the ability, having no business sense, no design sense and no way to feed it deliverables then the future remains bright for software engineers. AI will continue to be there to make your life a little easier but it isn’t coming for your job in the foreseeable.
I leave you with a quote from Marc Andreessen, “The spread of computers and the internet will put jobs in two categories: people who tell computers what to do, and people who are told by computers what to do.”