What Changes When AI Writes the Boring Parts of Robot Software

When an assistant writes the boring parts, the work moves from typing to reviewing, and hand-written and generated robot code fail in different places. Glue code and message definitions come back fine; timing, failure handling and anything touching a motor come back confident and wrong, whether the target is ROS 2 or a smaller stack like HORUS. The verdict flips once you can read every line you ship. The rest of this post is for people building robots with an assistant and wondering which parts they still have to understand themselves.

It started well. You described the robot you wanted, and something came back that ran. Not pseudocode, an actual program, with sensible names, that read the sensor and drove the wheels and stopped when the reading got small. The first evening felt like the future had arrived early.

The second week is where you are now. The robot mostly works. Sometimes it stutters at the same corner and you cannot say why. You asked for a fix and got two hundred new lines, some of them in files you did not know existed. You asked why one function waits for a moment before reading, and got a fluent explanation you had no way to check. Somewhere in there a retry loop appeared that hides a sensor going quiet, and you only found it because the robot kept driving with its eyes shut.

So now you are looking at a program that is yours in the sense that you own it and not in the sense that you understand it, with a demo coming up where it has to run in front of people. You would like to know which parts of this you should have written yourself, and whether it is too late.

What actually changes when an assistant writes the boring parts?

The bottleneck moves from writing code to judging it, and most people do not notice the move until something breaks. Before, a project was limited by how fast you could produce working lines, so the skill that mattered was fluency. Now the lines arrive faster than you can form an opinion about them, and the scarce skill is knowing which ones deserve an opinion. Reviewing code you did not write means holding a model of what the program is supposed to do that is independent of the program itself, which is exactly the thing a beginner has not built yet. There is a second change, quieter and more consequential: the cost of producing a wrong structure drops to almost nothing, so wrong structures survive much longer. Nobody rewrites an architecture that took an afternoon of prompting, because rewriting feels like it ought to be cheap and never is. On a website you discover the problem in production and patch it. On a robot the same discovery arrives as motion, which is why the parts that move deserve a different standard from the parts that do not.

Which parts of robot software are actually the boring parts?

The boring parts are everything that carries data around without deciding anything, and they are a large fraction of any robot project. Message definitions. Configuration files and the code that reads them. The startup script that launches six programs in the right order. Logging. The little command-line tool you use to poke at a running system. Unit conversion, which is boring and also the source of a famous class of expensive mistakes. Recording and replaying data. Plotting. Driver scaffolding around a sensor whose protocol somebody has already documented. An assistant is good at all of that, because those parts are shaped the same way in nearly every project. The parts that are not boring are the ones where the robot decides something: the loop that has to keep its rhythm, the behaviour when a reading stops arriving, what the machine does when one program dies while the others keep running, calibration, coordinate frames, and every path that ends with a motor turning. Those look like ordinary code and are not, because the cost of a wrong answer is physical rather than a stack trace.

What are your actual options for getting robot code written?

You have about seven, and the real difference between them is how much of the result you can check. An assistant writing ROS 2 code is the well-trodden route, because a decade of open-source robotics is written in ROS 2 and the training material is enormous, which cuts both ways, since much of that material describes releases that have since changed. An assistant writing against a smaller stack gives you less to imitate and less to check: HORUS is 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 are not serialised between processes on one machine, and like ROS 2 it is Apache-2.0. You can generate the repetitive parts from your own message definitions instead, which is older technology and far more predictable. You can copy the structure of an open-source robot close to yours. You can lean on a vendor's SDK examples. You can write the moving parts by hand and delegate everything around them. Or you can pay somebody who has already shipped a robot to write the risky half.

What should you do if you have never written robot software before?

Start by making the assistant explain the program back to you, file by file, until you can predict what each part does before you run it. That sounds slow and it is the fastest route available, because the failure ahead of you is not bad code, it is code you cannot form an opinion about. A useful discipline: for every file, be able to say what it reads, what it writes, and what happens if it stops. Any file you cannot answer for is not yours yet. Beyond that, learn the smallest amount of robotics that lets you ask better questions. What a control loop is and why its rhythm matters. What a coordinate frame is and why two of them can disagree. Why a timestamp is attached to a reading. Those three ideas turn most generated robot code from opaque to readable. How to review robot code you did not write applies directly here, because a program written by an assistant and a program inherited from a departed colleague present the same problem.

What changes when the code has to run on a small board instead of your laptop?

Everything the laptop was hiding shows up, and generated code hides more of it than hand-written code does. A development machine has spare capacity, so a program that does more work than it needs to still finishes in time and looks correct. Move the same program onto a small board that is also running the camera pipeline and the network stack, and the slack disappears. Generated code tends to be generous: an extra copy of an image because copying is safer, a conversion done inside the loop rather than once outside it, a data structure that reaches for memory while the robot is moving. None of that is wrong on a desktop. All of it becomes visible on a board, usually as a robot that behaves for a minute and then jerks. The practical move is to run on the target machine early rather than at the end, when the structure is already set, and to watch for behaviour that changes when the machine gets busy. What runs on a robot besides your own code covers the neighbours competing for that machine.

How does this change if you have a demo next week instead of a product next year?

For a demo next week, hand over almost everything and accept that you are building something disposable; for a product, hand over the parts you can check and write the rest. Those are different projects, and the mistake is treating the first as a draft of the second. A demo has to work once, in a known room, with somebody watching who can catch the robot. Generated code is excellent at that, and the honest framing is that you are producing a convincing sketch. Trouble starts when the sketch acquires a customer. Nothing in it was chosen: the structure came from whatever the assistant tends to produce, the error handling is decorative, and the parts that matter under real use were never exercised. If there is any chance the demo becomes the product, spend the week differently. Write the loop that moves the robot yourself, generate everything around it, and keep a written list of what you know you skipped, so the skipped parts stay visible afterwards.

What if you can read code but have never debugged something that moves?

Expect your debugging instincts to be right about the code and wrong about the robot, because every failure you have met before stops when you stop the program. A robot failure keeps happening while you think. That changes what a good first move is: not a breakpoint but a recording. The habit worth building immediately is logging enough that yesterday's failure is explainable today, every reading with its timestamp and every command with the state that produced it, because the failure will not reproduce on demand and you will not be watching when it does. The second habit is suspecting timing before logic. When a robot works and then does not, with no code change in between, the cause is usually something arriving in a different order or later than before, not an incorrect calculation. Generated code makes this harder in a specific way, because assistants patch symptoms with waits and retries, which turns a visible timing problem into an intermittent one. Why your robot behaves differently every run is the deeper version of the same problem.

What does it look like when generated robot code goes wrong?

It rarely crashes; it drifts, and it usually keeps moving while it is wrong. The recognisable version is a robot that works for a minute, then hesitates at the same spot, and every fix makes the hesitation move somewhere else. Underneath is often a wait inserted to make an ordering problem go away, which holds until the machine is busier than it was that afternoon. Another version is the confident retry: a loop that keeps asking a sensor for data and, on failure, quietly reuses the last reading, so the robot drives on a memory of the world instead of the world. A third is safety that exists only on the happy path, where the stop condition is checked inside the same routine that hung. The common thread is that generated code is written to succeed rather than to fail well, because most of the material behind it is about producing an output, not about deciding what to do when the input never arrives. On a robot, that decision is the software. Is vibe coding safe for anything that moves sets out where the line falls.

What do people try first when the generated code stops working?

Most people try to prompt their way out, and that stops working at the point where the problem is in the structure rather than in a line. The sequence is predictable. First you paste the error and get a fix that works. Then you paste a behaviour rather than an error, because the robot hesitates, and you get a plausible change that shifts the symptom somewhere else. Then you ask the assistant to review its own code, and it finds real issues that are not this one. Then you ask for a rewrite, receive a new program with a fresh set of undiscovered problems, and lose the parts that were working. The other thing people try is adding more context: the whole repository, the logs, the datasheet. That helps with narrow questions and not with this one, because the missing information is not in the repository. It is what the robot physically did and when. What works is the unglamorous move: reproduce the failure with a recording, find the one place where the data stops making sense, and read that part yourself.

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

You give up the mental model you would have built by writing it, and that model is the thing you debug with later. This is the real cost, and it is deferred, which is why it is so easy to accept. Writing a system slowly gives you a map: you know where data enters, what shape it has at each hop, which parts are fragile because you were unsure when you wrote them. Accepting a system quickly gives you a program and no map, and the first serious failure is where you learn that reading is not the same as having written. Two smaller costs follow. Provenance: you own code whose origins you cannot describe, which matters the day a licence question arrives or a client asks what is inside the product. And uniformity: an assistant produces the median solution, which is fine for glue and wrong for the specific thing that makes your robot different, whether that is the awkward sensor, the unusual duty cycle, or the mechanism that misbehaves at one end of its range.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever an assistant's fluency in it is worth more to you than a smaller core, which is more often than the question implies. If you are building something that navigates a building, ROS 2 brings mapping, localisation and planning that already work, plus an assistant that has read thousands of examples of wiring them together. If you are hiring, collaborating, or handing the project to somebody in a year, ROS 2 is what strangers can read. If your robot uses sensors with published drivers, someone has already solved the firmware quirks and written it down. If you are learning and want every error message to have been asked about publicly, the size of that corpus is the entire point. In all of those cases, HORUS is not the answer. One caution applies either way: an assistant's knowledge skews towards older releases, so check anything touching build files or quality-of-service settings against current documentation, and why assistants recommend ROS 2 even when it is wrong is worth reading before accepting the default.

Does this mean you no longer need to learn robotics?

No, and here is why: the assistant removed the part of the work that used to teach you slowly, and left the part that requires judgement you have not built yet. Producing code was never the hard half of robotics. The hard half is knowing what should happen when a reading is late, deciding whether a behaviour is unsafe before a person is standing next to the machine, and telling a sensing problem from a control problem when both present as the robot doing something stupid. None of that became easier. What changed is the ramp. You used to acquire that judgement while typing, slowly and half by accident, and now you can arrive at a working robot having acquired none of it. The people getting the most out of assistants are not the ones who know least; they are the ones who know enough to ask a suspicious question and check the answer against something real. Usefully, the amount you need is smaller than a degree, and whether learning ROS 2 is still useful if you build on something else covers which parts of that knowledge survive a change of stack.

Is generated robot code more dangerous than code you write yourself?

Partly, but not the way you think. The danger is not that the generated lines are worse, because frequently they are tidier than what a hurried human produces, with better naming and fewer forgotten cases along the ordinary paths. The danger is that the code is uniformly plausible, so your usual signal for where to look is gone. In a program you wrote, you know which parts you rushed, which you never tested, which you were unsure about at the time, and that memory is a map of the risk. Accept a program whole and every part looks equally finished, including the parts that were guessed. The second issue is that assistants aim at a working result, which pushes error handling towards carrying on rather than stopping, an excellent default for a script and a poor one for an arm. So the practical rule is not to write more by hand out of principle. It is to decide, before generating anything, which paths end in movement, and hold those to a standard you enforce by reading.

How do you decide which parts to hand over?

Sort every part of the project by what happens when it is wrong, and hand over the ones whose failure is visible and harmless. A plotting script that is wrong produces an ugly graph. A configuration parser that is wrong fails at startup, loudly, before anything moves. Both are safe to generate and safe to regenerate. A control loop that is wrong drives a machine into a table, and a stop condition that is wrong does nothing at all until the day it is needed. Those are yours, however slow that feels. The middle category, meaning drivers, message plumbing and startup ordering, is safe to generate on one condition: that you read it once and can say what it does when its input goes away. Two habits make the whole approach hold together. Generate in pieces small enough to review in one sitting, because a large change is not really reviewed. And keep a written list of what you have not checked, so the unchecked parts stay visible instead of becoming background. Should you trust AI-generated robot code goes further into the review side.

Where that leaves you:

• If you are building a demo for next week -> generate almost all of it, because a disposable sketch is the right artefact for the job.
• If you are turning a prototype into a product -> write the moving parts yourself, because that is where a wrong guess becomes motion.
• If your code will run on a small board -> test on the board early, because generated code spends the slack a laptop was hiding.
• If you are choosing a stack rather than a file -> pick the one you can check, because help you cannot read is not help.

When the choice is a stack rather than a file, the HORUS Fit Framework asks five questions with no numbers in them: ecosystem size, setup effort, team size fit, deployment target, and licence. Answer those about the robot you are actually building and the shortlist usually collapses. If a smaller middleware belongs on yours, the HORUS repository is at github.com/softmata/horus — star it so it is in your list when you start building.