How Robotics Programming Is Opening Up to Everyone

For years, I’ve watched capable engineers explain exactly how a robot should behave to solve their problems, then get told they need to hire a specialist to implement it. A facilities manager who understands inspection routines perfectly can’t program an autonomous robot to execute them. An agricultural engineer who knows crop stress indicators can’t deploy the monitoring system. The capability exists, but access doesn’t.

I’ve seen this pattern before. Over thirty years founding and leading a software company, I’ve witnessed technology after technology follow the same trajectory: from specialist-only domain to accessible tool for everyday developers. What’s happening in robotics now mirrors exactly what I watched unfold across desktop development, web applications, and mobile platforms throughout my career.

In the late 1990s, Microsoft’s .NET suddenly let Visual Basic developers build sophisticated multi-threaded applications that previously required C++ expertise. When smartphones emerged, each platform demanded its own specialist skills until agnostic frameworks like Xamarin, React Native, and Flutter arrived. Within a few years, they became standard. Perhaps most striking, fifteen years ago, building production-grade backend systems with JavaScript was dismissed as absurd. Today, NodeJS is one of the most popular stacks for full-stack development.

That’s the transformation robotics is entering now, and it’s happening because of decisions the robotics community made years ago that are only now bearing fruit.

The foundation is ROS2, the Robot Operating System that’s become the de facto standard for robot control and communication. What matters isn’t just that it exists, but that it’s an open standard providing genuine interoperability. When a robot manufacturer designs with ROS2, their hardware works with thousands of existing software packages. When a software developer builds on ROS2, their code runs on hundreds of different robot platforms.

This standardisation solves the problem that held robotics back for decades. Every robot manufacturer built proprietary systems. Engineers couldn’t transfer skills between platforms. Software written for one robot was useless on another. ROS2 changed this by providing a common language for robots to communicate and be controlled.

But ROS2 was deliberately designed as foundational technology. The creators built a robust foundation and expected others to build accessible tools on top of it. That second layer is now emerging, accelerated by developments outside robotics entirely.

Cloud computing infrastructure means engineers no longer need to install complex local environments. Development tools can run in browsers, accessing robot systems remotely. This  previously blocked engineers from even starting. The technical barriers haven’t disappeared, but they’ve been abstracted away from the user, just as .NET abstracted memory management, and React Native abstracted platform-specific mobile APIs.

AI-assisted programming is the other accelerant, and it’s transforming accessibility faster than any previous shift I’ve witnessed. Large language models trained on robotics documentation can now generate working robot control code from plain English descriptions. An engineer can describe what they want the robot to do and receive syntactically correct code that follows ROS2 best practices. This removes the months of learning obscure syntax and configuration details that previously acted as gatekeepers.

The combination is crucial. ROS2 provides standardisation and interoperability. Cloud infrastructure removes installation barriers. AI assistance handles syntax and configuration complexity. Together, they create a path for domain experts to implement robotic solutions without becoming robotics specialists.

Robot manufacturers who previously spent weeks helping customers set up development environments are testing approaches that reduce this to hours. Software development firms that couldn’t bid on robotics projects are evaluating whether their existing developers can deliver these solutions. Universities are reconsidering whether they should spend months teaching infrastructure setup or move directly to application development.

The practical implications extend across industries. That facilities manager who understands his distribution centre’s inspection requirements better than any external specialist can now implement the solution himself. The agricultural engineer with deep knowledge of crop stress can deploy the monitoring system without hiring a robotics PhD. The manufacturing specialist who knows exactly how a collaborative robot should integrate can program the behaviour directly.

This matters economically. When robotic solutions required dedicated specialists, minimum project scales increased dramatically. Smaller engineering firms were priced out. Custom solutions for specific operational challenges weren’t viable. As programming becomes accessible to domain experts, these economics shift. Projects that couldn’t justify specialist overhead become viable.

More significantly, it changes who builds robotic solutions. Engineers with deep operational knowledge can now directly implement their expertise in working systems, rather than attempting to explain requirements to robotics specialists who lack that context. Solutions get built by people who understand the operational reality, using robots as tools rather than as specialist systems requiring dedicated expertise.

This doesn’t eliminate the need for robotics specialists. Cutting-edge research and complex system integration will always require deep specialist knowledge. But for the vast majority of practical engineering applications, the challenge isn’t conceptual complexity, but barriers created by the need for specialist training.

Having watched this pattern repeat across three decades of software development, I recognise the inflection point when I see it.  ROS2’s maturation as a stable standard creates the foundation. Tools being built on that foundation are removing accessibility barriers. The timing isn’t coincidental. The robotics community deliberately chose open standards over proprietary approaches, understanding that broad adoption required interoperability. That decision is now enabling a wave of accessible tooling that wasn’t possible in a fragmented, proprietary landscape.

For engineering firms, the question shifts from “do we have robotics specialists?” to “can our domain experts access robotic capabilities when projects need them?” The answer is increasingly yes, but it requires recognising that the tools available today are fundamentally different from those available even two years ago.

The engineers who’ve been locked out of implementing robotic solutions they fully understand are about to get access. The foundation has been built. The accessible layer is arriving. The firms that experiment now with modern robotics development approaches will be positioned ahead of those that wait.

I’ve seen this film before. I know how it ends. The only question is which organisations recognise the shift early enough to benefit from it.

Nick Thompson, CEO and co-founder of OLO Robotics