ArtificiaI intelligence, APIs and the transformation of computer science

These are exciting times in the world of artificial intelligence as advanced capabilities escape the labs and become central to mainstream products -- think Amazon Echo -- and increasingly accessible to everyday software developers.

Recently, we’ve seen a run of large companies open-sourcing their A.I. platform APIs. Google has open-sourced TensorFlow, its machine learning library. Not to be outdone, Amazon has released its TensorFlow competitor DSSTNE (or Deep Scalable Sparse Tensor Network) and Facebook has done the same with fastText, its machine learning engine for text classification and language recognition. Those big-company A.I. platforms join -- and in some sense compete with -- notable open source deep learning libraries like Caffe, Theano andTorch.

In many ways, open sourcing access to A.I. represents the culmination of the “API economy,” where software developers set aside their not-invented-here pride of creation and instead access the work done by others -- and in the process accelerate their own development work -- via API hooks. If software development-by-API made sense in the past, it may be the only practical path forward when it comes to fully leveraging new capabilities in the artificial intelligence field.

Indeed, the impact of these moves can’t be overstated. On a business level, they significantly lower the barrier for entrepreneurs looking to start up the next wave of artificial intelligence-driven companies by democratizing access to machine learning resources. That’s hugely significant.

But I’d argue for an even more fundamental change: Open source A.I. APIs represent the beginning of a transformation of computer science (CS) into a field focused on impact.

Innovators, integrators and designers

At its most basic, CS can be described as people working on new algorithms or improvements to existing ones, with new “inventions” being built on the back of what came before it. In CS, there are two standard ways of doing this: creating libraries of functionality that developers can build into their own applications; or providing access to functionality in one fell swoop via API.

Software development via API is hardly new. Microsoft became a behemoth on the strength of its platform APIs and the swarms of developers that consumed them. More recently, SaaS companies like Salesforce and Google have offered developers the ability to extend their platforms via API. And in the latest trend, new programming concepts like microservices and bots are centered on assembling applications via modular, distributed processes accessed via open APIs.

The latest surge in A.I. APIs opens up a whole new world of capabilities to software developers. Need an engine that can understand spoken language, recognize a single face from a crowd of thousands, pull meaning from a mountain of social media sentiment or act as the "brain" behind an industrial robot or self-driving car? Yesterday’s programmatic algorithms won’t cut it; you need machine learning and A.I.

Like yesterday’s code libraries, you could try to build A.I. platforms yourself -- if you had a few years and a dozen data scientists to throw at the problem. Or you can access A.I. engines like IBM’s Watson or Google’s TensorFlow “as-a-service,” taking advantage of the planet’s most advanced, fundamental CS work via an API call.

When one looks at the world of software in this way, the choice for most companies today is straightforward: spend years of effort and millions of dollars in expense duplicating extremely important -- but ultimately commodity, especially once it’s open-sourced -- computer science work, or instead focus on leveraging that work to develop and improve their own products and intellectual property. For most businesses, the choice is simple.

In this new future, the choice for developers also becomes clear. They can be software innovators, integrators or designers. These roles will slightly overlap in some ways given an individual’s skillset and company needs but by simplifying the roles, its easier to communicate how I envision our way forward.

• Innovators work out on the edge of research and development, creating new algorithms that have not yet been built and extending the capabilities of those that already exist. Fundamental CS work is always required and absolutely crucial but in today’s open source-driven software environment also increasingly a commodity.
• Designers focus on crafting new products, solutions and applications, using powerful technologies like machine learning and A.I. -- accessed via open APIs -- to identify new opportunities, create new solutions and solve problems in new ways altogether.
• Integrators take existing capabilities and build them into new products. Their role is to deal with the nuts and bolts of implementing the designs that bring innovations together. They do not design the algorithms or products; rather, they make them work.

It’s absolutely crucial for academia, businesses and even developers themselves to understand the distinctions between these three very different types of software developers. They represent three different skill sets and approaches to the business of software development.

For companies, hire wrong and the results can be devastating. Bring on an innovator to do an integration job and nine months later they’ll still be tinkering under the hood. Need some exploratory data work done? Hire an innovator, yes, but don’t expect them to build your industry’s next breakout product. For individual developers, mismatched skills and ambitions can be just as damaging, not only to someone's career path but day-to-day enjoyment of the job and task at hand.

More than ever in a computer science landscape defined by systems in artificial intelligence and big data manipulation and analytics, not all data scientists and programmers are created equal. That’s not a value judgement, i.e., good vs. bad. It’s about a difference in kind. Innovators, designers and integrators.

Tomorrow’s worlds of business -- and software development -- needs them all, and more importantly needs to be able to tell them apart and pick the right tool for the right job. The future of computer science depends on it.

This article is published as part of the IDG Contributor Network.Want to Join?