What I let an AI do in an HMI project, and what I don't.

An AI assistant is good at the part of HMI work nobody wants to do by hand. It knows nothing about your machine. The useful line between the two is whether you can check the result in one read.

The AI-assisted engineering page: the headline Let an AI assistant do the repetitive part, next to the diff that adds twelve alarms to the group Line faults.
One diff for twelve alarms. Every change comes back as a diff you can read. Anything destructive waits for a confirm.

NEXT HMI has a built-in MCP server, so an assistant such as Claude can edit a project the way you would in the editor. That raises the obvious question for anyone who has stood next to a machine during commissioning: what should you let it do? This is where I draw the line.

Where it earns its keep

Repetitive work you can check in one read. Forty alarms from the spreadsheet the mechanical engineer sent over. Twenty screens that differ only in the station number. Every string on a page moved into the translation table. In each case the assistant does an hour of clicking, and you spend five minutes reading a diff. That's the trade, and it's a good one.

Where I don't use it

When I can't follow the diff. If I can't tell why a binding changed, the change doesn't go in. Reviewing is the job; the assistant only moves the typing.

On a running machine without someone watching. A running project picks up a change at once and pushes it to every operator screen. That's what you want while building, and exactly why MCP writes stay off on a project that's in production.

To decide what the machine should do. Which faults deserve an alarm, which values an operator may write, what a fault means for the product: that's process knowledge. The assistant can type it in. It shouldn't make it up.

Why the limits sit in the server

A prompt is a request. A model can misread it, or be talked out of it. So the limits in NEXT HMI aren't instructions to the model. Writes are off for every project until someone ticks a box in the Manager. A token belongs to one project and is either read or write. Datasource connections are read-only, user credentials are never exposed, and starting, stopping, creating or deleting a project isn't a tool at all.

What an assistant may touch: read and write for pages, events, variables, alarms, translations and assets; read only for datasource connections, components and users, never credentials; never for starting, stopping, creating or deleting projects.
Read, write, read only, never. The full table, and how to connect an assistant, are on AI-assisted engineering.

One thing is worth saying plainly. The dry-run diff guards the assistant, not you: an assistant can ask for the diff and confirm it in the same turn without asking anyone. The checkbox is what stops writes. The full list of what an agent can touch is on AI-assisted engineering.

How NEXT HMI itself is built

NEXT HMI is built with an AI coding assistant, Claude Code, and the repository doesn't hide it: a CLAUDE.md and an operating manual for agents sit next to the code, along with a reviewer agent. The same rule applies as above. I read the diff of every change, the backend and frontend test suites and the linters run before it goes in, and the decisions about what the product does are mine. The assistant writes a lot of the code. It doesn't decide what it's for.

Where to start

Turn MCP on for a copy of a project, not the one on the floor. Ask for a read first, such as "list the pages", so a wrong address or token shows up before anything is written. Then try one of the four starter prompts. The MCP guide has the steps.

Sources: AI-assisted engineering for the limits and the starter prompts, the MCP guide for setup and token management.