Software Engineer, Robot Autonomy; Reliability & Test Infrastructure

At Laelaps AI, we believe robotics is entering a transformative decade, much like the arrival of the internet. Advances in AI, cloud computing, and hardware are reshaping what autonomous systems can do. Our mission is to build the intelligent software that powers physical security in the real world - enabling robots and sensors to handle dangerous and critical tasks that humans shouldn't have to.

By engineering the orchestration layer for intelligent security, we aim to create a world that is safer, more secure, and more resilient.

We're a strong founding team based in Zurich, backed by visionary investors and advisors. We are engineering the future of security today!

You will own the path a code change takes from commit to robot, and the evidence behind every gate on that path. Today the honest answer to "is this build safe?" is "it worked on the test robot." You will replace that with a system: the simulation environment the team tests against, the regression suites that run on every change, the hardware-in-the-loop rigs, and the release gates that decide whether a build can go onto a robot that will patrol a customer site alone tonight.

This is the first engineer dedicated to reliability and test infrastructure, and it sits in our Robot Autonomy team, next to the engineers building perception, localisation, planning and locomotion. Our robots patrol security sites, critical infrastructure and defence facilities without a human present, so a bad release is not a rollback: it is a customer incident. Within six months, nothing should reach a customer robot without passing something you built.

• Release pipeline: code change, automated tests, simulation at scale, staging robot, pilot site, full rollout, with explicit pass criteria at every gate and nothing advancing without meeting them.

• Simulation as infrastructure: a GPU-backed simulation environment (Isaac Sim today) running continuously, so engineers test against scenarios instead of queueing for the one robot in the lab.

• Scenario libraries and regression suites: coverage across the whole on-robot stack, perception through locomotion, and the infrastructure to run thousands of scenarios on every change.

• Hardware-in-the-loop: bench rigs and test procedures on the physical robots for what simulation cannot tell you.

• Failure injection: drop sensors, degrade LiDAR returns, kill the network link, corrupt odometry, then verify the system degrades and recover the way we tell customers it does.

• Field incidents to tests: when a robot misbehaves on site, reproduce it deterministically and turn it into a permanent regression test.

• Reproducibility: log capture, replay tooling, deterministic seeds, versioned scenarios, and coverage metrics that are honest about what they do not cover.

• Acceptance criteria: turn product and customer requirements into measurable tests, and report against them without softening the numbers.

A test, validation or reliability engineer who has shipped a product where failure had consequences, and who has seen what changes when a fleet goes from one unit to fifty. You treat simulation and CI as production infrastructure that you own, not tools you consume. You have judgment about what is worth testing: we want a safety net, not a wall of green ticks that hides the real risk.

And you are comfortable being the person who says a build is not going out.

• 4+ years in test, validation, reliability, SRE or platform engineering on a product that shipped to customers.

• Experience with a complex system at scale: autonomous driving, drones, industrial automation, medical devices or similar.

• Strong Python and/or C++, with solid CI/CD and containerised infrastructure skills.

• Hands-on with a robotics simulator run as production infrastructure:
  Isaac Sim preferred, Gazebo, Mu Jo Co  or equivalent accepted.

• Comfortable owning cloud infrastructure and GPU orchestration, not just consuming it.

• Enough hardware literacy to read a timing problem or a flaky sensor trace, and the judgment to know when to hand it to Hardware.

• ROS 2.

• Hardware-in-the-loop rigs and bench automation.

• Fleet telemetry and observability (Grafana, Prometheus, Open Telemetry).

• Functional safety or comparable standards work.

• On-prem, air-gapped or defence deployment experience.

• Having been on call for hardware in the field.

• Ownership: you are able to ship products and deliver project end-to-end.

• Mission: autonomous security that…