When AI Writes the Code, What Becomes the Model?

Picture a mobile machine during testing.

An experienced operator makes a movement and notices something immediately. It feels a little too aggressive. Perhaps it overshoots slightly before settling, or the transition does not feel as smooth or predictable as expected.

A control system engineer looks at the implementation.

Not long ago, trying another approach could require a significant amount of work: study the problem, modify the algorithm, review the change, compile it, deploy it, find another machine test slot, and ask the operator to reproduce the situation.

Now the first part of that process can look quite different. The engineer may ask an AI coding assistant to propose a modification that reduces the overshoot, smooths the transition, or takes a different structural approach. A plausible alternative can appear quickly.

That implementation is not automatically correct. It still needs to be understood, reviewed, and verified. But producing the next candidate may no longer be the slowest part of the loop. AI assistance increasingly extends beyond implementation as well. Tools can help create tests, suggest edge cases, analyze failures, and work with test results.

So the interesting change is not simply that we can write code faster. More of the engineering experiment can potentially become faster.

Faster code does not tell us which code is better

Suppose we produce three alternative implementations. One reduces the overshoot but makes the machine feel sluggish. Another settles quickly but introduces more aggressive acceleration. A third stays close to the original behavior while removing the sharpest part of the transition.

Which one is better?

There is no answer hidden in the source code. The answer depends on intent: performance targets, safety constraints, mechanical limitations, energy consumption, operator comfort, and probably several other considerations.

Some of that intent is captured in requirements. Some may be represented in models and tests. Some exists as engineering knowledge that has never been formally written down. And sometimes an experienced operator notices something that none of them captured.

If an operator says, "This doesn't feel right," even though the existing checks pass, that observation should not simply be dismissed. It may expose a missing requirement, an incomplete test, or behavior that the current model does not represent sufficiently well.

Code is executable, but that does not make code the definition of correct behavior.

Short feedback loops are not new

Control system engineers already have mature ways of learning about behavior before or alongside testing the final machine. Model-Based Development, Software-in-the-Loop, Hardware-in-the-Loop, virtual controllers, and many other forms of simulation exist precisely because experimenting directly on the physical system can be expensive, slow, or difficult to repeat.

There are also development environments where the feedback loop can already be very short. Engineers working with PLC environments such as CODESYS are often accustomed to changing logic, downloading it, and observing what happens on the machine during commissioning. That immediacy can be extremely useful.

Teams moving more functionality into C or C++ can lose some of that feeling if the development process becomes edit, compile, deploy, and wait for access to the machine. Simulation offers another possibility: move some of that exploration away from scarce machine time while keeping a short feedback loop around the implementation.

AI does not invent that idea, and it does not make established simulation and testing methods obsolete. What it may change is how frequently and cheaply we can move around the loop.

But changing the code is not the only experiment

We do not necessarily need to modify and recompile the control algorithm every time we want to learn something.

If inputs, parameters, and test conditions can be supplied externally, the same snapshot of the implementation can be executed repeatedly under different conditions. Instead of asking only "Can I simulate this implementation?" we can start asking "Which parameter values produce the behavior we want?"

We can run parameter sweeps, try different input sequences, compare results, and optimize against measurable objectives without rebuilding the control algorithm for every experiment. The implementation remains fixed while the experiment around it changes.

That can make a surprisingly large difference. Once an experiment becomes cheap enough to repeat, we naturally start asking questions that would have been impractical if every attempt required another build, deployment, and machine test.

Real machine data can make the experiment more meaningful

Recorded machine data gives us another way to tighten the loop.

Suppose we have logs from a real machine showing inputs and measured responses during a particular movement. Instead of immediately modifying the controller until the simulated result looks better, we can first ask a different question:

Does our simulation reproduce what actually happened on the machine?

If it does not, the limiting factor may not be the control algorithm. Perhaps the representation of the plant is too simple. Perhaps a delay is missing. Perhaps an assumption about the dynamics is wrong.

Measured behavior can provide an anchor while we improve the simulation context until it represents the behavior we care about well enough for the engineering question in front of us. It does not need to become a perfect representation of the entire machine. And a model fitted to one set of logged data should still be challenged against other operating conditions and independent data rather than assumed to be universally valid.

Once the simulation context is credible enough for the question we are asking, we can start changing the controller and exploring alternatives with more confidence that the observed differences are meaningful.

This creates another iteration loop. We are not only iterating over code. We can iterate over parameters, inputs, assumptions, and the simulation context surrounding the code.

Different questions need different evidence

None of this means every control problem can be solved with a simple simulation.

Sometimes a generated input sequence and a plot are enough. Sometimes recorded machine data provides the missing context. Sometimes we need a plant model, Software-in-the-Loop, Hardware-in-the-Loop, or a more detailed simulation. And for many questions, we still need the real machine.

Real-machine testing also depends on something that is easy to underestimate: access to the right people. An experienced operator may be able to reproduce or evaluate behavior that a control system engineer cannot. The operator knows how the machine feels under load, which combinations of movements expose a problem, and when a response that looks reasonable in a graph simply does not feel right from the cab.

The objective is not to replace that stage. It is to arrive there having already learned as much as we reasonably can, so that valuable machine and operator time can be used for the questions that genuinely require them.

These approaches are not competitors. They provide different kinds of evidence. The engineering task is to understand what question we are trying to answer and what evidence is sufficient to answer it.

The experiment can become cheaper

That may be the more consequential change.

AI can make producing another implementation cheaper. External parameters and inputs can make another simulation run cheaper. Recorded data can make a real situation easier to reproduce. A simulation context can let us investigate that situation repeatedly without occupying the machine. AI can increasingly help create experiments, explore alternatives, and interpret the resulting data.

None of these things determines what the machine should do.

Requirements still matter. Models still matter. Tests still matter. Engineering judgment still matters. And the operator who says, "No, that still doesn't feel right," may still provide the most valuable piece of information in the entire experiment.

What changes is the cost of asking the next question.

The opportunity is not merely to write control system software faster. It is to shorten the loop between intent, implementation, behavior, and evidence—and to learn faster about the system we are actually building.