Ronald Ashri


Building AI software: The working programmer’s conundrum

What on earth does it mean to “build AI software”?

This company is going to go AI-first on all its tech and that will cut costs, increase revenue and the world will be amazing.

You’ve been working on your company’s software for years. You know all the ins and outs, the paths that lead nowhere, the tripwires to hop over and the avalanche-prone areas where you must tread lightly.

Despite everything, this delicate balancing act of a hodgepodge of software (half of which you would have never picked yourself but “strategic alliances” dictated otherwise) runs all the internal infrastructure and external consumer-facing tools just fine. You sleep easy (most nights) and you have a plan on how to get to a better state piece by piece, sprint after painful sprint. It will be tough, but you will get there because you actually care about your craft.

Yesterday, though, the management team called you in. This company is waking up, they say. It’s getting with the times. It going to innovate itself out of the downward spiral it’s in. They have just two words for you. Artificial Intelligence. This company is going to go AI-first on all its tech and that will cut costs, increase revenue and the world will be amazing. They’ve been told this is what happens and they have bought the dream. All they need you to do is come up with a fail-fast, iterate constantly, scale instantly plan that will get everyone there. Report next week.

You go back to your desk and think: “What exactly is AI anyway? What on earth does it mean to “put AI in software” or to “build AI software”.

“What on earth does it mean to build AI software?”

This, I think, is the working programmer’s conundrum (with regards to AI at least!). It’s not that we are concerned about change as programmers. We thrive on change. We are inundated daily with new ideas, new concepts, new frameworks and we have become very adept at understanding how to deal with them, what to ignore and what to take into consideration. AI, however, takes this problem to a whole new level.

It doesn’t help that whenever you start reading on the subject people start mentioning the need for PhDs and advanced math.

Worst still are those who say that AI is nothing to be too concerned about. It’s just business as usual. It’s a better recommendation algorithm, or some bit of fancy data analysis thrown in with a pretty visualisation perhaps. These are the same people that say they downloaded Tensorflow and built something cool in just a day.

The biggest trick AI managed to play on working programmers is to make them think that it doesn’t exist.

We need to start thinking of AI as a fundamentally different way of building software. The ability of the software to learn, adapt and autonomously make decisions is placed front and centre with AI. That needs to be the starting point.

We need a software engineering design methodology that places those concepts and those abstractions at the centre. From there we build out. From there we can start evolving the design until we get to the point were we start falling back to the tools we already have like object-orientation, or domain design or whatever is your preferred methodology to express a software design idea.

I’ve started writing about it here in the context of data-driven vs model-driven AI and I will be expanding on some possible routes in the future. In the meantime it would be great to hear other thoughts. Do we need a different set of abstractions? Are the tools currently available to programmers enough to design and think about AI software?

More by Ronald Ashri

Topics of interest

More Related Stories