Why AI Coding Agents Change the SimPy vs. Simio Decision
AI coding agents can write much of a Python simulation for me. So more of my effort goes into defining the problem and checking that the model really works.
The old tradeoff is changing
A simulation is a computer model that lets you try a change to a factory or service before you make it for real. Simio and SimPy are two common tools for building one. Picking between them has usually started with one question: how much work is it to build the model? Simio gives you a point-and-click workspace made for the job. You place objects on screen and fill in their settings. Then you set up what flows through (entities, like parts or patients), what serves them (resources), their states and routes, and your experiments. SimPy gives you a smaller engine. You describe the system in Python code, as a set of processes (the steps work goes through). So in the past, Simio made sense when building fast on screen mattered most. SimPy made sense when the extra coding paid off, because you needed custom programming or links to other tools.
Coding agents change that tradeoff in a big way. They're AI tools that write and edit code from plain-language instructions. Give one a clear, detailed description of the system and it can write the resources, event steps, routing rules and experiment setup. It can also write tests, code that loads data, and a starting frame for the visuals. So the big question shifts. It's less about how fast I can learn where every option hides in the menus. It's more about how clearly I can define the system, poke holes in the model the agent wrote, and prove it works right.
Where my time goes has flipped
Here's how I think about the shift. It's my rough split of where the work goes, not a rule for everyone. In a visual tool like Simio, I might expect about 20% of the effort to go into requirements. That's working out what the model must do and how the real system works. About 50% goes into building and setting up the model. The last 30% goes into checking it, which engineers split in two. Verification checks that I built the model right. Validation checks that I built the right model, one that matches the real world. With a tool like Simio, the middle step eats a lot of attention. You have to know which object to use and which setting or state controls what. You have to know how resources and the things flowing through them work together. And you have to know how the tool expects you to write the logic.
With SimPy and a good coding agent, I'd aim for something closer to 30% requirements, 20% building the model and 50% checking it. The agent squeezes down a lot of the routine coding. But I don't want that saved time to just vanish. I want it to move earlier, into better requirements, and later, into tougher checking. To be clear, those percentages are my own rule of thumb, not measured industry averages. The real split will depend on how complex the model is, how experienced the team is and how much checking the job demands.
Why this tips things toward code
People trust a simulation when it matches the real system they're making decisions about. How fast you snapped the blocks together doesn't matter. When an agent can quickly turn clear requirements into Python, code becomes a cheaper way to build the model. And everything in it is out in the open: steps, resources, waiting lines (queues), priorities, breakdowns and routing rules. So are the random patterns for things like arrival times (distributions). You can read all of it as plain code. You can review each change line by line, since a 'diff' shows exactly what changed. And you can test it with the same everyday tools software engineers use.
It also makes the model easier to look after over time. Each requirement can be tied to a piece of code, a test or a what-if case. Edge cases, the odd situations at the extremes, can become regression tests. Those run every time the code changes, to catch anything that breaks later. Version control keeps an exact record of every change. Outside reviewers can check both the code and the evidence that it matches reality. So coding with agents doesn't make simulation know-how useless. It means more of the engineer's job is understanding the real system, designing good experiments and checking the work.
Connecting to other tools is where SimPy pulls ahead
A simulation rarely has to sit off by itself. A Python model can plug straight into databases, data-processing code, optimization models, statistics tools, machine learning and APIs. An API is a doorway that lets one program ask another for data or actions. The model can even offer an API of its own. It can run in the background on a schedule, with no screen at all. It can try a whole range of settings in one go. It can save a full log of every event and feed a custom web page. And none of that needs anyone to export and import files by hand.
Working with agents opens up even more connections. MCP servers are a standard way to plug an AI agent into other tools. With one, an approved agent can reach things like data layouts (schemas), documentation, experiment results or other company tools. APIs can link the model to other apps and to the systems that coordinate many programs. A database connection can make every what-if case start from saved inputs you can rerun. It can also make every result traceable to where it came from. SimPy's edge isn't a prettier screen. It's that the simulation can become a normal piece of software that snaps together with other pieces.
Spend the saved time on checking
Building faster is dangerous if it also means trusting faster. An animation that looks right doesn't prove the model is right. So I want to spend the extra checking time on the basics. Does every job that comes in either leave or stay inside, with nothing lost? Are people in line served in the right order? Does each resource stay within its capacity? Do events happen in the right sequence? Does the model act sensibly while it warms up from empty, and does it stop when it should? Are the random draws handled right, including the seed (the starting number the computer uses to make them)? What happens in extreme cases? Textbook formulas make good cross-checks too, where their assumptions match the simulation. Little's Law links how much work is inside, how fast it finishes and how long it stays. Erlang C predicts waits in a line with several servers.
I also want tests of whole scenarios where I already know what should happen. If zero customers arrive, zero should come out. With practically unlimited capacity, nobody should wait in line. In a stable system, adding service capacity and changing nothing else shouldn't make things consistently worse. Rerunning with the same fixed seed should repeat the exact same run. And for simple toy systems with known textbook answers, the results should get closer to those answers as you run enough repeats. Coding agents can help write these tests. But the engineer has to decide what counts as convincing evidence.
What Simio still does really well
I'm not saying Simio is out of date. A mature visual tool for discrete-event simulation (DES) can be excellent. That's the kind of simulation that jumps from one event to the next, like an arrival or a finished job. A tool like that is great for quickly showing a model to the people who have a say in a decision. It has animation and experiment tools built in. And it suits teams whose way of working is already built around its blocks. A point-and-click screen also lets reviewers who don't want to read Python see how the model fits together. And since so much comes built in, a team has less tech setup of its own to build and look after.
My point is narrower. Building a simulation in code used to take a lot of extra effort. Coding agents remove a big chunk of that cost. That moves the line where SimPy becomes worth it for me. This matters most when a project has to connect to other tools, APIs or databases. It also matters when you need automation, version control, custom charts and numbers, or a way to ship the model as real software.
The engineer's job moves up a level
The biggest change isn't 'AI writes the simulation.' It's that writing code gets cheaper compared to thinking. So more of my attention can go to the thinking. What flows through the system, and where does the model stop? Which random patterns best describe things like arrival times? How should limits on people and machines be built in? Which real-world causes actually matter? How should the experiments be set up? Why did the model do something unexpected? And how do I earn people's trust in it?
That's where I want simulation work to go. I want requirements clear enough that people and agents can both build from them. I want models that others can review as code and combine with other pieces. And I want checking strong enough that building fast doesn't mean making mistakes fast. Better coding agents make SimPy more appealing for exactly this reason. They let the engineer spend less time running the modeling tool and more time engineering the model.