Why vibe coding your production scheduling recreates the Excel problem

TL;DR

• Most production companies still sequence orders and operations in Excel, because the advanced planning software that could do it is too expensive to configure and too hard to understand.
• You can vibe code an optimisation algorithm for your factory with Claude or ChatGPT, and it may be a fraction of the code in a full planning suite.
• Vibe code the whole application and you recreate the Excel problem. One person who understands it, with maintenance, integration and security left unsolved.
• The working answer is to keep your IBP platform for everything that needs to be dependable and vibe code only the optimisation as a fenced building block inside it.

Picture a foundry. Castings go into a furnace at 1,000 degrees for two weeks. The furnace can hold four products if they share a temperature and a duration. Put one in instead of four and you have quadrupled the cost of that run. Now multiply that by 20 furnaces, casting days that only fall on certain weekdays, moulds that may or may not be free, and a workshop with 10 to 20 finishing steps after the heat treatment.

That factory plans most of it in Excel. Benjamin Obling, CPO of Perito IBP at Roima, has met them, and they are far from alone. In episode 28 of our S&OP MasterClass podcast, Benjamin and host Søren Hammer Pedersen take on the question we now hear in almost every planning conversation. If the software is that hard, why not just vibe code it?

Detailed scheduling is the step where production order proposals from MRP are placed in sequence, prioritised, and assigned to lines, factories and machines, operation by operation. Everything upstream may be working well. Then the proposals arrive and someone has to decide what runs first and where.

In the physical world that sequencing feels obvious. You cannot package a part before you have cast the iron it is made from. In software, every one of those rules has to be spelled out. Which orders can run together, what the setup times are, which customer matters most because their order ships with a bigger one.

Benjamin's rough estimate is that 80 to 90 percent of companies do this manually, and "at least more than half for sure". Software exists in abundance. Advanced planning tools are built to be configured for any optimisation task in the world. Configuring one for your factory becomes a very expensive project, and afterwards nobody can explain why the plan looks the way it does. The foundry above ended up using advanced software for parts of the job and Excel for the rest. A food producer with expiry dates to manage needs a completely different part of that same software, yet both carry the full code base and the full configuration burden.

A vibe-coded optimiser is an algorithm you build by describing your machines, operations, constraints and priorities to an AI assistant and letting it generate the code. Benjamin is clear that this works to a large extent. Instead of a huge application with a ton of configuration options, you get a small module written for your two or three specific problems. "It would be like 2% of the code base of the other one," he says.

The trouble starts when the module grows into an application. "You can build something that looks awesome in a few hours or a few days," Benjamin says. Getting it from there into something you would put into your supply chain is a different matter. How does the data integration work? How is the transformation from the ERP system handled, back and forth? What about security? And who fixes it when it breaks?

That last question should sound familiar. Companies running on Excel very often have one person who built the sheet and understands it, even in large organisations. As Benjamin puts it, "It's amazing what you can do in Excel and it's super awesome, but it's also super fragile and it's super people dependent. And it's exactly the same trap you'll end in with vibe coding."

The working answer is a split. Keep the integrated business planning platform for everything that needs to be dependable, and rip out only the optimisation itself.

The platform gives you the data integration to the ERP system, possibly several of them. It gives you the transformation layer, so lead times and routing data pulled from raw ERP tables arrive in the right units and nobody maintains them in two places. It gives you roles, rights and security, so you know who can see what. And it gives you the planner dashboards, adaptable screens where the plan is visualised, reviewed and released.

Inside that frame sits the building block. It has a clearly defined input, the production orders, the operations, the machines and their availability, the logic. It runs the optimisation, in Python inside our Perito IBP platform. Perito IBP is Roima's integrated business planning platform. And it hands back a clearly defined output, which production order, which operation, when it starts and when it ends. The platform takes it from there, back into the ERP system.

Rather than a new standalone solution, this is one building block placed into the planning ecosystem you already run. Benjamin adds the argument that settles it. If you vibe code the full platform, "you would have a supply chain planner doing software engineering already, that's probably not a good idea."

Even the simplest useful optimiser produces a plan that is too complex to review completely by eye. Several constraints, order priorities, OEE weighed against a delayed customer order, all at play at once.

So the planner's role shifts to overseeing and approving. That needs a good dashboard, and it needs a way to ask why. Benjamin's example is a furnace with three products in it and room for one more. Why did the algorithm leave it out? An AI embedded in the solution can answer that specific question, whether the reason is a frozen step, a different temperature, or a customer delivery that would be violated.

There is also a point where you should stop. Some rules, like which operator is better on a Monday morning, will never make it into an algorithm, and the data needed to encode them would cost more than the human decision. As Benjamin says, "stop before it gets overly complicated in any case."

There is a cheap way to test all of this. Benjamin's advice for anyone looking at a crazy software budget, or at a demo that looked too good, is to run a proof of concept. Strip the complexity down to something manageable, use your own data, and see how far you get in four weeks. If the answer is not far, find someone else.

The gap between what is possible in production scheduling and what actually happens is wide. Crossing it takes a small, well-fenced optimiser inside the platform you already trust, with a planner and an embedded AI on top. For more on that AI layer, see our feature on embedded and bolt-on AI in planning.

Frequently asked questions

Can you vibe code a production scheduling tool with Claude or ChatGPT?

You can vibe code the optimisation algorithm, and it may be a small fraction of the code in a full planning suite. Vibe coding the entire application, including data model, integration and security, recreates the one-person Excel problem in a browser.

What should the IBP platform provide around a vibe-coded optimiser?

Data integration to the ERP system, a transformation layer that puts routing and lead time data into usable units, roles and security, and adaptable planner dashboards. The optimiser only needs a clear input and a clear output.

How far should production scheduling be automated?

Stop when the complexity of encoding the next rule outweighs the labour it saves. Small judgment calls, such as who runs a line on a given morning, are faster for a human than for an algorithm.

What is a vibe-coded optimiser?

An optimisation algorithm generated by describing your machines, operations, constraints and priorities to an AI assistant. It handles the sequencing decision only, and leaves integration, security and the user interface to the platform around it.

• Specific angle covered: why vibe coding the whole scheduling application recreates the Excel trap, and the platform-plus-building-block split that avoids it.
• Primary query this feature answers: can we vibe code our production scheduling or detailed scheduling optimisation instead of buying advanced planning software?
• Relationship to cornerstone: no cornerstone blog is configured for Roima (Blog_Cornerstone is empty on the client record). This feature stands alone for E28 and extends the E27 supporting post on embedded vs bolt-on AI.
• Artwork prompt: editorial illustration of a small, precisely machined gear being lowered into place inside a large industrial control cabinet, warm workshop light, muted industrial palette, no text.