In a previous article, I wrote about how AI is Changing the Economics of Prototyping. When prototypes become realistic enough to experience an entire system, they also become powerful tools for stakeholder alignment and project discovery. That experience made me think about a part of IT where we spend an enormous amount of time: operations.
As an IT director, one of the things I want to explore more systematically is where our teams spend time on operational tasks that are difficult to automate. Not the obvious repetitive tasks that can easily become scripts or workflows, but those tasks that happen once in a while, are difficult to document completely, and require someone with enough experience to understand what is actually going on.
A recent Odoo migration was a perfect example. I needed to migrate an Odoo Community installation from version 14 to version 18. I had installed the original system several years ago, but I had very little experience with this kind of migration. There are migration tools, repositories and tutorials available, and on paper the process looks quite straightforward. But anyone who has worked in IT operations knows what happens next: you follow the instructions, discover that your environment is slightly different, encounter an unexpected error, try to understand what is missing, change something, run it again... and repeat. The documentation may be good, but there is always some contextual knowledge that is not written down.
Instead, I gave OpenCode a simple instruction, pointing it to the existing Odoo environment and the community migration tools. It explored the repositories and documentation, understood the migration path and proposed a strategy based on Docker images for each intermediate version. It progressively migrated the data from 14 to 15, 16, 17 and finally 18.
As expected, things did not work perfectly on the first attempt. When it encountered a problem in Odoo 18 related to currencies and the database, it investigated the Odoo 18 repository and documentation, identified the additional configuration required, modified the environment and continued. It also performed checks throughout the process, comparing records and validating the results. What would probably have taken me around 10 hours of exploration, trial and error and troubleshooting took roughly 15 minutes.
The interesting part for me was not simply the time saving. It was the way the AI dealt with the knowledge gap. I did not have to know beforehand exactly what needed to be installed, which configuration was missing or why a particular error was occurring. The agent could explore that knowledge, build a plan, execute it, encounter problems and adjust its approach.
This is where I see an opportunity worth exploring in my day-to-day work. I want to spend more time identifying those operational tasks that quietly consume hours because they are difficult to automate conventionally. The goal is not simply to automate them. It is to recover time while capturing the knowledge generated during the process.
Today, much of this knowledge remains tacit: it lives in the experience of the person who performed the operation. Tomorrow, an AI agent may be able to use documentation, repositories, previous executions and the operational context to perform the task under supervision. In doing so, the execution itself can become a way of creating explicit, reusable knowledge.
For me, that is the real experiment: finding the operational tasks that steal our time, using AI to reduce that effort, and turning each intervention into knowledge that makes the next one easier.
The Odoo migration was just one small example. I know there are many more hiding inside the everyday work of IT teams.
Comments
Post a Comment