Coding agents reportedly wrote most of an OpenGL ES 3.0 Linux GPU driver for the M4 Mac mini in a month

Two developers say they have shipped an OpenGL ES 3.0 conformant Linux GPU driver for Apple's M4 Mac mini after roughly a month of work, with the bulk of the code produced by LLM coding agents. According to a dev.to write-up, Cody Ho and Niklas Sheth published the driver in September 2026; it targets the M4 Mac mini and the MacBook Neo, and Ho describes it as likely the first GPU driver written entirely by LLMs.

Built from scratch, not ported

Despite how it might look, this is not the well-known Asahi Linux driver patched for newer silicon. According to the write-up, the pair reverse engineered the AGX firmware ABI and the M4 user space themselves, working from live hardware traces and deliberately avoiding Apple's binaries. The resulting code is new, including a custom shader compiler and a command stream builder. Asahi's kernel UAPI was reused unchanged, and the developers credit the earlier M1/M2 driver for having settled many of the design questions.

The newer generation is also genuinely more complex: they report that the new firmware ABI contains roughly one and a half times as many structs, and twice as many pointers, as its M1/M2 counterpart. The claimed outcome is full OpenGL ES 3.0 conformance, with the remaining failures confined to optional extensions, plus OpenGL 3.3 support in the shipped build.

How the agents worked

Ho reportedly used Codex for the kernel and firmware reverse engineering and Claude for user-space work, with most of the effort running as long, largely unattended agent loops. On the kernel side, the agent used a hypervisor Ho had written for an earlier project to capture the GPU's full memory state, replay it after a reboot, and progressively rebuild the firmware structures in code until nothing needed replaying any more. On the user-space side, Sheth's agent iterated Mesa against the Khronos conformance suite until the OpenGL ES 3.0 tests passed.

That test suite is central to the story. The developers argue that the hardest and most sensitive part of working with LLMs is supplying good tests to keep them grounded, and that the Khronos conformance suite had already solved that problem for them.

Where human judgement still mattered

The write-up is candid about the limits. One compute capture came back at 336 MB and proved impossible to replay; the agent spent over a week on it without success. The breakthrough was a human decision about method: boot into single-user mode so no render work runs, trigger a minimal Metal compute program, and capture that instead. A further day was lost because the agent chose the hardest subtask first. Neither developer claims the agents worked without supervision.

The tooling behind clean-room reverse engineering

The instrumentation is notable. Ho's hypervisor, originally built to run and observe macOS on the hardware, produced the firmware ABI traces, and the agents drove it directly, capturing full address spaces and diffing them against known-good samples whenever their own code misbehaved. The reference workloads were small Metal shaders the team wrote itself, compiled and run so the developers could watch what changed in memory. Apple's required firmware blobs were treated as opaque, with a third party documenting them so the implementation could remain clean-room. All of the reverse engineering experiments were published so that the provenance of the work can be checked independently.

The Asahi split and upstream plans

The driver ships in Gravity Linux, a Fedora remix that was forked from Asahi Linux specifically over AI policy. Asahi's contribution rules forbid generative AI; Gravity permits it under disclosure and provenance requirements.

On upstreaming, the developers say the Mesa side uses the unmodified Asahi UAPI, so there are no policy obstacles there, although it still needs more testing and human review. They also expect their code to be held to a higher standard than human-written code. The kernel driver is further out, because they intend to wait for the M1/M2 driver to go upstream first.

Why it matters

For anyone running Linux on Apple Silicon, GPU acceleration is the difference between a usable desktop and a machine that renders everything in software, and the M4 generation is newer territory than the M1/M2 hardware where Asahi has made its progress. Beyond Apple Silicon, the project is a controlled case study in what coding agents do when pointed at a hard reverse engineering problem that already has an exhaustive test suite attached; that suite appears to be what kept agent-written code honest. It also shows that AI contribution policy has become a real fault line in open source, significant enough for a distribution to be forked over it.