Can AI build, test and debug machine software itself?

Machine software is normally developed in separate steps. An engineer reads the requirements, writes the PLC code, configures motion, builds the project and tests parts of the solution. Later the software meets the mechanics. Only then are some of the assumptions behind the program challenged by the actual machine.

AI lets us connect more of those steps. At neexo, we can already give an engineering agent access to much more than a source file. It can work with existing machine software, company architecture and libraries, PackML, motion, HMI, I/O, technical documentation and information about the machine the software must control. It can build the project, continue after compiler errors, run against a virtual machine, analyse traces and use the result in the next iteration.

A normal coding assistant can explain a function block, suggest Structured Text or help with a compiler error. That is useful, but the machine does not exist in code alone. A sequence can be correctly programmed and still be wrong for the mechanics. A motion profile can be configured correctly and still leave too little time for the next process. A signal can be handled correctly in the PLC while the electrical documentation describes a different intent. A fault-recovery sequence can work in a normal test and fail when downstream is stopped.

When the agent also has mechanical and electrical context, it can connect the software to the system it must control. Information can flow both ways: requirements and engineering data, implementation, build, virtual test, measurements and traces, analysis, change and retest. After physical startup, data from the real machine can enter the same process.

Yes, when the agent has a clear software architecture and the tools it needs. PLC software at a machine builder rarely starts from a blank page. There are existing principles for structure, naming, machine modules, modes, alarms, diagnostics, HMI and motion. Many companies also have libraries or previous projects that show what a good implementation should look like.

That gives the agent a much stronger starting point than a generic prompt to write PLC code. The task can instead be to implement a new transfer station according to the company's existing machine standard.

The agent can work with the station's states and transitions, PackML integration, behaviour in Automatic and Manual, interlocks, alarms and HMI status. If the station contains servo axes, the same task can include enable, homing, positioning, limits, fault states and the motion functions used by the project architecture.

It can also connect the station to the surrounding machine. When may upstream deliver a product? When is downstream ready? What happens when a product is missing? How does the module return to a known state after a stop?

This depends on good standards. An unstructured codebase does not become good machine software simply because an AI can access it. Reusable architecture, clear interfaces and consistent principles become more valuable when people and agents work in the same project.

The first feedback loop is simple. The agent changes the project and builds it. If the build fails, it receives the compiler output, finds the cause, makes a change and builds again.

A PLC project that compiles does not tell us whether the machine behaves correctly. The agent can therefore continue into a digital test environment where the actual machine logic runs against a model with the relevant mechanics, sensors, actuators, product flow and motion.

Take a transfer station as an illustrative example. The station receives a product, positions it and hands it on. The normal sequence is only the beginning of the test. The agent can also test what happens when downstream never becomes ready, a sensor changes later than expected, a product is missing, a movement is interrupted or the machine is stopped in the middle of a transition. After each change, the relevant scenarios can run again.

An engineer no longer has to choose between spending time on implementation and running a long set of repetitive regression tests. The agent can perform much of that repeated work while the engineer defines architecture, test intent and the boundaries the solution must respect. Testing becomes a continuous part of development rather than something that receives full attention only close to FAT.

Most tests start with a known expectation. We know a sensor can fail, so we test the sensor failure. We know downstream can stop, so we test a stop. We know about an earlier fault in recovery, so it becomes a regression test. That still leaves the problems nobody thought to ask about.

When the agent can read traces and machine data, it can inspect a run for deviations instead of checking only a predefined pass or fail result. A test can pass while something interesting has still changed.

An axis takes longer to accelerate. Torque looks different from the reference run. A state remains active slightly longer. A sequence waits more often for a particular handshake. Fault recovery takes a different route through the program. None of these observations is automatically a defect. They are signals the agent can investigate.

The agent can return to the software change, compare earlier traces, inspect motion parameters and test whether the change is related to other parts of the machine. The test plan still matters, but it is complemented by an agent that can look for behaviour we did not write into the test plan in advance.

One of the main limitations of a code-only agent is that it naturally looks for the explanation in software. Real machine problems do not respect that boundary.

If an axis arrives late, the sequence may be wrong. The cause may also be the motion profile, a changed mechanical load or a signal that arrives later than expected. With access to the wider context, the agent can separate those possibilities more effectively.

Imagine a trace showing that a movement now takes longer than in earlier tests. The agent can check whether the PLC start time changed. If it did not, it can compare the speed and torque curves, then relate the measurement to the mechanical configuration and the relevant project changes.

AI cannot diagnose every physical fault by itself. It can, however, combine information that is normally split across automation, mechanics, electrical engineering and commissioning and use it in the same investigation.

Before physical startup, the agent can work against the simulation. After startup, the same logic can be supplemented with traces and measurements from the real machine. The difference between expected and observed behaviour becomes new input to the engineering process. The simulation can therefore act as a reference for expected machine behaviour, not only as an environment for testing before FAT.

The agent does not need to stop and ask a user after every compiler error or failed regression test. A large part of the loop can run autonomously: implementation, build, test, trace, analysis, change and regression test.

There should still be clear boundaries around actions that affect the physical machine or change important engineering assumptions. An agent may conclude that a motion profile should change. That is different from automatically sending the new profile to a production machine and moving the axis.

A practical architecture therefore changes where approval is required. A person does not need to approve every small operation. Gates make more sense around safety-related behaviour, deployment to physical equipment, new movement limits and other changes with real physical consequences.

For an engineering manager, the useful question becomes: Which actions may the agent perform and verify on its own, and which changes require engineering judgement or physical approval? That is more useful than a general discussion about whether we trust AI.

Technical documentation has a recurring problem: it is often written after the work. By then, the code can show what the solution does but rarely tells the whole story of why it ended up that way.

Why is this interlock here? Why was this motion profile selected? Which test caused the change? Which alternatives were tried? What did the trace show?

When the agent has participated in the engineering loop, much of that information already exists. It has seen the requirement, implementation, build results, test scenarios, traces, changes and subsequent regression tests. It can document the decision from the process that actually took place.

Documentation can link code and parameters to their engineering rationale. It can explain which situation a change was meant to solve, what evidence supported it and which tests were run afterwards. Service can see the background, a new engineer can understand why the code looks the way it does, and the next machine project can reuse both the implementation and what was learned during testing.

As implementation becomes cheaper, the quality of requirements, architecture, constraints and test intent becomes more important. The agent needs to know what good software means in your company. It needs a machine architecture to work within and must distinguish between a harmless software change and a change that requires physical validation.

AI can take over more of the repetitive work between those decisions: creating software modules, fixing build errors, running regression tests, comparing traces, checking interfaces and keeping documentation current. The result should not be measured only in programming hours removed. A more useful measure is how much additional engineering and verification the team can complete within the same project time.

Do not start with the whole machine. Pick a clearly scoped machine module with a real PLC function, clear interfaces and behaviour that can be tested digitally. It could be a transfer, a process station or a motion module. Give the agent the existing standard and the tools it actually needs. Let it implement a clearly scoped change, build the project and run a known test set.

The loop can then expand with more regression testing, traces, mechanical and electrical context and eventually feedback from the physical machine. An engineering agent should be judged by whether it can deliver a change that builds, behaves correctly, passes the relevant tests and leaves an understandable record of why the solution looks the way it does.