End-user robot programming grants users the flexibility to re-task robots in situ, yet it remains challenging for novices due to the need for specialized robotics knowledge. Large Language Models (LLMs) hold the potential to lower the barrier to robot programming by enabling task specification through natural language. However, current LLM-based approaches generate opaque, "black-box" code that is difficult to verify or debug, creating tangible safety and reliability risks in physical systems. We present RoboCritics, an approach that augments LLM-based robot programming with expert-informed motion-level critics. These critics encode robotics expertise to analyze motion-level execution traces for issues such as joint speed violations, collisions, and unsafe end-effector poses. When violations are detected, critics surface transparent feedback and offer one-click fixes that forward structured messages back to the LLM, enabling iterative refinement while keeping users in the loop. We instantiated RoboCritics in a web-based interface connected to a UR3e robot and evaluated it in a between-subjects user study (n=18). Compared to a baseline LLM interface, RoboCritics reduced safety violations, improved execution quality, and shaped how participants verified and refined their programs. Our findings demonstrate that RoboCritics enables more reliable and user-centered end-to-end robot programming with LLMs.
Figures & tables
Figure 1. We introduce RoboCritics , an approach that augments LLM-based robot programming with expert-informed critics, automated fixes, simulation, and physical execution. Critics analyze motion-level execution traces to detect safety and performance issues, surfacing transparent feedback and enabling iterative refinement through one-click, automated fixes while keeping end users in the loop. The workflow begins with Conceptualization stage then connects to Specification stage by chatting with LLM in natural language. The LLM's generated code then enters the Verification stage, where expert-informed critics analyze the motion-level execution traces. The user then moves to Validation stage via simulation. If not satisfied, the user goes back to Specification stage. If the program is verified, the user is ready for Deployment stage on the physical robot, ensuring the user remains in control throughout the iterative refinement cycle.
Figure 2. RoboCritics workflow: (1) The user begins by providing a high-level task description. (2) The LLM generates a corresponding robot program. (3) The program is executed and evaluated against user-selected critics based on the resulting trajectory. (4) Feedback and results are stored in the interaction memory. (5) The LLM uses RAG to refine the program. (6) The refined program incorporates critic feedback. (7) The user validates the improved program via simulation. (8) Once verified, the final program is stored for future reference. (9) The validated program is deployed to the physical robot. \oursysworkflow: (1) The user begins by providing a high-level task description. (2) The LLM generates a corresponding robot program. (3) The program is executed and evaluated against user-selected critics based on the resulting trajectory. (4) Feedback and results are stored in the interaction memory. (5) The LLM uses RAG to refine the program. (6) The refined program incorporates critic feedback. (7) The user validates the improved program via simulation. (8) Once verified, the final program is stored for future reference. (9) The validated program is deployed to the physical robot.
Figure 3. User interface of RoboCritics : The panel on the left hosts a chat interface (a) for natural language interaction with the LLM agent. Users can chat by sending a message (i). The center panel exposes critics (b) allowing users to inspect and verify the generated program before execution. Users can activate critics by selecting them (g) and also fix the issues raised by critics by pressing the fix button (f). After selecting critics, users can execute the generated code by pressing “Run Code” button (d). The terminal shows the feedback from the selected critics (h). The panel on the right displays a simulation (c) of the generated robot program, allowing users to play and replay the execution as needed (e). User interface of \oursys: The panel on the left hosts a chat interface (a) for natural language interaction with the LLM agent. Users can chat by sending a message (i). The center panel exposes critics (b) allowing users to inspect and verify the generated program before execution. Users can activate critics by selecting them (g) and also fix the issues raised by critics by pressing the fix button (f). After selecting critics, users can execute the generated code by pressing ``Run Code'' button (d). The terminal shows the feedback from the selected critics (h). The panel on the right displays a simulation (c) of the generated robot program, allowing users to play and replay the execution as needed (e).
Embedded
External
Attempt
Score
Attempt
Score
Recycling
2
5
5
8
Sorting
3
8
5
8
Preparing Breakfast
2
6
5
7
Average
2.3
6.3
5.0
7.7
Table 1. Comparison of embedded (prompt-only) versus external (motion-level) critics across three tasks. The Attempt indicates the number of LLM program generation attempts until completion (max 5). The Score reports program quality on a 0 - 10 scale, where higher scores indicate better program quality. A table comparing embedded (prompt-only) and external (motion-level) critics across three tasks recycling, sorting, and preparing breakfast. For each task, the table reports the number of LLM program generation attempts required to complete the task (up to five attempts) and a program quality score on a scale from 0 to 10, where higher scores indicate better quality. External critics consistently score higher than embedded across both number of attempts and score for all three tasks. The average of external critics is higher than embedded for both number of attempts and score.
Figure 4. Initial task state for each tasks performed in the user study. From left to right: recycling, sorting, and preparing breakfast. Initial task state for each tasks performed in the user study. From left to right: recycling, sorting, and preparing breakfast. Recycling task has a coffee cup, container, and a water bottle on the table with a trash bin behind the table. For the sorting task, there are two red apples and one green apple in the middle of the table, with white box on the left and brown box on the right side of the table. For preparing breakfast task, there is a plate with a fork in the middle of the table. On the right, there is a cupcake on top of an apple inside a brown box. A trash bin is behind the table.
Figure 5. (left) Program quality scores across tasks for both with-critic (dark blue) and no-critic (light blue) conditions. Scores were computed using domain-specific critics, with higher scores indicating better program quality. Horizontal lines indicate statistically significant differences based on the Student’s t-test ( p<.05∗ ). Vertical lines in each bar graph indicate standard deviation. (right) Total number of critic activations across categories. There are two subfigures. The left subfigure shows a bar chart with program score from 0 to 10 on the Y axis across three tasks. For each task, there are two conditions, with-critic (dark blue) and no-critic (light blue). For Task 1 and Task 2, with-critic is higher than no-critic with significant difference p<.05. The right subfigure shows a bar chart with critic counts from 0 to 30 across different critics. In order of descending critic counts is collision, joint speed, space usage, end effector pose, and pinch point.
Programming robots remains challenging for non-experts, as traditional methods require expert knowledge and even block-based interfaces often lack flexibility. Recent work has explored Large Language Models (LLMs) to automatically generate robot programs from natural language, but these systems remain limited by a lack of transparency, missing mechanisms to ensure alignment with user intent, and little support for reuse. We present APPROVE (AI-Powered Programming for Robots with Visual End-User Feedback), an LLM-based multi-modal end-user programming framework that integrates natural language input with a block-based interface and an explicit user confirmation step. Generated programs are visualized using a block-based interface in Blockly, allowing users to confirm, modify, or reject them before execution. Confirmed functions are stored in a library for reuse, gradually building a set of reliable program components. Our approach contributes a human-centered design for LLM-based robot programming that emphasizes user trust, intent alignment, and reusability.
This paper presents a novel concept for intuitive end-user programming of robots, inspired by natural interaction between humans. Natural language and supportive gestures are translated into robot programs using large language models (LLMs) and computer vision (CV). Through equally natural system feedback in the form of clarification questions and visual representations, the generated program can be reviewed and adjusted, thereby ensuring safety, transparency, and user acceptance.
Bijan Kavousian, Petar Tesic, Oliver Petrovic +1
Laboratory for Machine Tools and Production Engineering (WZL) of RWTH Aachen University, Steinbachstraße 19, D-52074 Aachen
Advances in advanced artificial intelligence tools have sparked research in robot autonomy, but the development of such systems has largely focused on execution rather than verifying the feasibility actions planning models propose. Like general-purpose LLMs, robotics planning models carry risks: biased toward user-specified goals, they may suggest actions misaligned with scientific ethics, they may be unsafe due to an inability to "remember" prior safety risks, or they may be vulnerable to adversarial attacks on the autonomy ecosystem. We propose a LLM-driven verification layer between planning and execution to evaluate action permissibility. Our LLM-as-a-Judge ensemble combines chain-of-thought reasoning across models and synthesizes those expert judge outputs, mirroring a combination of a mixture of experts and self-consistency approach. This layer serves as middleware, gating plans from the server's planning module before they reach the MCP server and therefore the robot's low-level controls: plans are approved, rejected for reformulation, or escalated for human review. With this system, we achieve near 85% precision across accept/escalate/reject categories 97% containment of adversarial attacks, with negligible errors between accepting and rejecting tasks, and errors mostly manifesting at the escalate boundary.