Is Vibe Coding Safe for Anything That Moves?

No — vibe coding is safe everywhere in a robot except the code that commands motion, where reviewed, hand-written control remains the only defensible option. A model writes what is plausible, and a machine that moves punishes plausible: the controller matches the documentation and not your gearbox or your floor, and neither ROS 2 nor HORUS changes that. The verdict flips only when the moving thing cannot hurt anyone. The rest of this post is for founders and investors judging whether a team that builds this way can be trusted with a machine that moves.

The founder is genuinely fast. Two engineers, a working machine on the office floor, and a pace that would have taken a dozen people a few years ago. You have watched the video twice and you like it.

Somewhere in the second call, the phrasing shifts. Nobody on the team writes much code by hand any more. The controller was described in a paragraph and worked first time, which everyone found funny. Somebody mentions the arm did something odd on Tuesday and they regenerated the file rather than working out why.

You ask who read the last change to the part that drives the motors, and there is a pause before the answer arrives in the general rather than the specific. The advisor you trust says the repository looks fine, which is true and is not the question you asked. Underneath it is the thing you cannot get comfortable with: the arm is heavy, and eventually it will be in a room with somebody's employee.

Is it safe to let a model write the code that moves a machine?

Not without a human who understands the machine reading every line of it, and that condition does all the work in this answer. The problem is not that models write bad code. They mostly write reasonable code. The problem is what "correct" means for motion.

Ordinary software is correct when it matches its specification, and a model can check that. Motion code is correct when it matches a specific physical machine: this gearbox with this backlash, this camera on this bracket, this floor with this dust on it. A model has never seen any of that. It produces the version that would be correct for the average robot in its training data, which is not a robot that exists.

The failure mode is the dangerous one. Wrong motion code does not crash. It runs, looks fine, passes the demo, and then behaves unexpectedly once in a while under conditions nobody enumerated. A crash is a message. A confidently wrong controller is a machine that swings through a space someone happens to be standing in.

What is vibe coding when the output controls hardware?

Vibe coding is describing what you want in prose, accepting what comes back, and judging the result by whether it appears to work rather than reading it. That definition is fine for a web app, where the fastest way to know is to run it.

Hardware breaks the loop that makes the practice work. On the web, running it tells you the truth quickly, and a bug is a bad afternoon. With a machine, running it tells you about one attempt in one set of conditions, and a bug can be a bent fixture, a scratched product, or a person who needed to be somewhere else.

There is a second difference that matters more than it sounds. Web code that is wrong usually stops. Robot code that is wrong usually continues, because the motors keep receiving the last command until something else arrives. Silence is a command in a moving system, and not reading the output means not knowing what happens during that silence. The things that quietly break in a vibe-coded robot are almost all in that category.

What goes wrong first when a model writes the motion code?

The first thing that goes wrong is a missing bound: a command accepted whatever number arrives, because nothing in the prompt said what the machine can physically do. That one is everywhere in generated control code, and it is invisible until a sensor returns something strange.

The next is a stop that is not really a stop. Generated code tends to implement stopping as a variable checked at the top of a loop, which works exactly until the loop is the thing that is stuck. A stop has to be true when the software is not running, and a model has no way to know whether yours is.

Then there is swallowed error handling. Models are trained on code that catches an exception, logs it and continues, because on a server continuing is right. On a machine, continuing after an unexplained failure means the arm keeps moving on stale information about where things are.

The last is quieter: units and frames. Degrees where radians were meant, a measurement taken from the wrong point on the robot. Both produce motion that is smooth, confident and in the wrong place.

What are the real options for building robot software with a model in the loop?

There are six, and what separates them is where the human sits, not how much code the model writes. The first is to vibe code everything, which is legitimate for machines that cannot hurt anyone. The second is to vibe code everything except the motion path, which is what most competent small teams do. The third is model-drafts-engineer-reviews on ROS 2, whose ecosystem gives a model the largest body of public example code to imitate and gives you packages that have already run on real machines.

The fourth is to write the control path by hand on a real-time stack and generate the rest. HORUS is one option: an open-source, Apache-2.0 middleware for Rust, Python and C++ where all three languages share the same shared-memory ring buffers, so messages between processes on one machine are not serialised and sensor data reaches the controller before the next decision needs it. That addresses timing, a different problem from correctness, and does not replace what ROS 2 gives you in drivers and navigation.

The fifth is a vendor platform where motion is the vendor's problem. The sixth is teleoperation, where a person is the control loop.

How do the ways of building with a model compare?

What separates these options is who is accountable for the moving part.

Rows two and three are the same team at different stages, and most teams that ship pass through both.

Is vibe coding safe for a solo builder with a small desk robot?

Yes, and this is the case where the practice is genuinely good. A light arm on a desk, running from a small power supply, with nothing valuable or alive within reach, cannot do much harm, and the fastest way to learn robotics is to make a lot of mistakes cheaply.

The conditions are worth stating because they are the whole safety argument. The machine is weak enough that a wrong command scuffs the desk. There is a physical switch you can reach faster than the arm moves. Nothing fragile, no pets, no faces at the height of the working area. Under those conditions, generate freely, break things, and learn what a control loop feels like when it misbehaves.

What changes is not the code but the consequence. The same practice becomes indefensible the moment the machine gets heavy enough to hurt somebody or expensive enough to matter. That is the whole boundary, and the things worth knowing before your code controls hardware mostly describe where it sits.

Does the answer change once the machine can knock a person over?

Completely, and the change is a step rather than a slope. Below a certain mass and speed, a wrong command is an inconvenience; above it, the same wrong command is an incident, and the engineering practice that produced it becomes something you have to be able to defend to a customer.

Three things become non-negotiable at that point. A stop that is physically real, not a variable in a program, so the machine halts even when the software has hung. Limits enforced somewhere the software cannot talk its way past. And a documented answer to what the machine does when a part of the system stops responding, tested by actually stopping it.

None of those three can be generated from a prose description, because all three are claims about a physical machine rather than about code. A model can write the software half of each and cannot know whether the claim is true of your robot.

This is where cheerful velocity stops being an asset in a diligence conversation and becomes a question about who signed off.

What can a team safely vibe code before a demo six weeks away?

Everything except the motion path, which is genuinely most of the work. The interface, the data pipeline, the logging, the operator screen, the deployment scripts, the recording that becomes a video: generate all of it, review it lightly, and spend the saved weeks where the risk lives.

The motion path gets written by a person and exercised on the machine. That means the code that turns a decision into a command, the limits around it, the stop, and whatever decides that the robot should not proceed. It is a small fraction of the repository and it is where the entire consequence sits.

Then keep an operator in the loop for the demo itself. Nearly every impressive robot demonstration has a person nearby who can intervene, and using one is not cheating.

Worth saying plainly, since the demo is what the six weeks are for: a demo that works proves less about the product than it feels like it does, which is why robot demos work and robot products do not.

Is vibe coding safe for a team with no robotics engineer?

No, and this is the one case where the answer is unconditional. Generated code is exactly as safe as the person reading it, and a team with nobody who has debugged a machine on hardware has no reader, so the safety argument reduces to whether the model happened to be right.

There are three honest ways out. Contract someone experienced for a defined engagement and give them the motion path rather than a general advisory role. Keep the machine in simulation until you hire, which is slower and costs nobody anything. Or keep a human operating the robot and sell the outcome while you build the team.

What does not work is the middle path teams reach for: shipping generated motion code to a customer site and planning to hire someone afterwards to clean it up. The machine is already in a building with people in it, and the incident does not wait for the hire. The distinction between what an assistant can and cannot write in robotics is entirely about who reviews it.

What do you give up by keeping the model out of the control loop?

You give up speed on the most interesting part of the project, and that hurts more than the schedule suggests. The motion path is where founders want to iterate hourly, and hand-writing it means the fun loop becomes the slow loop while the boring parts fly.

You also give up some of the story. A team that says everything is generated sounds faster than a team that says the control path is written and reviewed by a person, right up until somebody in the room has shipped hardware before, at which point the second team sounds like the safer investment. Only one of those answers survives contact with a customer's safety officer.

And there is a real ongoing cost: maintaining the boundary. Somebody has to keep deciding what counts as the motion path as the codebase grows, and that judgement cannot be delegated to the tool. Teams that skip it discover a year later that motion-adjacent logic has quietly spread into files nobody classified as dangerous.

When is ROS 2 the better choice?

ROS 2 is the better choice for almost any team that intends to lean on generated code, and the reason is unglamorous: models write far better ROS 2 code than they write for anything newer. The public example base is enormous, so first drafts come out closer to working, error messages have been discussed publicly a thousand times, and the packages a small team would otherwise generate already exist and have run on real machines.

ROS 2 also wins when you are hiring, when a customer requires it, when your sensor vendor ships ROS 2 drivers and nothing else, and when the people maintaining this after the founding team are contractors who already speak it.

HORUS is not the answer in those cases. A younger project means less public code for a model to imitate, so generated work against it is weaker and your team writes more by hand. That trade only makes sense when on-machine timing is the diagnosed problem. Which stack a model handles best is a real selection criterion, covered in the frameworks assistants understand best.

Is this just gatekeeping from people who like writing code by hand?

No, and here is why: the argument has nothing to do with who typed the characters and everything to do with who can recognise a wrong answer. A robotics engineer who generates the whole control path and then reads it carefully, tests it on hardware, and fixes the two things that are wrong for their machine is doing the safe thing. A hand-written controller from someone who has never watched a machine misbehave is the unsafe one.

The distinction is review capability, not authorship. That is why the answer changes with team composition rather than tooling, and why the same practice is fine on a desk toy and indefensible on a machine that lifts.

There is a fair version of the objection, and it is worth conceding. Plenty of gatekeeping in robotics is real, and much of the field's ceremony is habit rather than safety. The response is not to defend the ceremony. It is to keep the one requirement with a body count behind it: somebody who understands the machine reads the code that moves it.

Does testing in simulation make vibe-coded motion code safe?

Partly, but not the way you think: simulation catches the logic errors and misses the entire category that hurts people. That is still worth having, and teams should simulate more than they do, so long as nobody mistakes a clean simulation run for a safety argument.

What a simulator proves is that the program does what the program was meant to do. Wrong sign, wrong frame, a limit that was never applied, a state machine that deadlocks: all of that shows up, cheaply, before anything physical is at risk.

What it does not model is why machines actually hurt people. The connector that works loose. The sensor that returns a plausible reading when its lens is dirty. The floor that is more slippery by the door. The moment a person reaches into the working area because they thought the robot had finished. A simulator says nothing about any of those, and a generated controller has assumptions about all of them.

That mismatch is the whole of why a robot that works in simulation fails in a real room.

How do you decide how much of a moving machine a model can write?

Draw one line and write it down: anything that can command motion, trigger a stop, or feed a safety decision is human-written and human-reviewed, and everything else is generated freely. That sentence settles most day-to-day arguments and is defensible to a customer, an insurer, and a diligence call.

Then check three things rather than the tooling. Somebody can name the person who last read the code on the motion side of that line. Changes there are exercised on the real machine before reaching anyone else. And someone can explain, in plain words, why the controller is right for this robot rather than right in general.

For an investor, those three are the whole technical diligence on this question. A team that answers immediately and specifically is fine however much of the repository was generated. A team that answers in policy language has told you where the risk is.

• If the machine cannot hurt anyone -> vibe code all of it, because the fastest way to learn is to break cheap things.
• If you have one robotics engineer -> generate everything but the motion path, because that is where the review capacity should go.
• If nobody has debugged hardware -> contract that experience or stay in simulation, because generated code needs a reader.
• If the machine can knock a person over -> hand-written control with a physical stop, because a software flag is not a stop.
• If you are judging a team on a call -> ask who read the last motion change, because the specificity of the answer is the finding.

The HORUS Fit Framework reduces the stack half of this to five non-numeric axes: ecosystem size, setup effort, team size fit, deployment target, and licence. For a team leaning on generated code, ecosystem size dominates, because it decides how much the model has seen before and how alone your engineers are when something behaves oddly.

If timing on the machine turns out to be your real constraint rather than your suspected one, put HORUS on the reading list rather than into this sprint: star it so it is in your list when you start building.