Did not open the editor at all: AMD Vice President used only Claude AI to generate Python code and directly chat with the Linux GPU kernel driver

IT Home, March 8 — AMD Vice President Anush Elangovan released a small experimental Radeon driver last week, entirely written in Python. According to Elangovan himself, the code was generated entirely by Claude Code, and he never even opened a code editor during the process.

At first glance, most users might automatically think of a sensational headline: “AMD senior executive writes a brand-new GPU driver using AI?”

While that’s certainly impressive, the reality isn’t as radical — the driver he developed isn’t what most people typically think of as a driver. Essentially, it’s a lightweight testing tool designed to interact directly with AMD’s Linux GPU interface.

According to Phoronix, modern Radeon GPUs on Linux usually run on a software stack built around ROCm. Applications communicate with the ROCm libraries, which in turn interact with the runtime in user space, ultimately passing commands to the kernel GPU driver.

Elangovan’s experimental project bypasses much of this stack. The Python code communicates directly with kernel drivers via device nodes like /dev/kfd and /dev/dri/render*, allowing it to allocate GPU memory, create compute queues, submit command packets, and synchronize CPU and GPU work. In other words, it can access the lowest level of AMD’s compute interface.

However, this might sound more exaggerated than it actually is, because AMD’s kernel driver (which was not replaced by AI code here) still handles almost all the heavy lifting. The Python layer simply constructs command packets and sends them through existing kernel APIs.

It’s somewhat like using a laptop temporarily as an MCU controller for a car engine — not meant for long-term driving, but a very practical diagnostic tool. The key point is that this new code can interact with GPU hardware in a very controlled way, without relying on the entire ROCm software stack.

Elangovan believes this makes the project very useful for debugging and experimentation. Engineers can isolate bugs within ROCm or test specific GPU features without compiling large C++ projects. The prototype reportedly can handle some real tasks, including creating command queues, allocating memory, scheduling compute packets, and synchronizing CPU-GPU timelines.

Another indication of the project’s purpose is that Elangovan’s release notes mention a “pluggable architecture designed for future bare-metal PCI(AM) backend.”

This sounds very forward-looking — the AM backend would bypass the kernel driver and communicate directly with the GPU via PCI. Such a setup is typically used for hardware initialization, diagnostics, or very low-level testing environments, not consumer-facing software. Bypassing the kernel driver would break features that depend on it, such as multitasking, virtual GPU memory, and DRM.

At this point, some may still hope that it could evolve into a fully functional Radeon driver for daily use, but that’s highly unlikely. Production GPU drivers are massive projects, involving shader compilers, memory managers, power management, security layers, and support for complex APIs like Vulkan and OpenGL — none of which are present in this experimental project.

What Elangovan demonstrated is that AMD’s Linux kernel interface is sufficiently open and modular that people can write scripts in high-level languages to interact with it. It also shows that he genuinely enjoys coding with Claude Code.