Alhussein Jamil — AI Systems Engineer

// layer_00 · signal

About

AI systems, robotics, and software that has to touch hardware

Alhussein Jamil

AI systems, close to the metal

Paris, France

At Arago I work on backend paths, runtime dispatch, and launch code for a photonic AI accelerator.

Before that: walking robots and exoskeletons at Wandercraft, then computer vision for robotic automation at EyePick. École Polytechnique and Sorbonne Université in the mix.

I like code that has to deal with reality: hardware quirks, physics, latency, humans, bad assumptions. And yes, I vibe code too; I knew how to code before that became a personality trait.

// hidden_layers · experience

Where I've been useful

Accelerators, robots, computer vision, and prototypes that made it past the notebook

Where the work stopped being hypothetical.

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.

General-purpose silicon, PyTorch-first software. APIs, runtime, and firmware paths follow how ML teams already work.

Problem: Photon matmul is one kernel. Shipping means the full path: PyTorch in, runtime and firmware dispatch in the middle, tensors back out without breaking normal workflows.
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

GitHub ↗

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

How I got here

Skills, education, teaching, languages, and interests

Programming

Python
C++
C
OCaml
Java
C#
SQL

AI Systems

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

Personal builds with real demos

Problem: Get a Cassie-style biped walking in simulation without teaching it weird shortcuts.
What I built: A Ray RLlib training pipeline on MuJoCo, with exportable policies for Cassie-style locomotion.
Tricky bit: Reward goes up; the gait can still look wrong. Most of the time went into making the walk believable.

/ 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: Build a playable prototype 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 build · ~200 hours · made 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: Python implementation of convolutional Wasserstein distances (Solomon et al., SIGGRAPH 2015).
Tricky bit: Using the structure of the domain instead of materializing a full cost matrix.

Barycenter demos