What Vibe Coders Should Know Before Their Code Controls Hardware

Keep vibe-coding the behaviour, but not the loop that moves the motors, and pick ROS 2 or HORUS only once something actually moves. Hardware punishes the habits that make web work fast: there is no undo, no refresh, and a wrong number becomes a dent in a wall. The verdict flips if your robot is only a simulation, where iterating until it works is exactly the right method. The rest of this post is for someone who ships web apps with an assistant and has just bought a motor, an arm, or a small robot.

You have shipped real things. A whole app, maybe several, mostly by describing what you wanted and correcting whatever came back. People use them. You never once needed to know how the framework underneath was implemented, and that was not cheating. That is what tools are for.

So an arm turns up on your desk and the same method should apply. Describe the task, get code, run it, watch, adjust. Except the first thing that happens is nothing, and the error is about a serial port. Then something does happen, and what happens is that the arm swings to a position you did not intend and stops against the table with a noise you have never heard a computer make.

Now you are being careful in a way you never were with a web app, and careful is slow. You are also noticing that the assistant is confident about hardware it cannot see, and that its suggestions assume a robot that is not the one in front of you. Nobody warned you that the hard part would be the last few centimetres.

Can you build a robot the way you build a web app?

You can build most of a robot the way you build a web app, but not the part that decides how much current reaches a motor. The outer layers behave like ordinary software: the interface, the data plumbing, the logging, the state machine that says what the robot should be doing next. Generate all of that, correct it, move on.

The inner loop is different, and not because the code is harder to write. The difference is that your feedback is gone. On the web, wrong code shows you a red error or a broken layout. On hardware, wrong code sometimes shows you nothing at all, sometimes shows you a dent, and sometimes shows you one perfect run followed by an odd one much later.

So the method survives with a single change: you need something between the generated code and the hardware that stops the robot when the code is wrong. A power switch in reach, a limit the motor cannot exceed, a check that refuses a command outside the range you expect. That is the whole discipline.

What is robot middleware, in terms a web developer already knows?

Middleware on a robot is a message bus between the separate programs on the machine, much closer to a publish and subscribe queue than to a web framework. One program publishes camera frames under a name. Another subscribes to that name and never learns which program produced them.

Two things make it unlike the queues you have used. Everything is usually on one computer rather than spread across a network, and the messages never stop, because a robot produces sensor data continuously.

The third difference is the one that catches people. In a web app a late message is a slow page. On a robot a reading that arrives after the decision that needed it is a wrong movement, which is a dent. Late is not a lesser version of correct; late is a different kind of wrong.

You probably do not need any of this yet. One program, one loop, one board is a complete robot, and staying there longer than feels respectable is the right call.

What can you actually build a robot's software on?

There are six honest options: one plain program, a robot kit's own library, microcontroller firmware, ROS 2, a shared-memory middleware, or a simulator before you touch hardware at all. One plain program means Python on a single-board computer with a loop that reads, decides and drives, and it is the correct answer more often than people expect. A kit library is what arrives with the hardware, and it works until you want to change the hardware.

Firmware means C on a small board with no operating system beneath it, which is right whenever the robot only has to react. ROS 2 is the professional default and brings mapping, navigation, visualisation, recording, simulator integration and vendor drivers, in exchange for setup and a pile of new concepts. HORUS is an open-source real-time middleware for Rust, Python and C++ in which all three languages share the same shared-memory ring buffers, so messages between processes on one machine are not serialised; the project is Apache-2.0, is validated in simulation, and matters when a working robot starts stumbling under load rather than when you are choosing your first thing to install.

How do the options compare side by side?

Read the last column first, because for most people holding a new motor, four of these six disqualify themselves immediately.

Nothing here is a ranking, and the first row is where almost everyone should start regardless of ambition.

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

It goes wrong in three recognisable shapes. The first is that nothing happens at all, and the error mentions a serial port, a permission or a device that is not there. That costs a day and teaches you nothing.

The second is units and direction. The assistant writes a plausible number, but your servo wanted radians and got degrees, or positive meant the other way round, and the arm moves confidently to a place your table already occupies. There is no error message, because nothing was invalid. It was just wrong.

The third is the expensive one, because the demo passes. The generated loop assumed it would always finish before the next reading arrived. One value was read while another part was writing it. An exception was swallowed and the robot carried on with a stale number. Everything looks fine for an hour, and then the arm hesitates once. That family of failures is worth reading about before you meet it, because what quietly breaks is rarely what you were watching.

Does any of this change if you are one person with a side project?

Yes, and it changes in your favour: with one person, the constraint is attention rather than architecture, so pick the smallest thing that moves. You have nobody to catch your mistakes, which sounds like a reason for more structure and is actually a reason for less. Every framework you install is another thing that can fail in a way you have to diagnose alone at midnight.

The compensating move is to put the safety in the hardware instead of the code. A power switch you can hit without leaning over the robot. A motor genuinely too weak to hurt anything, chosen deliberately over the one that matches your ambitions. An arm mounted so that its worst move ends in air rather than in a laptop.

Solo builders who do this iterate freely, because a mistake costs a shrug. Solo builders who skip it become cautious, and caution is what kills a side project long before any technical limit does. Buy the weak motor.

What hardware should your first code control?

Your first code should control something that cannot hurt you, cannot hurt itself, and tells you what it is doing. In practice that means a small hobby servo or a low-powered wheeled base rather than an arm that can reach your face, and it means hardware with position feedback, so you can ask where the motor thinks it is instead of guessing from noise.

The second rule is to buy the thing with the most examples online, not the one with the best specification sheet. Your debugging strategy for the next month is searching, and searching only works if other people have already had your problem.

The third rule is to prefer a small computer running Linux over a microcontroller for your first project, because your existing tools work there. You get a shell, a package manager, logs, an editor and the ability to run the same script your assistant just wrote. A microcontroller is a different world with a different toolchain, and it is a fine second project.

What if you want something moving this weekend?

Then write one plain program, install no framework, and accept in advance that you will throw the code away. The weekend path has four steps and each one ends with something visible. Make one motor turn from a script. Read one sensor and print the value. Make the motor stop when the sensor says so. Then make the whole thing repeat without you touching it.

That fourth step is a robot. It is a small one, but it senses, decides and acts in a loop, which is the entire shape of every robot you will ever build. Everything beyond it is more sensors, better decisions and more careful timing.

What will tempt you is installing a framework first, because the tutorials are there and it feels like the serious path. Resist it this weekend specifically. A framework installed before you have made a motor turn gives you two unfamiliar systems failing at once, with no way to tell which one is wrong. Get the motor turning. Then get ambitious.

What do you need to understand yourself, even with an assistant writing the code?

Four things, and only four: units, timing, stopping, and how to tell whether a change helped. Units means knowing whether your hardware speaks degrees or radians, millimetres or metres, and which direction counts as positive. Nobody can check that for you, because the answer is printed in a datasheet or discovered by careful experiment on your specific hardware.

Timing means understanding that your loop has a deadline. If the code takes longer than the gap between sensor readings, the robot acts on old information, and that shows up as jerky motion rather than as an error.

Stopping means having a definite answer to what the robot does when something stops responding. The default answer in generated code is usually to carry on with the last value, which is the worst of the available options.

Telling whether a change helped means recording runs so you can compare two of them. Without that you are adjusting numbers and trusting your memory of how the last attempt looked.

What do you give up by picking a framework early?

You give up the ability to see the whole system, which is the one advantage you actually have as a beginner. A single script means every question has one place to look. Add a framework and a question like why did the arm not move becomes a question about configuration, message names, startup order and versions, all before you reach your own code.

You also give up some of your assistant's usefulness, and this catches vibe coders specifically. An assistant is strongest where there is a mountain of ordinary example code, which describes plain Python and general programming far better than it describes a particular framework release. Ask about framework specifics and you tend to get answers that are plausible, well-structured and quietly out of date, and you will not be able to tell. That failure mode is worth understanding, because assistants recommend heavy stacks by default whether or not the project needs them.

What you gain later is real. Just make sure you are paying for something you have already felt the absence of.

When is ROS 2 the better choice?

ROS 2 is the better choice the moment your robot has to work out where it is and get somewhere on its own, and HORUS is not the answer for someone at that stage. Mapping, localisation and obstacle avoidance are years of work by people who do nothing else, and ROS 2 hands you implementations that have already been tested by thousands of robots in public.

ROS 2 also wins when you bought hardware whose drivers already exist there. Writing a driver yourself is not a project, it is a season.

It wins again when you want to attach a language model to a physical robot, because the pieces between a model and a motor already exist in that ecosystem, and the interesting part of your project is not rebuilding them.

And it wins when your goal is a job or a course credit, since the vocabulary is what gets read on a CV. If any of those describe you, install it this week and accept the setup cost with good grace.

Can an AI assistant write the code that controls a motor?

No, and here is why: an assistant has read a great deal about robot code and nothing at all about your robot. It cannot see your wiring, your gearing, which way your motor is mounted, or whether your servo was assembled with its zero position folded or extended. What it produces is correct for the average robot in its training data, and the average robot is not the one on your desk.

The second reason is that an assistant cannot watch the result. The loop that makes generated web code work is that you see the outcome instantly and feed it straight back. A physical failure does not report itself, so unless you build the observation, the correction step in that loop simply never happens.

What an assistant does well here is everything around the motor: glue code, state machines, logging, tests, parsing a datasheet you paste in, explaining an unfamiliar error. Use it hard for those, and check the motor commands yourself. That division of labour is more useful than either extreme.

Is your web experience useless once code touches hardware?

Partly, but not the way you think: the parts that transfer are the ones you probably consider boring. Version control, so you can get back to the version that worked. Logging, so a failure leaves evidence. Small reversible changes, so you know which change did it. Suspicion of shared mutable state, which is the single most valuable instinct in robotics and the one web developers already have.

What does not transfer is the assumption of a cheap retry. On the web, failure means a refresh. On a robot, failure means a bent bracket and an afternoon. That single difference reshapes how you work: you test the dangerous command with the motor disconnected, you bound the values before you send them, and you make the robot stop rather than guess.

The other thing that does not transfer is the reflex to add a library. In web work, more dependencies usually means faster progress. On a robot, each dependency is another thing that can behave differently when the machine is busy.

How do you decide what to build on?

Decide by writing one sentence describing what must move by the end of the week, then installing only what that sentence requires. The arm picks up a block and puts it down needs one script and the arm's own library. The robot drives forward and stops before it hits the table needs a loop and a distance sensor. The robot maps my flat and drives to a spot I click on a screen needs ROS 2, starting today.

Then keep two habits. First, whenever you finish a session, check that you can still explain everything running on the robot. The first time the answer is no, you have added machinery you are not using, and it will be the thing that breaks.

Second, keep the simple version working while you learn the bigger one. The plain script that still turns the motor is what you fall back on when the new stack will not build.

Here is the whole decision in five lines.

• If you have not made a motor turn yet -> one plain program, because nothing else teaches you what your hardware actually does.
• If your robot must map a room and navigate it alone -> ROS 2, because that is precisely the work ROS 2 has already done.
• If you want to attach a language model to a real robot -> ROS 2, because the parts between a model and a motor already exist there.
• If your working robot stutters whenever another program gets busy -> a shared-memory middleware, because the trouble is between processes on one machine.
• If you are nervous about breaking something -> weaker hardware, because caution costs more side projects than any framework choice.

The HORUS Fit Framework compresses that into five axes you can score any option against: ecosystem size, setup effort, team size fit, deployment target, and licence. For someone coding with an assistant, setup effort and ecosystem size dominate early, because both decide how good the answers you get back will be.

When your robot grows into a timing problem, you want the option already on your shelf. Put HORUS on that shelf now: star it so it is in your list when you start building.