Hazy Research argues coding agents will retire CUDA DSLs

Stuart Sul and Chris Ré have a provocative claim out of Hazy Research: they think CUDA DSLs are heading toward retirement. The concrete evidence they point to is their own workflow. Last year they built a C++ abstraction layer to make megakernels tractable. This year, they say, they deleted it and let agents work through the complexity directly.

The framing is that abstractions have historically done two jobs, and one of them is going away. Abstractions are a cognitive offloader, a way for a human to reason about a hard system without holding every detail in their head. The authors' claim is that this job is being taken over by agents, and that tasks like writing an optimized GEMM kernel are now "nearly automated given the right prompt." By inductive reasoning, they argue, CUDA DSLs are next on the list, including their own ThunderKittens library.

The tradeoff they land on is codebase versus prompt. A codebase is precise but tied to a language, a hardware target, and conventions only its authors really understand. A prompt is fuzzy, but it travels. As the fuzzy-to-working-code gap narrows, the value of the precise-but-brittle artifact shrinks, and what survives is intent, invariants, and the test suites that let you check the output.

The honest caveat is one the authors flag themselves. They describe their position as "a single, biased sample," working in a domain they know cold, with oracles and reference implementations already in place. What the post does not give you is a benchmark showing the agent-written kernels match the abstraction-backed ones on throughput, or an answer to how newcomers pick up kernel programming without the framework as scaffolding. They also say plainly they are going to keep updating ThunderKittens.

If they are directionally right, the interesting question for anyone maintaining a DSL, a compiler, or a wrapping framework is what they actually own once agents can generate the layers. Not the syntax and not the abstraction hierarchy, but the tests, the oracles, and the domain knowledge encoded in what a correct output should look like. Those are what stays behind when the implementation becomes, in the authors' phrase, disposable.