Let AI do automation projects for you

Article#: 00126

Date: 2026-10-02s

Author: Radim

When we talk about using AI (artificial intelligence) in programming today, we often focus on individual programming tasks. We let AI write a piece of code. Explain an error. Modify a function. Create a test. Write documentation. All of that is useful.

But I am not thinking about "small" programming tasks here. Maybe we should stop focusing only on how AI can help us with a project and start thinking about how to define the project well enough that AI can do it for us.

This requires a slightly different way of thinking. Instead of: "I do the project. AI helps me." we can gradually move towards: "I define the project so that AI can implement as much of it as possible."

A software department in automation usually does not design the entire machine from scratch. By the time a project reaches a PLC or HMI programmer, much of the information already exists. The process engineering department has defined the technological process and machine functionality. The electrical engineering department has designed the electrical equipment. There are electrical schematics, pneumatic schematics, hardware, I/O, drives, sensors, valves, and safety components. In addition, there are company standards, existing libraries, coding guidelines, HMI rules, interface definitions, and many other sources of information. The programmer creates the software from this information. A large part of the work therefore consists of processing, interpreting, and translating information that already exists within the company into working software.

Fertile ground for AI:

We cannot simply take a chaotic engineering process, add AI, and expect a miracle.

Project information is often fragmented and not easily accessible. Some of it is in the specification. Some in the electrical schematics. Some in Excel. Some in PDFs. Some in the PLC project. Coding guidelines are somewhere else. Other rules are known only by experienced colleagues.

Someone who has worked at a company for several years gradually builds up this context. They know where to look, whom to ask, and which information matters. But if we want to hand over a large part of the work to AI, we somehow have to make this context accessible to it.

It is not enough to bring AI into our existing engineering process. We need to prepare the engineering process for AI. AI cannot fix the fact that we do not know what we want ourselves.

We need to know WHAT - what the result should be.

We need to understand WHY - why we need it.

And we need to define or constrain HOW - how the solution should be implemented.

The more knowledge remains only in people's heads or in the company's unwritten practices, the more difficult it is to hand work over to AI.

Work is easiest to automate when we understand it well. Ideally because we have already performed it manually several times. Then we know not only the normal workflow. We also know the exceptions, problems, and decision points that may arise along the way. And it is precisely this experience that we need to turn into information and rules that AI can work with.

The more work we want to hand over to AI, the better we need to define what we want. Including things that may seem completely obvious to us. Unclear requirements have always been a problem. AI will not eliminate that problem. On the contrary, it can very quickly produce a large amount of work based on poorly or incompletely defined requirements. Good engineering principles do not become obsolete with AI. They become even more important.

Is our engineering tool ready for AI?

For a long time, engineering tools have been optimized for working with a mouse. Maybe it is time to start optimizing them for programmatic access as well. A tool optimized for manual human interaction is not necessarily a good tool for automating work. Can AI access this tool programmatically and work with it through an API?

And how do we know the result is correct?

Generated software is not yet a finished project. If we want to hand implementation over to AI, we need to be able to verify that the result actually meets the requirements. Ideally, we should also be able to trace the relationship between a requirement, an architectural decision, the implementation, and the test that verifies the result.

AI also cannot be a one-way production line where we put requirements in at one end and a finished program comes out at the other. During implementation, new questions, problems, and situations will emerge that nobody anticipated during specification. This information needs to flow back to the person who has the authority to decide whether the requirements or the solution need to be changed.

AI is not just a tool for faster programming. If we want to use its full potential, we need to change the way we prepare and implement automation projects. This will allow us to gradually hand over larger and larger parts of the work.

Related previous articles:

User:

Log in user:

Log in user:

Log in user - Failure:

Log in user - Failure:

Request password:

Request password:

Request password - Failure:

Register user:

Register user:

Register user - Failure:

Register user:

Register user - Failure:

Register user:

Register user - Failure:

Register user:

User settings:

User settings:

User settings:

User settings: