Genesis-World: Core Simulation Engine Engineer

What we’re building

Robots will learn in simulation before they hit the factory. Genesis-World is our bet on that future.

Genesis-World is an open‑source, general‑purpose simulation platform for physical AI from Genesis AI. One unified multi-physics engine: rigid bodies, FEM, MPM, particles, cloth, fluids. A robot arm can pour water onto sand, grasp a deformable object, or cut a soft body, all in the same simulation. Nyx, our in‑house renderer, may be the most promising renderer for robotics out there: real‑time photo‑realistic rendering, advanced features like depth of field, and state‑of‑the‑art techniques never seen before. Sensors of every kind: cameras, lidar, IMU, contact forces, temperature, plus arguably the most advanced tactile simulation available (paper). And the engine keeps growing: we are developing internally the most comprehensive and fastest Incremental Potential Contact (paper) solver for deformable body dynamics we know of, soon to be open‑sourced. It powers real business applications, from full‑fledged box packaging with labelling machine and all, to wire harnessing and lab automation, without any physics hack or compromise.

Everything is Python‑first and runs anywhere. Kernels are written once, and Quadrants, our in‑house JIT compiler, lowers them to CUDA, AMD ROCm, Apple Metal, Vulkan, x86, and ARM64. A single laptop or a datacenter. Massively batched GPU simulation for learning at scale, and complex non‑batched scenes where CPU wins outright.

This is at the core of Genesis AI’s strategy. Evaluation is the bottleneck of scalable robotics: real hardware caps iteration at wall‑clock time, but simulation turns it into a compute problem. Ours already runs two orders of magnitude faster than hardware (tens of thousands of episodes in half an hour instead of 200+ hours), while correlating with on‑hardware rollouts at 89%. The north star: physical AI that improves at the speed of compute.

The role

Simulation is still a hard sell in robotics. Outside a few success stories, like reinforcement learning for locomotion, most teams skip it, and friction is a big part of why: painful to use, painful to debug. We live that pain ourselves: debugging a failing experiment during policy evaluation takes 30 minutes, and there is no way to automatically generate a standalone reproduction script. That blocks adoption, even internally.

Your job is to kill that friction. You build the software engineering backbone of Genesis‑World: everything that makes a large, fast‑moving simulation codebase reliable, maintainable, frictionless. And it all ships in the open. Every hour of pain you remove, you remove for every roboticist who comes after you.

You join as core maintainer of Genesis‑World, with shared stewardship of the whole platform from day one. Our physics team develops the algorithms, but just as importantly, you work to make everything around them excellent: infrastructure, tooling, APIs, architecture.

The problems waiting for you

• Make testing of a JIT‑compiled engine scalable. Running our full suite is already taking hours because the ratio between compile time and runtime can be as bad as x10. Getting rid of this bottleneck is a serious challenge that will require a joint effort from the Genesis‑World and the compiler teams.

• Make any bug reproducible. Dump and reload simulations bit‑exactly, across machines, across backends, even when a single timestep of a batched simulation can already max out VRAM. Turn any failing run into a standalone reproduction script, automatically.

• Make autodiff first‑class. Genesis‑World is differentiable today, but partially: memory‑hungry, slower than it could be, and hard to maintain due to manual operation recording. The project spans the engine and the compiler: you drive the requirements on Quadrants and iterate in a tight loop with the compiler team until the integration is solid.

• Edit scenes at frozen time. See the scene, move entities and robots around, iterate on layout, all without building the scene or compiling the engine. Authoring today means a full build cycle. Make it instant.

• Make the simulator extensible. First‑class plugins for physics solvers and interactive viewer backends, including Nyx. Sensors already work this way. Generalize it, and Genesis‑World becomes a platform others build on.

• Give robots real actuation. Motors and MIMO transmissions, cleanly abstracted at the interface between users and the physics engine.

• Make time a local variable. Today the clock and the timestep are global to the engine, which forbids whole classes of speedups: environments cannot step independently, the timestep cannot adapt to the state, and individual solvers cannot advance at their own rate. Free the clock down to the sub‑scene level and let the simulation fly.

• Make scenes come alive. Events triggered by physics: press the button and the microwave door pops open, squeeze the trigger and the drill spins.

• Keep the core sharp. Refactoring legacy subsystems, stronger typing, consistent coding style, less Python overhead on hot paths, full scene serialization, telemetry and replay.

Beyond the code: you review issues and pull requests with the core team, answer questions from users and contributors, and can join the push on adoption.

Who you are

You care about the engineer using what you build as much as the thing itself. A slow test, a cryptic error, a manual step: you see it, you go after the root cause, and you remove it for everyone. You have opinions about API design.

You are comfortable with physics and robotics: the right design choices take a working picture of what a simulator like Genesis‑World does, how it works, and how it is used, a picture you can partly build on the job.

• Strong Python engineering on large codebases: architecture, refactoring, typing, packaging, performance profiling (py‑spy, Nsight, Xcode Instruments, RenderDoc).

• Developer tooling, test infrastructure, or CI at scale.

• Enough fluency with JIT compilation, code generation, or GPU computing stacks to reason about compilation caching, kernel dispatch, and startup cost. You will work closely with Quadrants.

• At ease debugging across the full platform matrix: Windows, Linux, and macOS, on x86 and arm64, over CUDA, AMD, and Apple Metal (and possibly Intel XPU via Vulkan soon)

• Open‑source reflexes: triaging issues, reviewing external pull requests, communicating with a community.

Bonus points: experience with other robotics simulators (Drake, MuJoCo, Newton, Isaac, RaiSim, Jiminy, Brax). PyTorch, our user‑facing interface. Other JIT compilers such as Triton, JAX, or Numba. 3D tooling and interactive editors (Maya, Blender, Houdini). Serialization formats (USD, glTF, MJCF/URDF). C++, CUDA, or Metal. Developer relations or community work.