3 Common Roadblocks with AI Developer Tools for Enterprises

By recognizing important developer tool roadblocks organizations need to overcome now, we can expect a stronger and more powerful AI developer stack in the next 10 years.

The way I describe most AI developer stacks these days: they’re like DIY craft kits with 70% of the parts and the instructions sheet missing. Lots of missing pieces and little to no assembly instructions equate to decreased efficiency and stalled innovation. AI is poised to transform a number of industries -- it’s set to grow to a $190 billion industry by 2025 -- but not if companies have to deal with DIY craft kits for developer stacks and can’t effectively build the right tools to enable its scaling.

The reason most developer stacks are so disorganized boils down to a few common challenges. First, how enterprises consume these tools suffers from what I like to call the IKEA effect. We also haven’t converged on a dominant design for machine learning (ML) platforms, and it’s difficult to create appropriate form factors for AI developer tools. Here are ways we can combat these challenges and work toward a dominant design and good form factors for ML platforms, which will accelerate innovation in the AI space.

Challenge #1: Companies adopting AI suffer from an IKEA effect

The IKEA effect refers to the phenomenon that people attribute more value to products they helped create (this applies to toys, furniture, cake mixes, and all kinds of products). And it can apply to products built by internal teams too, with engineers attributing higher value to their products created in-house than to those created by specialized vendors.

Taking the first step to address the industry-wide AI developer stack problem starts with acknowledging internal shortcomings when it comes to building tools -- and that the building and maintenance of tools might not be the comparative advantage of most businesses. People don’t know what they don’t know, and it’s far too easy for engineers to conceive of plans for DIY infrastructure, even if they only cover a fraction of the functionality needed. In the future, I think we’ll see enterprise customers moving away from building their own ML platforms, recognizing that it’s not their core competency. They’ll realize that more value comes from applying ML to business problems versus spending the time to build and maintain the tools themselves.

Challenge #2: AI developer tools lack a dominant design

Countless cloud vendors and startups have piled on resources to bring AI developer tools to a broader audience. All these solutions attempt to solve the same user needs, but all of them also have different approaches -- leading to a proliferation in different designs.

As a product manager on the Google Brain team, I saw this problem firsthand. When I was on the team in 2016, I remember trying to rationalize more than 20 different high-level Python APIs that had emerged for TensorFlow within Google. Eventually, we converged on the Estimator and Layers APIs (which merged with Keras in TensorFlow 2.0). As I witnessed in this role, there is a lack of dominant design at every level of the stack, and it usually progresses from the bottom up.

To fix this, the industry will need to converge on a dominant design for ML platforms. What we’ll likely see is one platform that gains traction and leads the way in defining the core design, and the rest will follow. This one product’s momentum will cause many vendors to exit the market while other vendors will conform to the dominant design.

Challenge #3: AI developer tools have a form factor problem

Form factor refers to electronic components or different incarnations of how tech is packaged for users. Take the iPhone, for example, as the predominant form factor for smartphones. Unfortunately, defining common form factors for AI developer tools has proven difficult; I like to refer to it as the “Wild West” of different API services and surfaces.

The problem stems from an assumption that tools and processes we created decades ago for software engineering are magically transferable to ML. Some vendors have also attempted to create different form factors (like SQL ML and WYSIWYG/UI ML), but most fail. To address this form factor problem, we’ll need to create a few meaningful form factors for different target audiences -- there’s no reason we have to restrict ourselves to just one. Actually, I’d argue that it is desirable to have different layers of abstraction to ensure different categories of users can achieve all the possible benefits of AI. Each layer should be well defined, and abstractions shouldn’t leak between layers.

AI tools have so much potential: A majority of executives whose companies have adopted AI said it resulted in an uptick in revenue in the business areas where it’s used, and 44% say AI has reduced costs. But we can’t reap the benefits of it without the right tools built by the right startups. By recognizing important developer tool roadblocks organizations need to overcome now, we can expect a stronger and more powerful AI developer stack in the next 10 years.


Clemens Mewald is the director of product management, machine learning and data science at Databricks, where he leads the product team. Previously, he spent four years on the Google Brain team building ML infrastructure for Google, Google Cloud, and open source users, including TensorFlow and TensorFlow Extended (TFX). Clemens holds an MSc in computer science from UAS Wiener Neustadt, Austria, and an MBA from MIT Sloan.