Natural-language robot programming moves the risk from writing code to approving it. The review screen is now the most important flow in the HMI.
Many AI robot programming demos end the same way. Someone types or says a task in plain language, code appears, and the robot moves. The audience claps at the prompt box.
I think the audience is clapping at the wrong screen.
The International Federation of Robotics reported in September that the operational stock of industrial robots reached a record 5 million units in 2025, with more than 600,000 new units installed over the year. In a position paper on AI released in early 2026, the IFR said generative AI is changing the programming process by creating code for entire functions, as The Robot Report summarised it. ABB has added a generative AI assistant to RobotStudio that interprets natural language and answers questions from ABB's manuals. Inbolt announced CAD-based robot programming for its Automate 2026 stand in Chicago and pitched it bluntly: "No teach pendant."
Writing a robot program is getting cheap. Checking one is not. That shifts the hardest interaction design problem in the cell from authoring to approval, and in my view most robot HMIs are not yet designed for it.
95 percent is a design brief, not a success story
The most useful recent data point I have found comes from the Chair of Production Systems at Ruhr University Bochum. In April 2026, Daniel Syniawa, Levin Droste and Bernd Kuhlenkötter published a two-stage LLM pipeline in the journal Robotics. Stage one turns a natural-language task into structured process steps. Stage two turns those steps into code that runs on ROS 2 and MoveIt 2, with cell and product data supplied through AutomationML. They tested it in simulation on terminal block assembly for electrical cabinets.
The headline is a success rate of up to 95 percent. With Claude Sonnet 3.7, 57 of 60 simulation runs succeeded. The locally run open-source models did far worse: Llama 3.1 70B reached 24 of 60, DeepSeek-R1 32B reached 38.3 percent, and Qwen3-coder 30B produced zero error-free runs. On a physical ABB IRB 120 running two simple cube tasks, one task (stacking and colour sorting) succeeded in 4 of 5 runs and the other (creating diagonals) in 5 of 5.
Figure 1. Share of error-free simulation runs out of 60 per model. Source: Syniawa, Droste and Kuhlenkötter, Robotics 15(4), 79, 2026.
Read that as a designer, not as a buyer. Even the best model got 3 runs in 60 wrong. A cell runs a program thousands of times. A 1 in 20 failure at generation time is acceptable only if the review step reliably catches the one bad program before it reaches the controller.
The authors seem to know this. Their workflow is not "prompt and run." Generated code is evaluated in simulation, and the results feed back into refinement. A graphical interface shows intermediate results and lets the user intervene manually. The system tells the user when required data is missing or when a request is invalid. In the physical test, the user reviews the code in simulation before it is transferred to the controller. They also warn that weaker models would need multiple verification rounds and substantial coding expertise from the operator, which could make manual programming nearly as efficient.
That last point matters. If the review step demands an expert, you have not removed the expert. You have moved them to a worse screen.
The approve button is where the bias lives
Here is the uncomfortable research behind that worry. None of it comes from robotics, but all of it maps directly onto a robot HMI.
In a Stanford study presented at ACM CCS 2023, participants with access to an AI coding assistant "wrote significantly less secure code" than those without. They were also "more likely to believe they wrote secure code." Worse output, higher confidence.
At CHI 2021, Gagan Bansal and colleagues tested whether explanations help people and AI work better together. Explanations "increased the chance that humans will accept the AI's recommendation, regardless of its correctness." A tidy explanation panel next to the generated program can make approval more likely without making it more accurate.
The counterweight is a 2021 study led by Zana Buçinca and Krzysztof Gajos at Harvard, with Maja Barbara Malaya (N=199). They designed "cognitive forcing" interventions that make people engage with the problem before or while seeing the AI's answer. These "significantly reduced overreliance" compared with simple explainable AI. The catch: people gave the least favourable ratings to the designs that reduced overreliance the most.
Figure 2. AI-generated illustration. The review moment is a design surface in its own right, not a formality at the end of the flow.
Put those three findings together and you get a clear design rule. The review screen that feels smoothest in a usability session is probably the one most likely to wave a bad program through. If your design goal is "operators liked it," you will optimise for the rubber stamp.
The regulation moved. The oversight brief did not.
For a while, the EU AI Act looked like it would force this issue for machine builders. Article 14 requires high-risk AI systems to be designed "including with appropriate human-machine interface tools" so that people can effectively oversee them. It spells out what those people must be able to do: understand the system's capacities and limitations, detect anomalies, "remain aware of the possible tendency of automatically relying or over-relying on the output," correctly interpret the output, disregard, override or reverse it, and interrupt the system through "a 'stop' button or a similar procedure that allows the system to come to a halt in a safe state."
Then, in July 2026, the Digital Omnibus on AI (Regulation (EU) 2026/1744) moved the Machinery Regulation from Section A to Section B of the AI Act's Annex I. Law firm DLA Piper summarised the effect: "AI-enabled machinery is removed from the direct application of the AI Act's high-risk regime." Machinery AI now follows a sectoral route through the Machinery Regulation, which applies from 20 January 2027 and already covers machinery with AI-powered safety functions.
I am not a lawyer, and your notified body and legal team decide what applies to your product. But I would not read the Omnibus as permission to relax. The legal route changed. The physics of an operator approving a program they did not write did not. Article 14 (4) is still the best one-paragraph spec for an AI review screen I have read: understand, notice, interpret, override, stop. If you design to it now, you will not be redesigning when the sectoral rules catch up.
Five layers of a review screen that actually reviews
This is the pattern I would use for any flow where AI generates or modifies a robot program, whether it is a natural-language assistant, CAD-to-path generation or an AI-suggested fix after a fault.
Figure 3. A five-layer review flow for AI-generated robot programs, from stated intent to a staged first run. Framework by Leon Potgieter.
1. Restate the intent before showing any code. Show the operator what the system understood, as numbered process steps in their own vocabulary: pick from fixture A, place on rail position 3, repeat for 12 parts. This is the Bochum paper's stage one, made visible. In my view, a wrong step is far easier to spot in plain language than in 200 lines of robot code, and interpretation is exactly where a language model can drift.
2. Show the diff, not the program. If a program already exists, the question is never "is this program correct?" It is "what changed, and do I want that change?" Highlight changed targets, speeds, tool data and I/O. Treat unchanged lines as context, collapsed by default.
3. Show it in space. A program is a path through a physical cell. Show the planned motion in the cell model with reach, zones and the positions that changed. In my reading, simulation does the heaviest lifting in the Bochum workflow, and it is the review tool that does not require the reviewer to read code.
4. Surface what the AI assumed or could not find. Missing data, invalid requests and assumptions deserve their own panel, ahead of the code. "Gripper offset not found in cell data, default used" may be the most valuable line on that screen. The Bochum system already notifies users about missing data and invalid requests. Make that a first-class panel, not a log entry.
5. Force one specific check, then stage the first run. This is where the Buçinca and Gajos result earns its place. Before approval, ask the operator to confirm the riskiest single item, chosen by the system: the new place position, the changed speed, the I/O signal that opens the gripper. Not "Are you sure?", which trains people to click. A specific question about a specific value. Then run the first cycle in a staged mode your safety concept allows, and only then mark the version as approved.
Throughout all five layers, two controls stay visible and never move: reject the change, and stop.
A checklist for your next AI programming flow
Use this in your next design review or usability test plan:
Intent first. Does the operator see the interpreted task steps in plain language before any code?
Diff by default. Can the operator see what changed from the last approved version, in under ten seconds?
Spatial preview. Is every changed target shown in the cell model?
Assumptions panel. Are missing data, defaults and guesses listed separately, above the code?
Targeted confirmation. Does approval require answering one specific question about the riskiest change, rather than a generic confirmation dialog?
Staged first run. Is the first execution of a new AI-generated version treated differently from routine runs?
Override and stop. Are reject and stop always visible, and does stop bring the cell to a safe state?
Test the failure. In usability testing, do you seed a wrong program and measure whether participants catch it? Satisfaction scores alone will reward the rubber stamp.
The last item is the one teams skip. Testing an AI review screen only with correct programs tells you nothing about whether it works.
The prompt box is the demo. The review screen is the product.
Natural-language programming will make robots easier to set up, and I think that is good for the industry. But the value is not in the moment code appears. It is in the moment a person decides that code is allowed to move steel around a shop floor.
The vendors and integrators who win this shift will not be the ones with the smartest prompt box. They will be the ones whose review screen makes a wrong program obvious to a tired operator at the end of a shift. That is an interaction design problem, and it belongs on the HMI roadmap now, not after the first near miss.
Sources
- IFR, "Five Million Robots now Operate in Factories Globally" (24 September 2026)
- The Robot Report, "IFR releases position paper on AI in robotics" (17 February 2026)
- ABB, "ABB Robotics adds generative AI assistant to RobotStudio"
- Perry et al., "Do Users Write More Insecure Code with AI Assistants?", ACM CCS 2023
- EU AI Act, Article 14, AI Act Service Desk (European Commission)
- Regulation (EU) 2026/1744 (Digital Omnibus on AI), EUR-Lex
