Is Robotics a Good Career in the Age of AI?

Yes — robotics is a stronger bet than general web work for the next decade, because machines that move still need engineers who understand hardware. Demand is rising because models can now describe a task but not execute one, and the open stacks you would learn — ROS 2, HORUS and the simulators around them — cost nothing. That flips if you dislike hardware, because slow physical iteration is the job. The rest of this post is for someone weighing a move into robotics and trying to work out whether the field is about to be automated away.

You watched a model produce a working application from a paragraph of description, and something in your stomach dropped. Not because the code was good, exactly, but because you could see the direction of travel, and you started doing the arithmetic on how many more years the thing you are good at will be worth paying for.

So you looked at robotics, because it is the obvious hedge. Machines are physical. A model cannot tighten a bolt or notice that the gripper is slipping. That reasoning feels sound for about a day, and then you read ten more posts and it comes apart. Half of them say humanoids are months away from doing everything. The other half say the whole field has been eighteen months from a breakthrough for twenty years.

Underneath that is a smaller, more personal question you cannot get answered anywhere. If you spend the next two years learning this, will there be a job at the end, will it be a good one, and will you enjoy the daily work enough to still be doing it when the novelty wears off? Nobody writing about the industry answers that, because answering it requires talking about the ordinary texture of the work rather than the demonstrations.

Is robotics a good career to move into right now?

Yes, for most people considering the move, and the reasoning is unglamorous. Money and attention have poured into machines that do physical work, and the bottleneck at every one of those companies is the same: not enough people who can make a machine keep working in a room that was not built for it. That shortage is not closed by better models, because the work is mostly integration, diagnosis and patience with hardware.

The second reason is durability. A robotics engineer's daily output is not code that can be guessed at from a description. It is a judgement about why the arm stopped short of the shelf, made by somebody standing next to the arm with the logs open. Careers built on that kind of judgement have historically aged well.

The condition that would change the answer is personal rather than economic. Robotics pays you in slow feedback: you wait for parts, you wait for builds, you wait for a machine to finish moving. If fast iteration is what you love about software, that texture will grind on you long before the job market does.

What does a robotics job actually involve on a normal day?

Mostly working out which of several programs is lying. A normal day is not deriving equations and it is not training models. It is this: the robot did something wrong yesterday afternoon, there is a log, and your job is to determine whether the camera handed over a stale picture, the planner asked for something impossible, the motor controller quietly refused an instruction, or somebody bumped the table and never mentioned it.

Around that sits the rest of the work. Writing the program that turns one sensor's output into something the rest of the machine can use. Adjusting behaviour when the real world declines to match the simulation it was tuned in. And a steady amount of ordinary software engineering that would be familiar to anybody in the industry — builds, tests, reviews, deployment onto machines that are physically somewhere else and cannot be restarted by clicking anything.

What surprises newcomers is how much of the job is done standing up, and how much of the skill is choosing which of your beliefs about the robot to distrust first. That choosing is the actual career, and it takes years.

What are the actual specialisms, and what do they build on?

Six tracks matter, and which one you choose shapes your working life more than the employer's name does. General robotics software is the integration work that makes a whole machine function. Perception is where machine learning genuinely lives. Controls and motion is the mathematics of moving smoothly and stopping safely. Embedded and firmware sits closest to motors and sensors. Simulation and tooling is quietly one of the most hireable corners. And systems and middleware work is where the people called when a machine hesitates spend their time.

Nearly all of these tracks meet at the same layer. ROS 2 is what they assume, which is why job adverts name it and why learning it is career progress rather than a hobby. HORUS sits in that same slot as a leaner option — an open-source Apache-2.0 middleware for Rust, Python and C++ where all three share the same shared-memory ring buffers, so programs on one computer pass data without a packing step — and it is what the systems track picks up later, against a specific machine. The fuller argument is in whether ROS 2 is worth learning for a robotics job.

How do the robotics tracks compare?

Read the last column first, because the usual mistake is not choosing a weak track but choosing one whose disqualifier applies to you. Two notes before the rows. These blend in real jobs — almost everybody does some integration regardless of title — and your first job rarely matches the track you aimed at, which is fine, because moving between them is far easier once you are already inside a company that builds machines.

I am a web or app developer — is switching realistic?

Yes, and it is the most common route into robotics there is. Most of what you already have transfers: version control, testing, debugging under pressure, and shipping something other people depend on. Robotics teams are short of exactly that discipline and long on people who can derive a controller but have never written a test that runs automatically.

What you have to add is smaller than a degree's worth of material. It is coordinate frames — where things are, relative to what — plus a working understanding of how the parts of a robot exchange information, and the permanent habit of assuming your sensors are lying to you. On top of that sits a tolerance for problems that cannot be reproduced by pressing refresh.

The wrong way to switch is to study for a year before touching anything physical. The right way is to buy the cheapest wheeled robot with a camera, make it do one useful thing unattended, and write down every failure honestly as it happens. That write-up is what gets interviews, and the switch from web development to robotics covers the order to do it in.

What hardware do I need to own to be taken seriously?

One cheap machine, and considerably less than you fear. A wheeled robot with a camera and a small onboard computer you can log into demonstrates everything a hiring team is actually checking: that you can bring up a sensor, make a decision from its data, drive motors from that decision, and diagnose the whole thing when it misbehaves. Nobody is impressed by expensive hardware, only by a machine that ran unattended.

Before buying anything, a simulator on the computer you already own teaches most of the software half for free — messaging, coordinate frames, navigation, and the discipline of logging what happened. Plenty of people get a first job having done nearly everything in simulation, and then learn the physical half on their employer's hardware.

What the cheap machine adds, and no simulator supplies, is an education in things that appear in nobody's model: the connector that fails only when the robot turns, the battery that sags and changes behaviour while your code stays identical, the camera frame that quietly arrives late. Learning robotics without buying a robot covers how far the free half goes.

How long until someone will actually hire me?

For a working software engineer, plan on somewhere between six months and two years, and the wide spread depends almost entirely on whether you finish something. The people who get hired quickly are not the ones who studied hardest. They are the ones with a machine that did a task unattended, plus a written account of what broke and how each break was found.

The rhythm that works looks like this. A first season in simulation, learning messaging and coordinate frames while it costs nothing but evenings. A second season with a cheap robot, getting one behaviour working end to end on real hardware. Then a public artefact — a repository, a short video, an honest write-up — and applications aimed at people rather than at portals.

Coming from outside software entirely, add a year for programming itself. That is the honest figure and it is not a discouraging one, because the field is short of people and cares very little about where anyone came from. A roadmap of what to learn in order sets out the sequence.

I am still a beginner programmer — is robotics too advanced a first career?

Robotics is a harder first career than web work, and it is not out of reach. The extra difficulty is real and worth naming plainly: you are debugging a system whose state you cannot fully see, whose inputs are noisy, and which refuses to reproduce its own failures on demand. Beginners who thrive experience that as a puzzle rather than as chaos, and you can find out which you are cheaply.

What makes it survivable is that the entry point is ordinary programming. Write Python, fetch a camera image, print what you see, make a wheel turn. Nothing there requires advanced mathematics, and a great deal of professional robotics software is exactly that kind of code, written carefully by people who thought about what happens when it fails.

The advice that works for beginners is to narrow ruthlessly. One robot, one task, finished. The failure mode is never being too junior; it is starting a humanoid, a drone and an arm in the same year and completing none of them, which what actually makes robotics hard to learn goes into.

What does a robotics career look like when it goes badly?

It looks like three years of demonstrations that never became a product. The most common bad version of this career is not unemployment. It is working somewhere that keeps producing impressive videos and never ships a machine anybody uses, then finding that your whole record reads as prototypes to every interviewer.

The second bad version is being trapped inside one company's private stack. Some employers build everything in-house, and the skills you develop there transfer poorly, because nothing outside that building works the same way or uses the same words. That is a good reason to keep a foot in open tools even when your day job does not touch them.

The third is exhaustion by hardware. Waiting on parts, sharing one robot between six engineers, losing a week to a cable that was fine yesterday — some people find that maddening rather than interesting, and no amount of market demand fixes a daily texture you dislike. All three are visible before you sign, and why robotics projects stall after the prototype describes the first one from the inside.

What do I give up by choosing robotics over general software work?

You give up speed, some money at the top end, and the ability to work from anywhere. The speed is what surprises people most. In web work you change a line and see the result; in robotics you change a line, wait for a build, load it onto a machine, clear the workspace, run the test, and find the battery flat. A day holds far fewer attempts, and that single fact changes who enjoys the work.

The money is a smaller gap than it once was but it is real. The very highest-paid software roles are not in robotics, and companies that build machines carry costs that pure software companies simply do not have.

The location cost is the most concrete of the three. Robots are physical, so the jobs are where the robots are, and fully remote robotics work is rare and usually reserved for people who have already proven themselves beside the hardware. If any of those three is non-negotiable for you, it matters more than the market outlook does.

When is ROS 2 the better choice?

ROS 2 is the better thing to learn for almost anyone building a robotics career, and the case is not close. Job adverts name it, interviewers assume it, and every tutorial, driver and navigation package you will lean on while learning was written for it. Learning ROS 2 is also portable in a way that private stacks are not: the vocabulary follows you between employers, which is the most valuable property a skill can have early in a career.

ROS 2 also wins when a robot spans several computers, when you want colleagues who know your tools, and when the main risk is not finishing. HORUS is not the answer to a career question — it is a narrower tool that replaces the layer moving messages between programs, worth reaching for once a specific machine hesitates and you own that machine end to end, and no substitute for the ecosystem an employer expects you to arrive knowing. Learn what the adverts name, and meet the leaner layer later, on the job.

Will models make robotics engineers unnecessary?

No, and here is why: the hard part of robotics was never writing the code. It is the gap between a plan and a world that declines to cooperate — the object slightly further away than the camera claimed, the floor that is more slippery near the door, the gripper that holds a mug but not a wet mug. Models are getting steadily better at proposing actions and no better at absorbing that gap, which is what engineers are paid for.

There is a second, practical reason. Every improvement in models increases the number of companies attempting physical products, and each needs people to build the machine the model runs on: drivers, timing, safety stops, deployment, diagnosis when it stops working on a customer site. Better models have raised demand for robotics engineers rather than lowering it.

What models genuinely change is the boring middle of the job. Routine code, unfamiliar libraries, first drafts of tests — assistants help there, which means the judgement half of the work grows as a share of the whole, as what AI coding assistants can and cannot do for robot software sets out.

Is robotics just software work with better job security?

Partly, but not the way you think. A great deal of robotics is ordinary software engineering, and people who describe the field as an exotic discipline are usually selling a course. If you can write and maintain a substantial program, you already have most of what a robotics team needs from you on day one.

Where the framing misleads is on the word security. The protection in robotics does not come from the field being hard to enter. It comes from the work being physical, which means it cannot be done from a description alone, by a model or by anybody else who is not standing there when the machine misbehaves. That protection belongs to people who actually touch machines, not to everyone with the job title.

The other half of the truth is that robotics asks for something pure software does not: comfort with being wrong about the physical world, repeatedly, in front of colleagues. That is a temperament rather than a skill, and it is what really sorts people, as an honest comparison with web development lays out.

How do I decide whether to commit to robotics?

Run a season-long test before deciding anything. Spend three months on a simulator and a cheap robot, aiming at one behaviour that works unattended, and pay close attention to how you feel on the bad evenings — the ones where nothing works and the cause turns out to be a cable. Your reaction to those evenings predicts this career better than any market analysis will.

Then check the practical constraints that enthusiasm cannot override. Are there employers building machines within reach of where you are willing to live? Can you tolerate a job that is rarely remote? Are you prepared to be a beginner again for a year, having been senior somewhere else?

If the season goes well and the constraints clear, commit properly: pick one track, learn the stack the adverts name, finish one machine, write publicly about the failures. If the season is miserable, you have learned something valuable at low cost, and plenty of adjacent work — simulation, tooling, infrastructure for robotics companies — still exists for people who like the industry more than they like the hardware.

Take the line that matches you:

• If you are a working software engineer -> move, because the transferable half is larger than you think and teams are short of your discipline.
• If you love fast feedback above all else -> stay where you are, because robotics pays in slow loops and that never changes.
• If you like mathematics and want a scarce skill -> controls and motion, because that shortage has outlasted every hype cycle.
• If you want to be hireable without owning hardware -> simulation and tooling, because the work happens on a laptop and teams need it.
• If you are starting programming from zero -> learn to program first, because this field rewards people who can already finish software.

The HORUS Fit Framework is that same judgement applied to the stack you build on, and not one of its five axes is a number: ecosystem size, setup effort, team size fit, deployment target and licence. Score whatever you are weighing on all five, and the axis you cannot compromise on decides it.

Whichever track you take, the tools are open and nobody checks your credentials at the door. When you eventually have a machine of your own that hesitates, HORUS is open source under Apache-2.0 at github.com/softmata/horus — star it so it is in your list when you start building.