Alhussein Jamil — AI Systems Engineer

// layer_00 · signal

About

A little about my work and life outside it

Alhussein Jamil

AI, robotics, and systems

Paris, France

I’m a software engineer based in Paris. I like projects that seem simple on paper—until the constraints of the real world get involved.

Most recently, I ported large models to ZML’s Zig-based inference stack. Before that, I worked on a PyTorch stack for a photonic accelerator at Arago, robot locomotion at Wandercraft, and computer vision for robotic automation at EyePick. I studied at École Polytechnique and Sorbonne Université.

I enjoy software that has to survive contact with hardware, physics, latency, and people. Outside work, that usually means side projects, music, climbing, or a puzzle I should have left alone.

// hidden_layers · experience

Experience

My work has covered inference, AI accelerators, robotics, and computer vision

Work that had to run outside a notebook.

ZML · Paris

Ported large AI models to ZML’s inference stack, built in Zig.
Adapted model architectures and operators so they compiled and ran efficiently on accelerators.
Worked on model loading, compilation, and inference.

Arago · Paris

PyTorch/ATen backend paths for a photonic AI accelerator: custom kernels, graph execution, and framework integration.
Runtime dispatch for graph partitioning, fast allocation, peer transfers, launch serialization, and concurrent queues.
Host code tied to firmware flows where launches become primitive device graphs for mono cores and sync points.
Hardware-adjacent work: custom ISA emission, driver interfaces, device setup, simulation, and validation.

A PyTorch-first accelerator stack designed around workflows ML teams already use.

Problem: A photonic matrix multiply is only one kernel. The product needs an end-to-end path from PyTorch through runtime and firmware dispatch, then back to tensors users can handle normally.
What I built: Compiler lowering, host runtime, driver paths, fast allocation, device-to-device movement, launch queues, and firmware dispatch.
Tricky bit: Graph regions or single ops get placed on devices, split into primitive graphs, run on mono cores, and reported back to PyTorch through events. It still has to feel like a normal accelerator stack.

PyTorchRuntimeFirmwareAccelerators

Why there is no repository →

01

PyTorch computation graph

ATen ops form a real dependency graph
Tensor edges help decide what can run where
Acceleratable regions get pulled out for launch

02

Compiler + host runtime

01 Lower the graph

02 Place the work

03 Plan launches + transfers

03

Per-device execution

subgraph A

Device 0

node -> compute DAG

Execution sessions

queue 0 queue 1 queue 2

Device primitive graph

Control core

Laser compute unit

Sync + device events

PCIe / device interconnect

subgraph B

Device 1

node -> compute DAG

Execution sessions

queue 0 queue 1 queue 2

Device primitive graph

Control core

Laser compute unit

Sync + device events

Simplified map — public, generic terms only

EyePick · Paris

Built computer-vision pipelines for real-time robotic automation in industrial, agricultural, and culinary settings.
Worked on image-based anomaly detection and classification for quality control.
Adapted ResNet-based models when YOLO-style detection pipelines were blocked by licensing constraints.

Wandercraft · Paris

Trained RL control policies for the Cassie bipedal robot and the Eve exoskeleton.
Used NVIDIA Isaac Gym and Ray RLlib for parallel simulation and distributed policy training.
Worked on sim-to-real transfer with imitation learning, domain adaptation, and visual adaptation.

Poppins (formerly Mila) · Paris

Implemented adaptive difficulty for a therapeutic game designed for dyslexic children.
Used clustering and gameplay metrics to adjust difficulty without asking children for explicit feedback.
Worked on both the algorithm and the game-side integration.

// weights · toolkit

Skills and background

Tools I use, what I studied, and where I teach

Programming

Python
Zig
C++
C
OCaml
Java
C#
SQL

AI Systems

Inference pipelines
PyTorch execution
Graph lowering
Runtime work
Custom ISA
Kernels
Multi-core execution

Machine Learning

Computer vision
Reinforcement learning
Imitation learning
Sim-to-real
Model deployment

Robotics

NVIDIA Isaac Gym
Ray RLlib
Robotic control
Industrial automation
VR robot interfaces

Tools

Linux
Git
Docker
Debugging
HW/SW integration

Education

École Polytechnique

Engineering Degree — MSc equivalent · 2020 — 2024
Sorbonne University — UPMC

Master 2 — Intelligent Systems · 2023 — 2024
Lycées Buffon & Louis-le-Grand

CPGE — MPSI → MP* · 2018 — 2020

Teaching

X-HEC Master

Guest ML lecturer for engineering and business master's students.
Lycée Saint-Louis

Oral examiner in mathematics for CPGE students.

Languages

French bilingual · Arabic native · English bilingual · Spanish intermediate

Interests

MMA
Puzzles
Violin
Climbing

// forward_pass · selected_work

Projects

Selected projects with code, working demos, or both

Problem: RL projects often tie training code to one environment, so each new task becomes another wiring job.
What I built: An env-first framework on Ray RLlib: add a task folder, choose an algorithm in YAML, then train, resume, and render.
Tricky bit: Keeping tasks, configuration, and checkpoints portable while still supporting a full Cassie locomotion environment.

/ droprl · cassie · RL debug signals synced to video t = 0.0s

/ droprl · snake-v0 · AI agent iter 0 · reward 0.0 · score 0

★ star · policy π

Problem: Make a VR brush stroke line up with a real robotic touch setup closely enough for a psychophysics study.
What I built: Unity VR scene with Franka Emika arm control over Redis, hand-tracking calibration, and in-headset pleasantness/intensity ratings.
Tricky bit: Keeping rendering, robot/haptic hardware, and subjective ratings in sync without breaking the illusion.

Unity · VR · Franka Emika · Redis · Hand tracking

Touch simulation

Affective touch simulation

A brush stroke on a virtual hand, used as the main stimulus for the study.

Protocol & interface

Calibration

Hand-tracking calibration

The participant confirms hand poses, then follows a countdown before trials start.

In-VR ratings

Pleasantness & intensity UI

Ratings happen inside the headset, so the trial flow is not interrupted.

Problem: For a school research project, build a playable game to study how children with ADHD switch between exploration and exploitation.
What I built: A Unity hub world with four puzzle mini-games, pixel-art rooms, fog-of-war, grid logic, and physics puzzles.
Tricky bit: ~200 solo hours across game loop, level design, mechanics, lighting, and the user-testing build.

Hub & level select

A temple hub with statue landmarks and portals into each mini-game.

Solo school project · ~200 hours · built for ADHD user testing

4 mini-games

Color-coded crate puzzle

A Sokoban-style room: push crates onto matching colored altars.

Fragile bridge pathing

Numbered crates tell you how many tiles survive before the bridge gives way.

Ice sliding & hazards

Frictionless ice, spike traps, and very little room for sloppy moves.

Flashlight labyrinth

A circular maze where the fog-of-war only reveals tiles near the player.

Problem: Build Nine Men's Morris end to end, including an AI that can actually play.
What I built: A full Pygame implementation with rules, UI, and a Minimax search bot.
Tricky bit: Move generation changes across placing, moving, and flying phases, so the search has to follow the game state closely.

/ noine — nine men's morris ·

click a point · form a mill to capture

original Pygame build

Noine board mid-game with orange and white pieces — Mid-game

Noine board during a mill capture — Mill phase

Problem: Make optimal-transport distances practical on grids and meshes.
What I built: A tested Python package for convolutional Wasserstein barycenters on 2D and 3D grids and triangle meshes.
Tricky bit: Using convolution and heat solves instead of materializing a dense pairwise cost matrix.

Barycenter demos