Best Workflow for Building Robots With AI Help

The best workflow with AI help is simulation first, a stack the assistant already knows — usually ROS 2 — and human review of anything that moves. Assistants are strongest where public examples are thickest, so the stack with the most written about it costs you the fewest confidently wrong answers. The verdict flips when the robot mixes languages on one computer, where HORUS fits the job better. This post is for people who can prompt their way to working software and want the robot version not to end badly.

You have built things this way before. You describe what you want, the assistant writes it, you run it, you paste the error back, and after a few rounds there is working software. It worked for a website. It works, in a way, for a robot: the assistant produces confident code that imports packages, sets up a node, subscribes to something. Then you plug in the actual motor and nothing is where the code thinks it is. The camera returns frames in a format the example did not expect. The library the assistant reached for was renamed two versions ago. Worst of all, the code runs and the robot does something — just not the something you asked for, and there is no error to paste back. You cannot tell whether you have a wiring problem, a units problem or an invented function, and the loop of pasting the error stops working when there is no error. Somewhere in there sits a question that never came up when you were building websites: what is the hardware doing while you figure this out.

What workflow actually works when an assistant writes most of the code?

The workflow that works is: simulate before you wire anything, keep the robot in small named pieces, and read by hand every line that commands a motor. Everything else is detail. Simulation matters because a wrong answer in a simulator costs a restart and a wrong answer on hardware costs a gearbox, and because you can run the same mistake over and over without recharging anything. Small named pieces matter because assistants write one component with a stated input and output well, and hold a whole robot in their head badly; a request to write a driver that reads a serial port and publishes a reading gets a good answer, and a request to write the robot gets plausible mush. Reading motor commands by hand matters because that is the code with a physical consequence, and the only code where being confidently wrong breaks something you paid for. The rest — which framework, which language, which editor — moves the difficulty around rather than removing it.

What does building a robot with AI help actually involve?

Building a robot with AI help involves four different jobs, and an assistant is excellent at two, useful at one, and dangerous at the last. The first job is plumbing: reading a sensor, moving values between programs, writing the boilerplate a framework demands. Assistants do this well, because thousands of public examples exist and the result is checkable by running it. The second is explanation: what a transform is, why odometry drifts, what a quaternion is doing in your message. Assistants are strong here, and this is where the hours genuinely get saved. The third is debugging: given an error and the surrounding code, a good suggestion arrives quickly, though the suggestion is occasionally to install a package that does not exist. The fourth is judgment about the physical world — how gently that arm should approach a table, what to do if a sensor returns nothing for a moment, whether the safe failure is to stop or to coast. No public example contains your robot, and that fourth job stays yours.

What are the actual stacks an assistant can help you build on?

There are five, and the choice matters mostly because it decides how much the assistant already knows. ROS 2 has the deepest public record — years of questions, answers, tutorials and packages — so an assistant produces more usable ROS 2 code than anything else, and also more confidently wrong ROS 2 code, because it blends two versions of the same idea. A single-machine middleware such as HORUS is a smaller surface: an open-source layer where Rust, Python and C++ share the same shared-memory ring buffers, so there are fewer concepts for you or the assistant to get wrong, and far less written about it publicly, which means checking against the repository more often. Plain Python in one program is the option assistants handle most dependably, because it is ordinary software with a motor attached. A vendor SDK depends entirely on whether the vendor published documentation. And firmware on a microcontroller is where assistants are weakest, because the mistakes there are electrical. Which framework an assistant understands best is worth knowing before you commit.

Which stack fits which kind of AI-assisted builder?

The stack that fits is the one whose assumptions match what you can check, because a suggestion you cannot verify is not help.

Most people end up on two rows: a simulator while learning, and one of the others once parts arrive.

What should you do if you are a web developer moving to robots?

Keep your workflow and change one habit: stop trusting code you have not watched run. Web development taught you a loop where the assistant writes, the page reloads, and the feedback is immediate and free. Robotics keeps the first half and removes the second, because the thing giving feedback has mass. The replacement for the reload is a simulator, and the discipline is making the simulator the default place code runs for the first several weeks. The second adjustment is units and frames. Most robot bugs that survive an assistant are not code bugs at all; they are a value in degrees being read as radians, or a position that is correct in the camera's frame and nonsense in the arm's. Assistants make this mistake constantly, because both versions look like reasonable code. Print the value, look at it, and decide whether that number could be true of a physical object in your room. That single check catches more than any amount of prompting, and it is the practical half of knowing when to trust generated robot code.

What if you do not own a robot yet?

Build in a simulator and treat the missing hardware as an advantage for now. A simulator gives an assistant-driven workflow the thing it otherwise lacks: a free and repeatable place to be wrong. You can run a bad idea, watch the arm swing through the table, fix it, and run again without a charging cycle or a replacement part. Almost everything in the software half of a robot can be learned this way — message flow, control loops, coordinate frames, planning, the shape of a project — and what cannot is mostly the physical half: mounting, cable strain, and sensors that lie. Pick a simulator that ships robot models you did not have to build, because building a model is a project of its own and not the one you are on. The right time to buy hardware is when the simulator stops being the reason you are stuck, which shows up as a change in your questions: they become questions about one specific motor rather than about how any of this fits together.

What if you want something moving this weekend?

Use one language, one program and a simulator, and skip every framework decision until Monday. A weekend is enough to get a wheeled robot driving in a simulator, or a servo arm responding to keyboard input, and it is not enough to install a full framework, learn its build tool and get two programs talking — particularly alongside an assistant that will confidently suggest a package name from a version you are not running. So the weekend workflow is deliberately small: one script, an obvious loop, printed values, and a stop key that works. The point of the weekend is not architecture. The point is converting interest into a thing that moves, because that is what determines whether there is a second weekend. Architecture questions become real when you have three programs instead of one, a second language, or a component whose crash must not take the motors with it. Answer them then, with something running, rather than now, with nothing running.

What if you have never written C++ or Rust?

Stay in Python and use the assistant to find the one place where Python stops being enough. Sensor reading, coordination, planning at human speeds, dashboards, logging, most of a first robot: Python does all of it, and an assistant writing Python for a beginner is close to its best case, because the language is forgiving and the examples are endless. Python stops being enough at a recognisable moment — when the loop holding a wheel speed, or keeping an arm short of the table, misses its moment because the language paused to tidy memory, and the robot twitches. That is the point to move one component into a compiled language, not the whole robot. An assistant is genuinely useful for that rewrite, because translating a small, well-defined loop from one language into another is exactly the shape of task it handles well. What an assistant cannot do is tell you which component to move. That comes from watching the machine and noticing what stutters.

What does AI-assisted robot code look like when it goes wrong?

AI-assisted robot code goes wrong by running perfectly and producing behaviour nobody asked for. The classic version: the assistant writes a loop commanding the arm to a position, the units are wrong in a way invisible in the source, and the arm moves smoothly to somewhere it should not be. Nothing crashes. There is no error to paste. The second version is a function that does not exist, an invented method from a library version that never shipped, which is loud and harmless because it fails immediately. The third is the dangerous one: correct code with no failure handling, so when the sensor returns nothing for a moment the last value gets reused and the robot keeps driving on stale information. Assistants rarely write the boring defensive branch unless asked, because tutorials rarely include it. The countermeasure is a habit rather than a prompt: for every piece of code that moves something, say out loud what happens if the input stops arriving, and write that branch yourself. The quiet breakages are the ones worth studying.

What do you give up by letting an assistant drive the workflow?

You give up the understanding that normally arrives as a by-product of struggling. Code you did not write is code you cannot debug quickly, and robotics punishes that harder than most software, because the failure is physical and the clock keeps running while you read. You also give up a kind of taste — the sense of which library is maintained, which approach the community abandoned, which answer was true in 2019 and is not true now — because an assistant presents all of it in the same even voice. The third thing you give up is architecture. Assistants write components; nobody writes the shape of the project, so a robot built prompt by prompt often ends up as one enormous file with the timing rules scattered through it. The fix for all three is the same, and it is not to stop using assistants: keep a written picture of the parts and how they talk, read every part that moves something, and once a week rebuild one small thing yourself with no help at all.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever an assistant is doing much of the writing and the robot needs anything from the catalogue. The public record is deep, so suggestions land more often and mistakes are more likely to match a question somebody already answered in public. If the robot must map a building and navigate it, ROS 2 has that and no assistant is going to write it for you. If you want a simulator that already speaks the same message types, ROS 2. If you might hand the project to somebody else, or want the experience to count on a résumé, ROS 2 again. And if the robot spans two computers by design, ROS 2, because HORUS is a single-machine middleware and shared memory stops at the edge of the board. The case against ROS 2 is narrow: one computer, no catalogue pieces you actually need, and a preference for a surface small enough to hold in your head. Outside that narrow case, the catalogue wins, and the assistant knows the catalogue better anyway.

Can an assistant just write the whole robot for you?

No, and here is why: the hard part is not the part that is written down. An assistant produces the code for reading a sensor, publishing a value, subscribing to it and running a loop — the parts with thousands of public examples behind them. What no example contains is your robot: this motor with this backlash, this camera at this angle, this table at this height, this battery that sags when the arm lifts. Every serious bug in a robot project lives in that gap, and closing it means watching the machine and forming a theory, which is not a text problem. There is a second reason, and it is about consequence. Software that is wrong on a screen produces a wrong screen. Software that is wrong on an arm produces a dent, and occasionally an injury. A workflow that hands the whole robot to an assistant hands over the decisions with physical consequences too, and those are precisely the decisions a person should be making slowly.

Does an assistant remove the need to understand the stack?

Partly, but not the way you think. You genuinely no longer need to memorise command line flags, message field names, or the argument order of a build tool, and that is a real subtraction of tedium. What does not go away is the model in your head of how your robot is put together: which program owns the motors, what happens when one of them dies, where a value came from and how old it is by the time it gets used. That model is what lets you read a suggestion and notice it is wrong, and without it you are running a workflow in which nobody is checking. The uncomfortable version is that an assistant raises your floor and does nothing to your ceiling. You will get further on day one than you would have alone, and then stall in the same place everyone stalls — at the point where the robot behaves inexplicably and the only way through is understanding what you built. Budget the reading time.

How do you decide which workflow to run tomorrow?

Decide by what you are missing, not by what sounds thorough. If you have no hardware, the workflow is simulator plus one language, and the assistant writes almost everything. If you have hardware and nothing works yet, the workflow is one program, printed values and a stop key, with the assistant used for explanation more than for code. If you have several programs and a timing problem, the workflow changes shape: you need a middleware, a recording of a run, and code you have actually read, because that failure does not yield to prompting. And if you are choosing a stack, choose by what the robot needs from a catalogue and how many computers it runs on, which is the same decision a small team faces whether or not an assistant is involved. Write down which of those four situations you are in before opening a chat window, because the workflows differ and running the wrong one is how weeks disappear.

A short version, by situation:

• If you have no robot yet -> a simulator and one language, because a wrong answer costs a restart instead of a part.
• If you are a web developer with a servo and a weekend -> one Python script and a stop key, because motion this weekend decides whether there is a next one.
• If your robot needs mapping or navigation -> ROS 2, because the catalogue exists and no assistant is going to write it for you.
• If your robot mixes languages on one computer -> a single-machine middleware, because a bridge between languages is something you would maintain forever.
• If the robot already behaves inexplicably -> stop prompting and start recording, because the answer is in what the parts actually sent each other.

When you want to compare stacks rather than symptoms, the HORUS Fit Framework lines them up on five things that are not numbers: ecosystem size, setup effort, team size fit, deployment target, and licence. For an assistant-heavy workflow, ecosystem size matters most, because ecosystem size decides how often the answer you are handed happens to be true.

The repository is open source under Apache-2.0 and linked below. Star it so HORUS is in your list when you start building.