Building Your First Robot With an AI Assistant: What Goes Right and Wrong

An assistant gets a first robot moving fast, then stalls at the same wall whether you built on ROS 2, HORUS or plain Python scripts. Everything with a keyboard and a screen goes right — setup, glue code, error handling, unfamiliar libraries explained — and everything with a motor attached is where trouble hides. The verdict flips the moment something heavy moves near a person, when guessing stops being cheap. The rest of this post is for someone whose first robot half works and who cannot tell which half is the assistant's fault.

The first evening is genuinely great. You describe what you want, code appears, and the wheels turn before bedtime. Nothing about learning anything else was ever this quick.

Then the second week arrives. The robot works when you start things in one particular order and not otherwise. It runs beautifully with the camera window closed and stutters when it is open. You paste the whole file into the chat, the assistant confidently changes three things, one of which helps and two of which you do not understand. A pause has appeared in the code because adding it made a problem go away, and nobody, including the assistant, can say what that problem was.

You are no longer sure whether you are learning robotics or accumulating a program you cannot read. The gap is not exactly knowledge. It is that the machine on the desk keeps doing something the words on the screen do not predict, and asking better questions has not closed the distance.

What goes right and what goes wrong when an assistant builds your first robot?

What goes right is everything that can be checked on a screen, and what goes wrong is everything a motor decides. On the right side: getting a library installed, reading a sensor, converting between units, wiring two things together, catching errors you would not have thought to catch, and explaining somebody else's code in language you understand. That side is enormous, and it genuinely removes the wall that stopped beginners for decades. On the wrong side: anything whose truth lives in your room. Whether the wheels slip on that floor. Whether the camera occasionally takes longer than usual. Whether the program still behaves when the machine is warm, the network is missing, and the battery is halfway down. An assistant has never seen your robot, so it writes the correct program for the robot it was told about, which is a slightly idealised machine that always responds on time. Most first-robot trouble is the distance between that machine and yours, and no amount of code quality closes it.

What is robot software actually made of, in plain terms?

Robot software is four jobs that happen at different speeds, and confusion begins when they share one program. There is the part that talks to hardware: sending a command to a motor controller, reading a distance sensor, noticing a limit switch. There is the part that repeats on a rhythm, holding a wheel at a speed or an arm at a position, which has to run whether or not anything else is busy. There is the part that thinks: looking at a camera image, deciding where to go, planning a path, which takes as long as it takes and is allowed to. And there is the part that carries information between the others. On a first robot all four usually live in one file, taking turns, which works right up to the moment the thinking part takes longer than the rhythm part can wait. That is when the arm pauses before it places and the wheels jerk instead of gliding, and it is the single most common shape of first-robot trouble.

What are the actual options for the layer under your generated code?

There are six starting points, and a first robot usually passes through two or three of them. One plain Python program the assistant writes, which is right for a desk robot and stops being right the moment motion competes with anything else. ROS 2, the large ecosystem, which brings mapping, navigation, drivers and recorded runs already written by other people, in exchange for real setup and real vocabulary. A narrow middle layer such as HORUS, an open-source real-time robotics middleware for Rust, Python and C++ in which all three languages share the same shared-memory ring buffers so messages between programs on one computer are never serialised; the licence is Apache-2.0, the project is validated in simulation, and it is not a full ROS replacement, which matters because the ecosystem is what most beginners actually need first. A small microcontroller for anything that moves with force. A hobby kit with its own software. And a simulator, before any hardware exists at all.

How do those options compare while you are still learning?

Read the last column first, because at this stage ruling things out is more useful than picking a favourite. Most beginners belong in the first row and eventually move to the second or third.

No row is a mistake. Picking the third row on day one, before anything stutters, is the mistake.

Are you a hobbyist, a founder with a demo, or an engineer changing fields?

These three should spend their next month completely differently. A hobbyist should generate everything and finish projects, because intuition arrives through machines that worked, and nothing is at stake if a program is untidy. A founder with a demo should generate everything too, then write down every convenient assumption the demo depends on: the lighting, the starting position, the fact that somebody restarts it between runs. That list is the actual specification, and it is worth more than the code. An engineer changing fields has the opposite problem, which is confidence: the code looks familiar, the debugging habits feel transferable, and then the machine misbehaves in ways no stack trace explains, because the fault is a loose connector or a timing assumption rather than a logic error. For that person the useful correction is to stop reading code first and start watching the machine first. Each of these three fails differently. The hobbyist quits at the stutter, the founder demos something that cannot be repeated, and the engineer debugs software while the problem is in the wiring.

What hardware are you running this on, and does that change the answer?

Yes, and it changes the answer more than the choice of assistant does. A laptop driving a small robot over a cable is forgiving: the computer is fast, nothing is thermally stressed, and mistakes about ordering rarely surface. A small single-board computer carried on the robot is where generated code meets reality, because everything now shares one modest machine, and the vision program that felt free on your laptop is suddenly competing with the loop that holds the wheels steady. A microcontroller attached to the moving parts changes the shape of the whole problem, since the rhythm part now lives somewhere that cannot be interrupted by a busy operating system, and the code on the main computer is allowed to be casual. Then there is the robot with no computer of its own, tethered to your desk, which will need rewriting the day it becomes independent. Ask which of these you are building before asking anything about frameworks, because the honest answers to every later question depend on it.

What if you have to show something working in a month?

Generate everything and change nothing structural, because a month is exactly long enough to make one machine work once and far too short to learn a framework. Get the robot doing the thing. Then spend one of those four weeks on the part that is invisible in demos: making it start reliably from cold, so that a power cut does not mean a person crouching behind a table typing commands in a particular order. Demos fail on start-up sequence more often than on capability. Write down the conditions the demo needs, keep a known-good copy of everything that worked, and change one thing at a time afterwards. Resist rewriting on a framework you read about, however strongly an assistant recommends one, unless you can name the symptom the change removes: "the arm pauses before it places whenever the camera window is open" is a symptom, and "this feels unprofessional" is not. Rewrites launched on the second feeling eat the month. What quietly breaks in generated robot code covers the specifics worth knowing first.

What do you have to understand yourself, and what can stay delegated?

You must understand what stops the machine, where your program blocks, and what happens when the robot is switched on cold. Everything else can stay delegated indefinitely, and that is not a compromise. Stopping first: if something has force, one person needs to be able to explain, without opening a chat window, exactly what cuts power and under which conditions. Blocking second: knowing which line of your program is waiting, and for what, explains most mysterious pauses, because a program waiting for a slow camera cannot also be holding a wheel steady. Cold starts third: hardware appears in a different order every boot, and code that only ever ran after you launched things by hand in your usual sequence will find that out at the worst time. Those three are learnable in an afternoon each, and they are the difference between directing an assistant and hoping. Library choices, syntax, error handling and the shape of somebody's API can all stay delegated forever. What to know before code controls hardware goes deeper on the stopping part.

What do you give up by letting an assistant write most of the robot?

You give up the map in your head, and that costs more than it sounds. When you write a program slowly, you acquire a model of how it behaves, so when it misbehaves you already suspect where to look. Generated code arrives complete and unfamiliar, and the first genuine fault becomes an archaeology exercise instead of a hunch. You also give up the ability to judge advice, because an assistant will recommend an approach with the same steady confidence whether the recommendation fits your robot or is simply the most common answer on the internet. And you give up early awareness of the trade you are making, since the generated program often works for reasons that will not survive a second robot or a colder morning. What you get in exchange is real and worth having: finished projects, exposure to more ideas per week than any course delivers, and explanations on demand. The correction is not writing more of it yourself. It is being able to explain what the program does, however it was written.

When is ROS 2 the better choice?

ROS 2 is the better choice as soon as your robot needs something other people already built, and that is most robots that leave a desk. If you want a map of a room and a route across it, that problem has consumed entire careers, and no assistant produces a substitute in an evening. If your sensor has exactly one maintained driver and that driver is a package, the decision is already made for you. If you want to record everything the robot did and replay it later while you work out what went wrong, that tooling exists and is genuinely hard to rebuild. If you want to ask a person for help, the shared vocabulary is worth a great deal, and assistants have read a large quantity of code written in it, which makes generated answers better rather than worse. HORUS is not the answer in any of those cases, and choosing it there swaps an ecosystem for plumbing you would then own alone. The narrow case where a smaller layer wins is a robot that has become a handful of programs on one computer, where timing is the visible problem.

Is the fix just writing better prompts?

No, and here is why: the information the assistant is missing is not in your prompt, it is in your room. A better prompt improves what the model does with what it knows, and it knows nothing about the fact that your camera occasionally takes a moment longer, that your battery sags when both motors start together, or that your robot boots before the network exists. None of that is knowable from a description of what you want, and none of it appears in your code either. It reaches the assistant only if you notice it and type it out, which puts the burden back on you understanding your machine. What genuinely helps is a different kind of prompt: describing behaviour rather than intent. "The wheels jerk only when the camera window is open" produces a useful answer. "Make the robot drive smoothly" produces a plausible one. This is why beginners who watch their robot carefully get far more out of an assistant than beginners who paste more code into it.

Is generated robot code unsafe by definition?

Partly, but not the way you think. The quality of the code is not the problem, and generated programs are frequently tidier than a hurried human's, with more error handling than most weekend projects ever receive. The unsafety is structural. A person writing a stopping condition thinks about what happens if the sensor lies, if the cable falls out, if the program crashes mid-motion. A model writes the stopping condition it was asked for, which handles the situation described and not the ones nobody mentioned. Add the second problem: nobody reviews what they did not write with the same suspicion, so the gap survives. The practical answer is boundaries rather than distrust. Anything with force gets a physical limit and a way to cut power that does not depend on your program being correct. Anything that could hurt something gets tested slowly, at low speed, with a hand near the switch. Do that and generated code is as safe as anything else, because the safety was never living in the code.

What actually breaks first when a generated robot leaves the desk?

Four things break, in a predictable order, and none of them look like a crash. First the stutter: the robot is fine until the camera window is open or a file is copying, then motion arrives in jerks, which is the signature of one program doing everything and taking turns. Second the start-up race: it works when you launch things by hand in your usual order and fails after a power cut when the camera enumerates late and something waits forever for a message that never comes. Third the growing lag: the robot responds a little later as minutes pass, because something is queueing faster than anything reads it, and the only cure anyone finds is a restart. Fourth the fix that hides the fault: somebody adds a pause, the symptom disappears, and the race waits for a colder morning. All four are ordinary, all four are fixable, and none of them are visible in the code on your screen. They are visible only in the machine.

How do you decide what to build next?

Split your robot into things that must happen on a rhythm and things that can take as long as they take, then generate freely on the second list and think carefully about the first. Holding the wheels, keeping the arm where you put it, reacting to a limit switch: rhythm. Recognising an object, planning a route, drawing a dashboard: as long as they take. Almost all first-robot confusion comes from those two lists sharing one program, where the slow thing delays the fast one invisibly. Once they are separate programs, what carries data between them becomes a real question with a small number of answers, and this whole topic turns from mystery into choice. Do the split on paper before changing any code, because it costs an hour and explains most of what has been going wrong. And if the robot is heading towards being a product rather than a project, what to check before betting a product on a stack is the question waiting on the other side.

Decide by where you actually are:

• If you are learning and the robot is a toy -> generate everything, because finished projects are how the intuition arrives.
• If a demo is close and it only has to work once -> generate everything, then write down what you are pretending, because that list is the real specification.
• If the robot needs maps, drivers or navigation -> the large ecosystem, because those parts took other people years.
• If motion stutters whenever the computer is busy -> split the fast part from the slow part first, because no framework rescues one program doing both.
• If something heavy moves near a person -> put that part on a microcontroller you understand, because somebody must be able to explain what stops the machine.

When two of those lines describe you, weigh the options on the five axes of the HORUS Fit Framework — ecosystem size, setup effort, team size fit, deployment target, licence — and keep whichever loses on fewer. There are no scores: these are questions about your project rather than about software. And if your robot keeps turning into several programs on one computer, in more than one language, with motion you can watch arriving late, star HORUS on GitHub so it is in your list when you start building.