Cody Ho and Niklas Sheth built a GPU driver for Apple’s M4 chip that passes the full OpenGL ES 3.0 conformance test suite — Chrome and Firefox render WebGL on it, Minecraft runs at 212fps on an M4 Mac Mini. Ho says this job normally takes years; they did it in about a month with coding agents doing essentially all of the implementation. His writeup, part two of a series called “I Came, I Prompted, I Left,” calls it “likely the first ever fully LLM-written GPU driver.”

Most of the work was reverse engineering, not writing code:

  • Apple’s GPU is driven through a firmware interface nobody documents. The team traced what macOS does with a hypervisor, replayed those traces, then rebuilt the same effects in their own code until nothing was being replayed.
  • Codex took the word “replay” literally — it copied the entire GPU memory state, restored it after a reboot, fired the hardware event, and checked that the output pages changed. Over many experiments it shrank the copied state until everything was built from source.
  • The kernel half of a driver talks to firmware and schedules work; the user-space half understands the hardware and fills in the buffers. LLM-written, the kernel driver went from a Python prototype to a full Linux driver in three days.
  • The agents also found hardware features Apple’s own driver never exposes, including a single-instruction 64-bit add and anisotropic filtering to 128x, where Metal caps at 16x.

The parts worth keeping are about directing the agents, not about the GPUs:

  • Task framing beat raw model capability. The compute work stalled for over a week because Ho had not “scaffolded out the task properly.” The fix was to shrink and clean the problem — boot into single-user mode so nothing else renders, start a tiny Metal program the moment the graphics framework is available, capture the smallest possible trace. Days of failure became days of progress.
  • Order matters. Codex chose the hardest subtask first (partial renders, effectively save-and-resume for a driver) rather than the easiest one, and “one of those days was almost totally wasted.” Told to do compute first, everything went smoothly.
  • His description of Codex’s character is specific: “pedantic” — “extremely thorough all the time, which can be a major benefit in some scenarios, but other times it gets stuck in the weeds on some random tangent to the detriment of the overall goal.”
  • His collaborator’s approach worked better for that reason. Niklas built real Mesa graphics code first and reverse engineered only what blocked him; Ho tried to fully understand the hardware before implementing. Niklas moved significantly faster, because his agent was “grounded by the need to actually build Mesa” instead of spending time on inconsequential completeness.
  • Grounding usually is the hard part of using LLMs — giving them good tests. Here it came free: the Khronos conformance suite is an exhaustive corpus the driver must pass, so “the hardest and most sensitive part of working with LLMs… is already done for us.”
  • One limit is not about effort. Claude could disassemble and reassemble Apple’s shader programs, but understanding instructions well enough to compile arbitrary new ones went nowhere: it “did a horrible job and made basically zero progress.”
  • Safety guardrails broke the unattended loop. OpenAI’s cybersecurity restrictions kept pausing the agent, and a plain “keep going” was usually enough to resume. So Ho wrote a daemon that screenshots every minute and retypes a resume command whenever the screen stops changing — then accidentally left it running in group chats.

The bottleneck Ho names is human, not technical. Upstreaming to Mesa and the Linux kernel requires refactoring the work into reviewable pieces, more testing, and human review — and he expects the code to be held to a higher standard precisely because it was written by a model. He calls those obstacles “primarily human and nontechnical, which LLMs cannot help with.”

The 105-comment thread on Hacker News

What the thread adds

  • MoltenMonster — brings outside context the article never mentions: a linked r/AsahiLinux comment alleging the author was banned from the Asahi Linux project for concealing extensive LLM use in a different contribution. The author (ADevWithAnIdea) replies in the thread that he is a former Apple engineer, did not conceal it, and “had no exposure, at all, to any internal information or code about macOS, SPTM, or Apple Silicon during my time there.”
  • thrwy19940314 — the harsher version of the same objection: the work is “tainted since the poster is ex-Apple,” nobody can verify what other models were trained on, and Apple is currently suing OpenAI over trade secrets.
  • porphyra — the practical consequence: Asahi Linux has a strict no-AI policy, so “this great work can’t be upstreamed” there, and they expect AI-assisted forks to win on newer hardware because most people just want it working. In reply, the author points out that Asahi does not hold a monopoly on Linux for Apple Silicon and that “upstream Linux absolutely does NOT ban LLMs.”
  • kmeisthax — argues against LLMs for reverse engineering on principle, “when there’s even a chance the models have been trained on the thing I ultimately plan to reimplement,” and says it was rude to reveal LLM use only after showing a page of LLM-derived firmware interface docs. viraptor supplies the counter: “The title is literally ‘I Came, I Prompted, I Left.’” outworlder asks how a model could be trained on proprietary Apple code in the first place.
  • y1n0 — the strongest dissent from the celebration: current models produce “disposable software,” and “if you just say ‘here’s a regression suite. Write an implementation that passes’ you will get something that works for a while but ages quickly and will need to be thrown away.”
  • SXX — “it doesnt matter whatever you can upstream it or not,” publish the method so non-Apple engineers can reuse it on later chips. The author obliges with a four-step kernel recipe that ends “LLM handles the rest.”
  • varispeed — asserts the model Ho praises has since been nerfed (“It is now the dumbest model right after Gemini”); Ho disagrees outright: “Can’t disagree more, but my experiences are my own.”
  • Agingcoder — not an argument, but a fair summary of the reaction: “the fact this works at all is insane, as in black magic insane. I assume I’ll get used to it, but my mental model of what’s possible hasn’t been fully rewired yet.”

The question the thread keeps asking

Whether any of this can land upstream. ndiddy calls it “one of the best use cases for LLMs” and immediately asks whether it can be accepted into the kernel; zamadatix notes Asahi’s long-term plan is upstreaming anyway, and hopes the community continues that “rather than have forks on forks”; kmeisthax’s clean-room objection and thrwy19940314’s taint objection are the specifics nobody resolves. The article flags the same wall from the author’s side — human review, refactoring and “significant skepticism” — but leaves open what a project should actually do when a working driver arrives from a model that may have read anything.

Pseudonymous handles, no per-comment scores published by HN, and the ordering above is HN’s own ranking — so this is a slice of the thread, not a consensus.