Reviving Operations Research with AI
This article is my take on use of AI in the context of Operations Research (OR).
The problem
Here is the story from work. One of the leaders asked whether we could support production scheduling for one particular line that seems quite manual (excel-based) and heavily sub-optimal. Not to mention that whoever makes the plan, is all the time interrupted anyway (a raw material delay here, an urgent order there…). So the questioned popped up (as it typically does these days…) - can we do this job better with AI?
Of course we can!
…just not in the way everyone imagined (an AI agent coming in, figuring everything out on its own, and generating a perfect production plan).
What I recognized pretty quickly was the classic optimisation problem. A line that produces ~50 products a week and the need to optimize changeover time that is heavily driven by how the sequence of products (material similarity drives smaller changeover).
In the old days you would set up an optimization program: build some solver model, come back in a few weeks, show the theoretical results on paper with all the calculations, ask for the next step. Unfortunately while doing so, you would also experience people falling asleep the moment you start explaining the solver…
Approaching OR with AI
We knew we could implement the model with CP-SAT (Google’s open-source constraint solver). We knew there was a lot of tribal knowledge in the planners’ heads. And we knew that integrating the system to get data automatically would take some time. So we focused on one thing – build the best possible plan from the same ERP extract the planners already use today. But do it as fast as possible. And AI gave us the speed!
Week 1 – we proposed the concept and captured the key details about the logic. We also asked for the same data extract the planners are using to do the job today. Btw. zero enthusiasm at this stage…
Week 2 – we used AI (databricks notebook created with Genie + fancy html to display results created with Claude), to quickly spin up a working prototype based on real data and came back with a demo showing a nice line visualization with the actual plan (already optimized). The plan was far off from reality (missed few critical constraints), but people got intrigued (especially by the fact we based it on real data.. and btw the UI was stunning!)
Week 3 – we came back with a few critical patches to the model and showed that we can deliver the missing logic quickly. We proposed that from now on, we meet every week and come back with a new version, always comparing results to what the planners do. Everyone jumped on the train at this point!
Week 8 – after a few iterations the planners recognized that the latest version is already much more optimal vs what was done in the last 10 years. It also seemed like we implemented all the critical constraints - nothing felt off. We got ourselves real adopters!
But the part that actually won people over, was not the optimization. In fact the key point was the interruptions (raw material delay, business priority) as those were never a side problem. They were the job. So we modelled them. A delayed material delivery on Monday, or an urgent order that has to go in on Thursday – you put it in, and you get a new plan in seconds with the consequences visible. That is what made the planners want the tool - it was directly reflecting their operating reality. We just listened carefully and implemented what the planners needed (and lacked today).
The role of AI
AI did not figure out the plan here. CP-SAT did, and CP-SAT existed for many years. What AI changed is the implementation time – the model, the UI, every iteration. For me this story shows that we have a unique way to do real operations research again with much much better adoption. And we can do that because:
The time spent on implementing constraints and digitalizing business rules can be drastically reduced.
You can build a UI that is 100% aligned with the ways of working of the user. You can prototype any type of UI in days.
You don’t need a big team. One or two people, instead of an OR specialist plus a developer plus an analyst.
The requirements come out by themselves. Planners won’t list constraints in a workshop, but they will tell you exactly what is wrong when they see a concrete plan.
The solvers were free and good for years already (CP-SAT, OR-Tools). What was expensive was everything around them – data prep, UI, iterations.
I am not saying that OR will not get its own LLM niche, probably it will (btw. some intresting papers on OR-LLM can already by found in arvix). But as of today, whenever I am looking for pragmatic solution, I will not focus on LLMs or agents. I will continue to use proven methods from the past, but I will leverage AI to get them truly adopted. Fast.
Doing it the right way
Before you call me an irresponsible vibe coder – here are the top 5 rules I apply in the process:
The problem must be laser-focused. When you work on planning optimization, focus on just that. Don’t try to replace S&OP or MRP solutions. Otherwise you risk building a tool that would confuse more people in the organization than it will help.
Maintain very frequent business engagement. That’s the whole point – you can develop fast, so the true value lies in the immediate translation of tribal knowledge into a technical solution. You should also compare against the real human results as frequently as possible. This is the benchmark, and it is also how you build trust. For the first few weeks your job is to do the same job someone is doing the old way, and you just try to do it better.
Proof of value first, technology integration later. Don’t burn out on technology or integration at the beginning. Start with a manual extract from your ERP, as your business users are doing today. Later you may consider auto integration. Not to mention that you also need time to figure out your architecture before you start integrating the system with your enterprise IT landscape.
Anticipate minimal architecture from the very beginning. Put in minimal observability, make certain components configurable, invest in building you Claude environment. Don’t work in chaos otherwise no AI will help you.
Run a deeper solution refactoring session every 3-4 weeks until you reach your maturity. Your concept will evolve drastically, and because you build it fast, you will miss lot of foundation. And it’s important that you main codebase stays align with your latest vision and as soon as possible you achieve the state where you don’t need AI to do quick constraint coding. Otherwise thing will soon get out of control and you will lose your AI-gained speed anyway (or you won’t be able to truly productionalize the solution, because it will get so messy.)
(4) & (5) would probably require a little bit more deep-dive - I will plan dedicated article on those. For sure having someone with deep software engineering is important here.