There Will Be a Time in Which an AI Will Replace Myself in Writing this Article

Iacopo Ghisio, Head of Tech Innovation & Product: Artificial Intelligence, Machine Learning, Robotics and KYC, Gruppo Mutuionline

Iacopo Ghisio, Head of Tech Innovation & Product: Artificial Intelligence, Machine Learning, Robotics and KYC, Gruppo Mutuionline

There will be a time in which an AI will replace me in writing this paper; this is not yet the case but I think we’re not too far! I love being helped by someone else when I work on something, either by a human or by a machine; both of them have good or by sides, you just need to be able to exploit them correctly.

Then help received here was googling about top tech trends of 2021 and without too much surprise, the result number 4 was about hyper-automation. So let’s see what is and how to benefit from it.

Robotic process automation (RPA) is a quite new word but not as a concept. If you’re a senior enough professional in the IT world, for sure you will remember the concept of Macro; that was one the first way to automate something manual and repetitive; still too difficult to use because of not being resilient and stable and too much tied to the hosting system.

Let’s move to another space of automation that is the back end development, delivering any kind of script that could be scheduled and run; this could automate much more operations but with one big constraint: not suitable for being used with interface-only tools.

We’re now approaching more recent years in which we saw the rise of automation suites like UiPath (and many others) and, together with it, the number of companies that tried to use RPA to reduce the personnel costs, improve efficiency, decrease errors and so on. I’m not a fan of the debate about RPA killing jobs and similar hence I’m not touching deeply the point; I simply just suggest the reader to acknowledge the existence of this problem and try to best fit into its working reality.

Back to the software part of automation: I am a company that wants to test this new automation toy. What should I do? Make or buy? Of course, this is always the question asked to the IT guy in the room. As always there is no valid answer for everyone: it depends on what you need to do, in which company area you need it and for how much time.

“Programming rules can be a nightmare in terms of complexity and maintenance and sometimes you will discover that the only way to save your day is to have a human aside”

I’m not opening the debate here, but I will just tell the final part of my story: I work in a company that decided to make (for many different reasons not always technology related) and as an IT guy I’m very happy of this decision. We had to possibility to break down the technology pieces and build our own automation suite, being sure to be able to control every single piece that we write. We could minimize the learning curve of new entries in the team, having new RPA developers ready to generate value in few weeks; we could interface many different systems that allowed us to bypass two factor authentication, captchas and anti-scraping technologies. We are saving a lot of manual and repetitive work for people that can now better focus on brain-activities; yet the investment in money and trust was relevant but it fully paid back in months (not years).

Ok, let’s now dig a bit better into techy stuff. One of the drivers of the make choice was the presence of a python development team already established; python is not only a top-class language for artificial intelligence (AI) and machine learning but also belongs to a huge community of developers and has a ton of open source libraries for doing back end and front end automation. One of those is PyAutoGUI that let you interact with physical screens, mouse, and keyboard. Moreover, python can be upgraded with many tools like schedulers, loggers, remote control capabilities and interfaced easily with your existing IT frameworks and architectures. Python can scale up very easily with virtualization, containers and can be linked to automatic code review and DevOps pipelines.

We’re right now in the situation in which your robot can just open a browser, read data pages, copy them somewhere else! An automagic data entry system is now working without human intervention… or it should! Remember that a robot is just piece of code hence its resilience depends on how you code is; the more details you consider the stabler it will be. Otherwise, you should have humans managing robots errors manually.

Robots are just code and as I said already, they’re as resilient as your code is but also depends on external systems; if you’re browsing an external site and its layout changes, you probably need to adapt you robot and, in the meanwhile, handle manually the robotic process that cannot find the green button with OK caption in the lower right corner. Robots work in a programmatical way, that’s it. Programming rules can be a nightmare in terms of complexity and maintenance and sometimes you will discover that the only way to save your day is to have a human aside. This is the case in which input data are ambiguous or too difficult to understand: “this email that I just copied contains a request that doesn’t contain a triggering keyword; shall I paste it in the complaints section or somewhere else?”

At the beginning I wrote about hyper-automation so here we are. If a human can do something with its brain then a machine, with enough data to be used as training set, can learn to behave as the human do. With mistakes of course! Suddenly you’re realizing that the human companion to your bot can be computer software called AI, creating a human like decision to help the bot to complete the task. Fallback of the fallback is a real human.

No gents, we’re not going to lose our jobs; we’ll just have less repetitive tasks and more food for brains. Remember that a robot and AI are code: someone needs to write them… for now!