Auto-research with Codex: a 232x faster QR kernel and the loop behind it

Sankalp's write-up shows that a coding agent can do most of the work of speeding up a GPU kernel when the task scores itself, and that the human still matters at the end. The contest, run by GPU Mode with Core Automation, asked entrants to factor batches of square matrices into the compact QR form PyTorch's `torch.geqrf` returns. QR factorization splits a matrix into an orthogonal part, which preserves lengths and angles, and a triangular part. A checker rebuilt both parts from each submission and confirmed they multiplied back to the original matrix, then ranked correct entries by run time across a range of matrix sizes. GPU Mode's command-line tool let an agent test, time and submit on its own, which is what made an unattended loop possible.

The setup borrows from Andrej Karpathy's autoresearch idea, in which an agent follows a written program: change the code, run a fixed experiment, keep the change if the score improves and revert it if not, and never stop to ask. Sankalp's version was a problem statement, an AGENTS.md file of standing rules for OpenAI's Codex agent, and a log of every submission and its timings so later sessions could see what had already been tried. Codex's `/goal` mode then looped toward targets such as beating the current best time for the 512 by 512 case; one goal ran for over a day. The author reports more than 1,500 submissions over 14 days. By the author's measure, the final result ran in about 1,805 microseconds against roughly 419,000 for the `torch.geqrf` baseline, the 232x figure in the post's title. The announcement post said 212x. The author reports placing 12th of 183 entrants; the contest page could not be read to confirm it.

Progress slowed sharply below about 3,000 microseconds, when the agent got stuck tuning small variants of the same idea. The author's fixes were changes to the loop. Instead of testing each new idea against a single best submission, which tends to reject structural changes that only pay off after a few rounds, the agent kept a beam of three to five candidate lines alive. The author also told it to take more risks, sent it to consult a second model through headless `claude -p` calls for fresh ideas, used subagents and profilers, and stepped in personally every few hours. They note that Claude tended to declare the work exhausted where Codex kept going.

The author's own conclusion is that domain expertise speeds up both building the loop and steering it. Looking at the top ten entries afterward, they saw tricks their agent never pursued, such as detecting the input's structure (low-rank matrices, for example) and exploiting it, and replacing more library calls with custom code. The result is one person's account of one contest task, so the speedup says how far an agent loop can push this kernel with that checker, not how such loops perform on work without an automatic way to score each attempt.