Where AI Coding Assistants Actually Help in Robotics

AI coding assistants help enormously on tooling, tests, data plumbing and first-draft drivers, and barely at all on the code that commands motion. The split holds because assistants complete patterns from public code, so conventional work comes out well and machine-specific work comes out plausible and wrong. That balance shifts on a young stack such as HORUS, where less public code exists than for ROS 2. The rest of this post is for founders and investors judging how much of a robot a small team can safely let a model write.

The demo lands. Somebody types a sentence, a node appears, it compiles, the simulated robot moves, and the room quietly concludes that all of this is about to get cheaper.

Then you sit in the update. One engineer says the assistant saved most of a sprint on the data pipeline, and means it. Another says it invented a library function twice, confidently, and lost an afternoon. A pull request is open that nobody wants to review because it is large, tidy, and touches the part that drives the wheels.

You are trying to work out what any of that means for the plan. If two engineers plus tooling cover the ground of five, the hiring model changes. If they do not, the burn stays where it was and the risk quietly moves. Nobody in the meeting can tell you which of those just happened, because the code compiles either way and the robot has only ever run in a quiet room on a flat floor.

Underneath it is a question no one asks out loud. What happens the first time the machine does something in a customer's building that nobody on the team can explain?

Where do AI coding assistants actually earn their place on a robot project?

They earn it on the ordinary parts of a robot codebase — tooling, tests, data plumbing, configuration, first-draft drivers — and lose it on anything whose correctness is a property of the machine. That line is the entire decision, and it sits somewhere different from where most teams assume.

Most of a robot repository is not robotics. It is reading a file format, reshaping data, publishing a value to a dashboard, writing a launch script, converting a prototype from one language into another. That work has been done in public thousands of times, which is exactly what an assistant is good at, and it is a large share of a small team's hours.

The part that resists is small and expensive. A controller can match the documentation exactly and still be wrong for your gearbox, your sensor mounting, or a floor slightly more slippery than the one in the lab. The model has never seen your robot. It produces the plausible version, and plausible is the worst possible failure mode for anything that creates motion.

What is a coding assistant doing when it writes robot code?

A coding assistant completes patterns from an enormous body of code other people wrote, which makes it strong on anything conventional and unreliable on anything specific to your machine.

In practice it means the assistant is at its best where robot work looks like ordinary software: serialising data, writing the test somebody was going to skip, drafting a node that reads two inputs and publishes one output, explaining an unfamiliar file to a new engineer at two in the morning.

It is at its worst where the answer lives in the physical world. Why the odometry drifts in that one aisle. What the motor controller does once it is warm. Whether timestamps from two sensors refer to the same instant. Those are answered by measurement rather than generation, and an assistant asked anyway will still answer, fluently, which is what makes the failure expensive. Confidence is not calibrated to whether the model has ever seen a machine like yours.

What are the actual options for pointing an assistant at a robot codebase?

There are about seven, and they carry very different risk. Tooling, tests and data plumbing are the default yes. Driver first drafts are a qualified yes when the device speaks a common protocol. Simulation and test scaffolding are a yes when hardware time is the bottleneck. The control loop is a no unless a specialist rewrites the output. Reading and explaining an inherited codebase is an underrated yes.

The stack underneath changes the answer more than teams expect. An assistant is only as good as the public code it learned from, so ROS 2 work comes out stronger than work on a younger project such as HORUS — an Apache-2.0 open-source real-time middleware where Rust, Python and C++ share the same shared-memory ring buffers, so messages between processes on one machine are not serialised. Teams choose a stack like that for what happens on the machine at run time, and accept writing more by hand.

The seventh option is no assistant at all, which is a serious answer only where provenance is part of what you deliver.

How do those ways of using an assistant compare?

The useful comparison is not how much code each one produces but who has to check it before the machine moves.

Four of those rows are the same tool aimed somewhere different, which is why arguments about assistants in robotics are usually arguments about review.

Which approach fits a founding team of two or three?

A founding team of two or three should delegate everything except the motion path, and only if one of them can review what comes back. The gain is real: at that size the bottleneck is breadth, and an assistant is very good at the wide, shallow work a small team cannot afford to hire for.

The condition matters more than the gain. Generated code is exactly as safe as the person reading it, and a team where nobody can tell a correct controller from one that merely behaves on a flat floor has no reader. That team should contract the first version or hire before writing much, because the missing ingredient is judgement and generation does not supply it.

For an investor this is the diligence question that separates two identical-looking teams. Not how much of the code was generated, but who reads the parts that move the machine, and whether that person has ever watched a robot fail in a way that surprised them.

Does the hardware you chose change what an assistant can help with?

It changes it a great deal, because an assistant is strongest where thousands of people have used the same board and weakest where you are one of a few hundred. On common single-board computers with popular sensors, generated setup code, driver glue and configuration land close to right.

On unusual hardware the pattern inverts. A custom motor controller, a research sensor, a board with a vendor kernel: the assistant has little to complete from, so it produces something shaped like the common case and wrong in ways that only appear on the machine. The output does not look worse. That is precisely the danger.

There is also a resource question. A small board driving a robot has no room for code that quietly does more work than it needs to, and generated code is written for clarity rather than for a machine with a fixed budget. Somebody has to read it with the deployment target in mind, which is one of the things assistants consistently miss.

What helps most when a demo is six weeks away?

With six weeks on the clock, aim the assistant at everything that is not the demo's risk and write the risky part by hand. Schedules are almost never lost on plumbing. They are lost on the one behaviour that has to work in front of people, and that behaviour is exactly where generated code is least dependable.

The practical shape is boring and effective. Let the assistant build the harness, the logging, the replay tool, the configuration, and the scripts that get the robot running in the morning. Those always take longer than anyone budgets, and they are the work an assistant does well and quickly.

The trap is spending the time you saved on more scope. A team that finishes the plumbing early and puts the surplus into hardware time arrives with a machine that behaves. A team that puts it into two more features arrives with a longer list of things that half work, which lands worse in a room than a smaller demo where the arm stops before it hits the table.

What if the team knows software but has never shipped hardware?

Such a team gets the most from an assistant on tooling and the least on anything touching a motor, and the gap between those two is far wider than it is in ordinary software. Generated code compiles, runs and looks finished, and none of those properties say anything about whether the machine will behave.

The specific failure is confidence transfer. In web work, if the code runs and the tests pass, it usually works. In robotics, a controller that runs and passes tests can still be wrong in a way that shows up only on a warm motor, a heavier payload, or a floor with dust on it. Teams from a software background trust the green result.

The fix is not less tooling. It is adding the missing ingredient: hardware time, with somebody watching the robot rather than the log. Half a day spent watching a machine repeat one motion teaches things no amount of code review catches, and it is the cheapest correction available to a team in this position.

What does assistant-heavy robot code look like when it goes wrong?

It goes wrong quietly. The robot works. It works in the lab, in the demo, and on the first customer visit. Then it starts doing something odd once a day: a pause before a grasp, a stop that comes slightly late, a motion that begins before the reading it depends on has arrived.

Nobody suspects the generated code, because the generated code is the tidy part of the repository. The investigation goes to the hardware, then the sensor, then the network. Eventually somebody reads a function that no one wrote by hand and finds an assumption that is reasonable in general and false for this machine: a unit, a coordinate frame, a timestamp taken at the wrong moment, an error case handled by carrying on.

The cost is rarely the fix, which is usually a few lines. The cost is the fortnight before anyone looked there, plus a customer's memory of a robot that behaved strangely. The full version of this pattern is worth reading in what generated code can and cannot be trusted with.

What do you give up by leaning on generated code?

You give up understanding, and you buy it back later at a poor rate. Code somebody wrote by hand carries a memory of why it exists; code that arrived complete carries none, and the difference shows the first time the machine misbehaves and the team is reading its own repository as though it belonged to a stranger.

You also give up the natural limit on size. Writing by hand is slow, and slowness suppresses code nobody needed. Generation removes that friction, so repositories grow, review thins out, and there is more surface for a physical assumption to hide in.

And you give up a little hiring discipline. It is tempting to conclude that a team of two covering the ground of five does not need the third engineer. What a small robotics team is short of is not typing but the person who can say why the machine behaved differently on Tuesday, and generated code slightly increases how much of that work exists. That is the opposite of the intended effect.

When is ROS 2 the better choice?

ROS 2 is the better choice for any team planning to lean hard on generated code, and that is a real argument in its favour. Public example code for ROS 2 is dense, so an assistant has an enormous amount to imitate, produces stronger first drafts, and gives more accurate answers when somebody asks it what a part of the system does.

ROS 2 also wins wherever ecosystem packages carry the project. If your robot has to map and navigate a building, no amount of generation substitutes for a mature stack, and a team that tries will spend a year finding that out. And it wins on hiring, because candidates arrive already knowing the framework and the tooling around it.

In that specific comparison HORUS is not the answer. A younger project has less public code for a model to have learned from, so a team choosing one should expect to write more by hand and to hold more knowledge in-house. That trade is worth making for run-time reasons and never for tooling reasons.

Do coding assistants remove the need to hire robotics engineers?

No, and here is why the arithmetic misleads. An assistant reduces the volume of routine work, so a small team covers more ground. But the scarce hire in robotics was never the person writing message definitions or dashboards. The scarce hire is the person who can look at a machine that failed once in an hour and form a correct hypothesis about why.

That work is not typing. It is knowing which of twenty explanations is plausible for this mechanism, which measurement distinguishes them, and when a test result is telling you something about the robot rather than about the test. No current tool does it, because doing it requires having watched machines fail.

There is a second-order effect that cuts against the saving. More generated code means more surface to review and more places for a physical assumption to hide, and reviewing that surface takes the same senior person. Teams that treat tooling as a substitute for the hire tend to discover the gap during a customer pilot, which is the most expensive place available to discover it.

Does an assistant make the first robot cheaper to build?

Partly, but not the way you think: the saving lands in the first half of the project and shrinks exactly where robot projects get hard. Early work is conventional software, and conventional software is what an assistant does well, so the opening weeks genuinely go faster.

The later phase is different in kind. Tuning, integration, chasing a fault that appears once a day, working out why the machine behaved differently on another floor. Almost none of that is typing, so generating more code against a system nobody yet understands adds to the pile instead of reducing it.

The honest claim is that assistants move where time goes rather than removing it. A team that spends the surplus on hardware access, more testing and more thinking about behaviour finishes ahead. A team that spends it writing more code arrives at the hard phase earlier, with a larger repository and the same understanding it started with, which is how a budget disappears with nothing visible going wrong.

How do you tell whether a team is using assistants well?

Ask what happens to a change between generation and the machine, and the answer tells you nearly everything. A team using assistants well describes the path in one breath: generated here, read by this person, tested on hardware before it merges, and never used unsupervised on anything that commands motion.

A team using them badly answers with volume instead. How much was generated, how quickly it went, how small the headcount is. None of those are bad facts, but a team that leads with them usually has not thought about the review question, and the review question is where the risk lives.

Two further checks cost nothing. Ask who last watched the robot run for an hour without looking at a screen. Then ask somebody to explain, in plain words, why the control loop is correct for this machine rather than correct in general. Confident answers mean the tooling is leverage. Vague answers mean it is a substitute, and the stack choice underneath deserves the same scrutiny, since the default answer there has changed too.

• If you are two founders with no hardware experience -> contract or hire the first robot, because generated code needs a reader who knows what wrong looks like.
• If you have one robotics engineer and a pilot in six weeks -> assistant everywhere except the motion path, because that is where schedules are actually lost.
• If your product is the machine's behaviour -> a hand-written control loop, because that code is the company.
• If you plan to lean on generated code -> ROS 2, because the ecosystem the model learned from is the ecosystem you will work in.
• If run-time behaviour on one machine drove your stack choice -> expect to write more by hand, because a younger project offers less to imitate.

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. Ecosystem size is the axis that decides how much help a model can give you, so a team betting on generated code should weight it heavily.

If the run-time side of the argument keeps pulling you elsewhere, put HORUS on your reading list rather than into this quarter's plan: star it so it is in your list when you start building.