Can AI Coding Assistants Write Real Robotics Software?

AI coding assistants write real robotics software wherever a human engineer reviews it, and are a liability on code that moves the machine unreviewed. An assistant is strong where public example code is dense, so ROS 2 work comes out better than work on a younger stack such as HORUS, and weak where correctness depends on hardware it cannot see. That flips when nobody on the team can review the output. The rest of this post is for founders, technical partners and investors judging how much of a robot a small team can safely let a model write.

The demo is genuinely impressive and everybody in the room has seen it. Somebody types a sentence, a node appears, it compiles, it publishes, the simulated robot moves.

Then the real week starts. One of your engineers says the assistant saved most of a sprint on the data pipeline, and means it. Another says it invented a library function that does not exist, confidently, twice, and lost an afternoon. A pull request lands that nobody wants to review because it is large, tidy and touches the part that drives the wheels. Somebody asks whether the team should review it line by line or trust it, and there is a silence.

Underneath it is the question nobody asks in a standup. If two engineers plus tooling cover the work of five, what are you hiring for, and what happens the first time the machine does something in a customer's building that nobody can explain.

Can an AI coding assistant write robot software you would put on a machine?

Yes for most of the codebase and no for the part that produces motion, and the boundary between those two is the entire decision. An assistant produces working, ordinary code for the majority of a robot repository, because most of a robot repository is ordinary: configuration, message definitions, data plumbing, tests, logging, dashboards, a driver for a device that speaks a protocol thousands of people have already implemented.

The part it cannot be trusted with alone is the code whose correctness is a property of a physical machine. A controller can match the documentation exactly and still be wrong for your gearbox, your sensor mounting, or a floor that is slightly more slippery than the one in the lab. The model has never seen your robot. It produces the plausible version, and plausible is precisely the wrong failure mode for anything that moves.

So the useful framing is not whether assistants can write robotics software, because they can. It is which parts you let them write unsupervised.

What does an AI coding assistant actually do inside a robotics codebase?

An assistant does pattern completion against an enormous body of code other people wrote, which makes it excellent at anything conventional and unreliable at anything specific to your machine. That single sentence predicts almost every result you will get from one.

In practice this means it is at its best on the parts of a robot project that feel like ordinary software. Serialising and reshaping data. Writing the test you were going to skip. Converting a Python prototype into C++ or Rust. Producing a first draft of a node that reads two inputs and publishes one output. Explaining an unfamiliar part of the codebase to a new engineer at two in the morning.

It is at its worst where the answer depends on things no text contains: what your motor controller does when it is warm, or why your odometry drifts on that one aisle. Those questions are answered by measurement on hardware, not by generation, and an assistant asked to answer them will still answer.

What are the real options for getting robot software written this year?

There are five, and most teams end up on a blend of three of them. The first is an assistant-heavy team on ROS 2, the combination that currently works best, because ROS 2 has an enormous body of public example code for a model to have learned from. The second is an assistant plus a strong robotics reviewer, which is the same thing with the safety property added. The third is hiring robotics engineers and using assistants as ordinary tooling. The fourth is contracting the first version out to a robotics shop. The fifth is a vendor platform where most of the software already exists and you write behaviour on top.

The stack choice interacts with this more than teams expect. HORUS, an Apache-2.0 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, is a newer project with far less public code for a model to imitate. That trade points in a clear direction.

How do the ways of getting robot code written compare?

The comparison that matters is who reads the code before it reaches the machine, not how the first draft was produced.

Four of the seven rows are the same team with a different review process, which is where the real decision usually sits.

Which approach fits a two-person team with no robotics background?

Two people with no robotics background should contract the first version or hire before writing much, because an assistant cannot supply the judgement that is missing. Generated code is only as safe as the person reading it, and a team that cannot tell a correct controller from one that merely behaves in a quiet room has no reader.

This is the most expensive mistake in the category, and it does not look like one for months. The software works. The robot moves. The demo is fine. Then the machine meets a floor, a person, or a Tuesday the quiet room did not contain, and the team owns a codebase nobody can reason about, in a style nobody chose.

The workable version for a team like this is narrow: use the assistant for everything that is not motion, buy or contract the motion, and hire the robotics engineer earlier than the plan says. Two software engineers plus tooling plus one robotics engineer is a genuinely strong team. Two software engineers plus tooling is a demo company.

Does your hardware change what an assistant can safely write?

Your hardware changes it completely, because the risk of a wrong line scales with what the line can move. Code that draws a dashboard cannot injure anybody. Code that decides when to stop a heavy machine near a person can, and no amount of tidiness in the generated version changes that asymmetry.

There is a second, less obvious hardware effect. The more unusual your hardware, the less an assistant has seen anything like it, and the more confidently it produces code for a device you do not have. A common depth camera gets a good first draft. A motor controller you designed in-house gets fluent nonsense, because the model is completing a pattern from adjacent hardware.

The rule most teams converge on is a line through the repository rather than a policy about the tool. Anything that can command motion, trigger a stop, or feed a safety decision is written and reviewed by a person who has watched the machine run. Everything else should be delegated aggressively.

What should you do if the pilot is six weeks away?

With six weeks, use the assistant everywhere except the motion path, and do not restructure your team around it. Six weeks is not enough time to change how a team works and also ship, and a pilot is won by the machine doing its job in front of somebody, not by how the code was produced.

Spend the tooling on the parts that always eat a pilot schedule. Data recording and the small tools that let you look at what happened. The configuration and launch mess nobody wants to own. The tests that tell you on Thursday whether Wednesday's change broke the thing that worked. All of that is conventional software, all of it is where a pilot loses days, and all of it is what an assistant is good at.

Keep the loop that produces motion in human hands for these six weeks, not on principle, but because debugging generated control code under deadline is the specific situation where teams lose a week they did not have.

What level of robotics knowledge do you need to review generated code?

Enough to know what a wrong answer looks like on real hardware, which is a lower bar than writing the code and a much higher bar than reading it. A reviewer does not need to be able to derive the controller. A reviewer needs to look at a change and think about what the machine will do at the moment the sensor lies to it.

Concretely, the reviewer should answer four questions about any change that touches motion. What happens if this message never arrives. What if it arrives late. What if the value is stale rather than wrong. And what does the machine physically do while this code is deciding. Those four catch most of what generated robot code gets wrong.

If nobody on your team can answer those four about your own robot, the problem is not the assistant. Generated code has simply revealed a gap that was always there and was previously hidden by how slowly you were writing code.

What does assistant-written robot code look like when it fails?

It fails as behaviour, not as a crash, and that is what makes it hard. Generated code is usually syntactically clean and often passes the tests it was asked to pass, so the failure does not arrive as a stack trace. It arrives as a robot that is slightly wrong in a way nobody can source.

The pattern repeats across teams. A change lands that looks like a tidy refactor. Two weeks later the machine behaves differently from one run to the next and nobody connects the two, because the change was reviewed by someone who read it as text rather than as motion. Or a timeout appears with a plausible value that nobody chose, and it is wrong for your machine in a way that only shows up when the floor is wet.

The common thread is that generated code inherits no accountability. When a person writes a subtle line, somebody remembers writing it. When a model writes it, the memory does not exist, and every investigation starts from zero.

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

You give up your team's mental model of its own machine, which is the asset that makes the second year cheaper than the first. Understanding is built by writing things, getting them wrong, and finding out why, and a team that skips that path produces working software without producing the understanding that normally comes attached.

The cost shows up late and off the balance sheet. Debugging takes longer because nobody has the intuition that comes from having written the thing. Architecture drifts, because a model optimises the change in front of it rather than the shape of the system, so a codebase accumulates reasonable local decisions and ends up incoherent. New engineers onboard onto code with no author to ask.

None of this argues for refusing the tooling, which would be an expensive gesture. It argues for deciding deliberately which parts of the system your team must understand personally, and treating those as human-written on purpose. For most robotics companies that list is short: the control loop, the state machine that decides what the robot does next, and the safety path.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever you intend to lean on generated code, and HORUS is not the answer in that situation. An assistant reflects what has been written publicly, and ROS 2 has an enormous body of public code, tutorials, packages and answered questions behind it. Ask for a ROS 2 node and you get something close to conventional. Ask for the same on a newer project and the first draft comes from a model that has seen very little of it.

ROS 2 is also better when your team is learning, when you need navigation or mapping rather than a tuned loop, when you are hiring, and when your robots are spread across a network. In those cases the ecosystem does the heavy lifting and the tooling amplifies it.

The case for a newer stack is a run-time case, not a code-generation case. Teams choose one for what happens on the machine while it runs, and accept writing more themselves. Make that trade on the machine's behaviour, not on how much code a model can produce.

Do AI coding assistants remove the need to hire robotics engineers?

No, and here is why: the scarce hire was never the person writing routine code. The scarce hire is the engineer who can look at a machine that behaved oddly on Tuesday and produce a plausible cause by Wednesday, and no assistant does that, because doing it requires having seen the robot.

What changes is the ratio. A robotics engineer with tooling covers more ground and spends less of the week on message definitions and build configuration. That is a real gain worth having. It makes a five-person team behave like a slightly larger one. It does not make a zero-robotics team behave like a robotics team.

There is also an effect that cuts the other way. Generated code means more surface to review, more to maintain, and more places for a physical assumption to hide. Some of the capacity you gain comes back as review load, and teams that do not plan for it end up with a backlog of changes nobody senior has read. That is one of the ways projects stall after the prototype.

Does an assistant make a small robotics team move faster?

Partly, but not the way you think: the gain is real in the first half of a project and shrinks exactly where robotics projects are hardest. Early on, most of the work is conventional software, and conventional software is what an assistant does well, so the early weeks genuinely go better.

The later phase is different in kind. It is tuning, integration, chasing a fault that appears once a day, and finding out why the machine behaved differently on another floor. Almost none of that is typing. The bottleneck is understanding a physical system, and generating more code against a system you do not understand adds to the pile.

So the honest version of the claim is that assistants shift where your time goes rather than reducing the total. A team that uses that shift to buy more hardware time, more testing, and more thinking about behaviour comes out ahead. A team that uses it to write more code faster arrives at the hard phase earlier with a larger codebase and the same understanding it started with.

How do you decide how much of your robot to let a model write?

Draw one line through the repository 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 delegated. That line resolves most of the day-to-day arguments and is defensible to a customer, an insurer and an investor.

Then check the process rather than the tool. Every change that touches the machine gets read by someone who has watched the machine run. Every change gets tested on hardware, not only in simulation, before it reaches a customer. And somebody on the team can explain, in plain words, why the control loop is correct for this robot and not merely correct in general.

If those three hold, use the tooling as hard as you like. If not, the gap is in your team rather than the assistant, and more generated code widens it. It is also worth settling the stack question first, since the stack you build on decides how much a model can help you at all.

• If you are two people with no robotics engineer -> contract or hire first, 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 the schedule is actually lost.
• If your differentiation is the machine's behaviour -> human-written control loop, because that code is the company.
• If you are hiring and want candidates who arrive productive -> ROS 2 with tooling, because the ecosystem and the model both know it.
• If provenance is part of what you deliver -> generated code only where you can account for it, because an auditor will ask.

The HORUS Fit Framework reduces the stack half of this to five axes: ecosystem size, setup effort, team size fit, deployment target, and licence. Ecosystem size decides how much help a model can give you, so a team leaning on generated code should weight it heavily.

If the machine's run-time behaviour keeps pulling you toward a different stack, put HORUS on your reading list rather than into this sprint: star it so it is in your list when you start building.