AMD VP Used Claude Code to Build a Pure-Python GPU Driver

Editorial illustration for: AMD VP Used Claude Code to Build a Pure-Python GPU Driver

What Happened

Anush Elangovan, AMD's VP of AI Software, used Claude Code to build a pure-Python user-space driver for AMD GPUs. The driver communicates directly with AMD hardware, bypassing the standard ROCm/HIP software stack. It's currently used for stress testing, debugging SDMA operations, and verifying compute/communications overlap.

The project is not a toy. It includes KFD ioctl bindings for queue, memory, and event management, SDMA copy engine support, PM4 compute packet builders, timeline semaphore synchronization between GPU and CPU, an ELF code object parser for kernel loading, and multi-GPU support. It runs across RDNA2, RDNA3, RDNA4, CDNA2, and CDNA3 GPU families, and has been tested on MI300X (gfx942). As of the announcement on March 4, 2026, 130 tests are passing.

Elangovan was inspired by Tinygrad's user-space AMD GPU driver implementation. The code lives in a branch of AMD's TheRock repository on GitHub. He stated that "agents are the great equalizer in software" and emphasized development speed as a competitive advantage.

Why It Matters

A VP at a major semiconductor company just built a working GPU driver - one of the most complex pieces of systems software that exists - using an AI coding assistant. GPU drivers are traditionally written in C/C++ by specialized teams over months or years. This one was written in Python, by one person, with AI help.

This isn't about replacing production GPU drivers. The Python driver is a debugging and testing tool. But the fact that it works across five GPU architecture families and passes 130 tests shows that AI coding tools have moved well past "help me write a React component" territory. They're now useful for low-level systems programming that requires deep hardware knowledge.

For developers evaluating AI coding tools, this is a strong signal. If Claude Code can help produce a functional GPU driver, it can handle most of the specialized coding tasks you're likely to throw at it.

Our Take

The most interesting part of this story isn't the driver itself. It's who built it and why. This is AMD's VP of AI Software - someone who could assign a team of kernel engineers to the task. Instead, he used an AI coding tool because it was faster.

That's a meaningful endorsement. When senior engineers at hardware companies reach for AI coding assistants for complex systems work, it tells you something about where these tools actually are in terms of capability. It's not just about productivity gains on routine code. It's about making previously impractical projects feasible for individual engineers.

The Python choice is smart for a debugging tool. You trade some performance for dramatically faster iteration. When you're trying to reproduce a GPU synchronization bug, you want to modify and rerun code quickly, not wait for C++ compilation cycles. Claude Code apparently made that iteration loop even tighter.

Elangovan's comment about agents being "the great equalizer" is worth taking seriously. A single engineer with the right AI tools can now build software that previously required a team. That changes the economics of software projects across every industry, not just GPU drivers.