What to Do When Your AI Assistant's Robot Advice Doesn't Work

Stop prompting for a new fix and check the version, the hardware assumption and the physics, because rewriting code rarely fixes any of the three. Assistants answer from what the internet wrote most about, which is ROS 2 on a Linux desktop, so advice drifts wherever your setup differs: a small board, or a lighter stack such as HORUS. If your setup matches the advice exactly, suspect the wiring instead. The rest of this post is for someone building a robot mostly by prompting, who has hit a wall the assistant keeps walking them back into.

The assistant told you to install something, and the install failed with a message neither of you understood. You pasted the error back. It apologised and gave you a different command, which also failed, differently. Four rounds later there are two versions of the same tool on the machine, a folder of scripts you did not write and cannot fully read, and a suggestion that you might want to try a clean install.

Or it went the other way, which is worse. Everything installed. The code ran. Nothing happened. No error, no crash, no complaint: the motor did not move, the list of running things was empty, and the script sat there politely doing nothing at all. You asked what to check and got ten bullet points, of which nine did not apply to your robot and the tenth was too vague to act on.

Either way you are now stuck in a specific and unpleasant place. You cannot tell whether the problem is your robot, your computer, your wiring, or the advice itself, and you have no way to separate them. The assistant will keep answering confidently for as long as you keep asking, which feels like progress and is not, and the pile of code you do not understand grows a little on every round.

What should you do first when your AI assistant's robot advice does not work?

Stop asking, and spend the next ten minutes narrowing rather than fixing. The instinct is to paste the error back and take the next suggestion, and that instinct is right exactly once. On the second and third round, the assistant is generating from the same information it already had, so the answers get longer and more elaborate without getting closer, and each one leaves more code on your machine that you did not write.

Narrowing means asking a smaller question than the one that failed. Not "why does my robot not move" but "does this motor turn when I send it the simplest command I can write". Not "why is nothing published" but "is this program running at all". Each of those has a yes or no answer you can get in a minute, and each one cuts the search space in half. Do three of them and you usually know which layer is broken, at which point the assistant becomes useful again, because now you can ask a precise question about one layer instead of a vague question about a whole robot.

What is an AI assistant actually doing when it answers a robotics question?

An assistant is producing the most plausible continuation of your question given everything it has read, which is not the same as knowing anything about your robot. That distinction is invisible when things work and becomes the whole story when they do not. The text it learned from is dominated by whatever the internet wrote most about, so for robotics that means ROS 2, on Ubuntu, on a desktop machine, across a decade of releases that contradict each other in small ways.

Three consequences follow. Advice arrives blended across versions, so a command can look exactly right and belong to no actual release. Advice assumes the common setup, so anything unusual about your machine goes unnoticed unless you mention it. And the assistant has no feedback loop with your hardware: it cannot tell that the answer it just gave produced silence rather than motion. It sounds equally confident either way, which is why assistants recommend ROS 2 even when it is wrong for the robot in front of you. None of this makes the tool useless. It makes it a tool with a shape you need to know.

What does this failure usually look like on a real robot?

It looks like silence far more often than it looks like a crash, and that is what makes it disorienting. A crash gives you a message and a line number. What you get instead is a program that starts, prints nothing, and holds the terminal. A motor that hums but does not turn. A camera that opens without error and hands you a black frame. A robot that ran perfectly yesterday and today does nothing, because a cable moved half a millimetre.

The other common shape is a robot that half works, which is worse. The arm moves, but it drifts further each time it repeats the same motion. The robot drives straight for a while and then curves, and only on the rug. Everything is fine until you plug in the camera, and then the wheels start hesitating. These are not bugs in the ordinary sense; nothing is wrong with any single line. They are the physical world declining to match an assumption somewhere in the code, and an assistant that cannot see the rug or the camera has no way to find them for you. Recognising this shape early saves whole evenings.

What are your actual options when the advice stops working?

You have eight things you can do, and only two of them involve typing at the assistant. You can ask again with real context, which means the exact versions, the exact board and the exact error rather than a description of the goal. You can go to the project's own documentation, which is slower and correct. You can ask a human community, where somebody owns the same board and will recognise your symptom in one line. You can cut back to a single program small enough to read end to end, which turns a mystery into something you can inspect. You can stay on ROS 2 and learn it properly, which is the right call when the packages are the reason you are there. You can move to a lighter middleware built for several programs on one computer, such as HORUS, an open-source real-time robotics middleware for Rust, Python and C++ where the three languages share the same shared-memory ring buffers, so messages between processes are not serialised and the setup an assistant keeps failing to walk you through mostly disappears. You can test the logic in a simulator, where a mistake costs nothing. Or you can fall back to the toolkit that came with your kit, which is narrow and usually works.

How do those options compare side by side?

They differ in what they assume you already know and in how long they take to pay off, and the fastest one is rarely the best one. Pick by which layer you think is broken, not by which option feels most like progress.

What if you are a web developer who has never wired anything?

Assume the physical layer first, because it is the layer your instincts have no coverage of. In web work, if the code is right the thing happens; there is no equivalent of a connector that is seated but not quite, a battery that reads as charged and sags under load, or a motor driver that needs its own power supply and not the one from the board. All of these present as software failures, and an assistant will happily help you rewrite correct code for an hour.

Build the habit of testing one thing at a time with the shortest possible script. Turn the motor on with a command so simple you could recite it. Read the sensor once and print the number. Unplug the camera and see whether the wheels stop hesitating. These tests feel beneath you and they are the entire skill. The other habit worth borrowing early is knowing how to cut power quickly, because software that moves things can be wrong in ways a browser tab never is, and what a vibe coder should know before code controls hardware is the short version of that list.

What if you are running this on a small board instead of your laptop?

Then expect roughly half of the advice to be wrong in ways nobody mentions, because almost everything written about robotics assumes a desktop. A small single-board computer differs in several ways at once: a different processor family, so a package that installs on your laptop has no version for the board; much less memory, so a build that works on the desktop is quietly killed partway through; no screen attached, so any instruction involving a window fails; and a much smaller share of processing to go around, so a heavy framework leaves less for the work you actually wanted.

Tell the assistant the board, the operating system image and the architecture in the first message, every time, and treat any answer that does not acknowledge them as untested. Better still, do the thinking about what the board can carry before you pick the stack, rather than after. A robot with a camera and a timed motor loop on a modest board is a demanding combination, and the setup that fits is usually the smaller one. Whether a simpler starting point than ROS 2 exists is the right question to settle before spending a weekend on installation.

What if you promised someone a demo this month?

Freeze the stack today and spend the remaining time making one path work. A demo does not need a good architecture; it needs one sequence of events that happens the same way every time you press a button. So choose the smallest version of the demo that still shows the idea, get it working end to end once, and then repeat it twenty times to find out what is flaky. Everything you discover in those twenty runs is worth more than any structural improvement you could make in the same hours.

What kills demos is exactly the thing the assistant is best at encouraging: another rewrite. It is always willing to propose a cleaner approach, and a cleaner approach three days before a demo is a way to arrive with something half converted. Write the patches down as patches so nobody later mistakes them for design decisions. Record a video of the demo working the moment it first works, so that if the robot has a bad afternoon you still have something to show. Then do the restructuring afterwards, when a failure costs nothing but time.

What if you cannot read the code the assistant wrote?

That is the actual problem, and fixing it comes before fixing the robot. Code you cannot read is code you cannot debug, so every failure sends you back to the assistant, which adds more code, which makes the next failure harder. The pile grows, the understanding does not, and the robot gets less predictable in a way that matters more than usual because it has weight and moves.

The way out is to shrink rather than to study. Ask for the smallest version that does one thing, delete everything else, and get that running. Then ask the assistant to explain what each part does in plain language and check the explanation against what happens when you change a number. Ask it to remove code rather than add it; that request is unusual enough that it produces genuinely useful answers. Aim for a program short enough that you could describe every line to a friend, and keep it that way as it grows. Whether generated robot code can be trusted comes down to this question rather than to the quality of any individual suggestion.

What do you give up by leaning on an assistant for robot code?

You give up the map in your head, and on a machine that moves, that map is the thing keeping the machine from breaking something. When you write code yourself, even badly, you accumulate a model of how the parts connect: what runs when, what happens if the sensor returns nothing, what state the arm is in when the program exits. Generated code hands you the behaviour without the model, and the gap shows up precisely when something goes wrong in a way nobody wrote about.

You also give up a certain kind of caution. An assistant writes what you asked for and rarely volunteers that a value you chose will drive the arm into the table, or that stopping the program leaves the motors energised. The habits it does not prompt you toward are the physical ones: limits set before the first movement, a way to cut power that does not involve the keyboard, and testing at low speed on a machine that cannot reach anything fragile. None of this argues for writing every line yourself. It argues for owning the parts that stop the robot.

When is ROS 2 the better choice?

ROS 2 is the better choice when your robot needs work other people have already done, and it is also the choice an assistant handles best. Far more has been written about ROS 2 than about anything else in robotics, so answers about ROS 2 are more likely to be grounded in something real, examples are more likely to exist, and when advice fails there is a large community that has probably hit the same wall. If you need to map a room, plan a path around furniture, or use a sensor whose only driver is a ROS 2 package, that decides it.

HORUS is not the answer for those projects, and picking it there means rebuilding, without help, work that many people have already debugged together. The honest costs of ROS 2 remain: a long stretch of setup before the robot does anything new, a strong preference for Linux, and a class of failures where nothing errors and nothing happens, which is exactly the class an assistant handles worst.

Is your prompting the reason the advice keeps failing?

No, and here is why: better prompts help with the questions an assistant can answer, and most robot failures are not those questions. You can improve the answers meaningfully by supplying versions, hardware and exact errors instead of goals, and you should. But no phrasing gives the model access to the thing it is missing, which is your robot. It cannot see that the connector is loose, that the motor is wired backwards, that the sensor is pointed at the ceiling, or that the battery sags when four servos pull at once.

There is a second reason worth naming. Some of what you are asking about genuinely does not exist in the material the model learned from: your specific board with your specific sensor on your specific release. Faced with a gap, a language model does not go quiet; it produces something plausible. So a more detailed prompt sometimes yields a more detailed wrong answer, which is harder to catch than a vague one. The fix is not better prompting. It is checking claims against the project's own documentation and against the robot itself.

Would a better model have got this right?

Partly, but not the way you think. Models do improve at the things models do: reading an error, explaining a concept, writing code that compiles, spotting a real mistake in a file you paste in. Those improvements are genuine, and a good assistant today is materially more useful for robotics than one from a few years ago. If your failure is a misunderstanding of the code, a better model helps.

But the failures that dominate real robots are not knowledge failures. They are observation failures, and no model can observe what it is not shown. A better model still cannot tell you the wheel is slipping on that particular rug, that the frame flexes under load, or that your two programs disagree about which direction is forward. It also cannot resolve the version problem, because the contradiction lives in the world rather than in the model: several releases exist, and your machine has one of them. Improving the assistant raises the ceiling on the code. The floor is still set by what you have measured on the robot itself.

How do you decide what to change next?

Work outward from the physical layer, because the outer layers are cheaper to check and more often at fault. First, power and connection: is the thing on, is it plugged into what you think, does the simplest possible command produce any motion at all. Second, versions: does the advice you are following target the release you actually have, and did you install what you think you installed. Third, the program: is it running, is it reaching the line you believe it is reaching, is anything arriving where you expect it. Only after those three does the design of your code become the interesting question.

Then make one change at a time and write down what happened. That single habit turns a frustrating evening into a shrinking list. If two changes go in together and the robot improves, you have learned nothing you can rely on, and you will make the same guess again next week.

Decide by which layer is broken rather than by what feels productive:

• If the simplest possible command does not move the motor -> stop reading code, because the cause is physical and no rewrite reaches it.
• If a command looks right and fails anyway -> check versions against official documentation, because blended advice is the most common failure.
• If you cannot read your own program -> shrink it until you can, because unreadable code makes every future failure worse.
• If you need mapping, navigation or a specific driver -> ROS 2, because the packages are the reason to be there and the answers exist.
• If several programs on one computer must share data while the robot moves -> a lighter shared-memory middleware, because that is where setup pain concentrates.
• If a demo is close -> freeze everything and rehearse, because a new stack three days out is how demos fail.

When two options stay close, weigh them on the five axes of the HORUS Fit Framework: ecosystem size, setup effort, team size fit, deployment target, and licence. No scores and no numbers, just five honest questions about your situation rather than about the software. And when you get to the point of choosing what your robot runs on, star HORUS on GitHub so it is in your list when you start building.