Your coding agent isn’t stuck because it’s dumb. It’s stuck because it’s alone.

Give a strong coding agent a hard GPU kernel, a $1,000 budget and several days. How close does it get to the kernel experts wrote?

On one of DeepSeek-V3’s attention kernels, Codex running GPT-5.5 at its highest reasoning setting reached 28% of expert performance. That is the opening result of Evolving Agent Teams, a paper from UC Berkeley’s Sky Computing Lab published on 27 October 2026.

The authors keep the model and the budget the same and add a supervisor agent. It watches a team of agents work, diagnoses why progress stopped, and redesigns the team.

The kernel in question is MLA paged decode. A DeepSeek-V3 server runs it for every token it writes.

A model writes its answer one token at a time, and each new token looks back at every token before it. To avoid recomputing, the model keeps a key and a value for each earlier token in a KV cache, which production servers store in fixed-size pages. DeepSeek’s Multi-head Latent Attention, MLA, squeezes each token’s key and value into one small vector to keep that cache small.

Decode is the work of writing the next token, and the kernel is the GPU program that does it. Two matrix multiplies sit at its centre: Q·K scores the cached tokens against the new one, and P·V mixes their values by those scores.

The expert kernel comes from FlashInfer, the open-source library production servers run. Matching it means keeping tensor cores and CUDA cores busy together, with registers that MLA’s wide heads nearly fill.

A fast one needs WGMMA, the tensor-core instructions on Nvidia’s Hopper GPUs for large matrix multiplies. With a wrong shared-memory layout, WGMMA returns wrong values without an error, and the agent has to find which layout is wrong.

Agents working alone tried WGMMA, failed the correctness tests a few times, and switched to WMMA. WMMA is an older, simpler tensor-core API. It is easier to make correct, and it uses less of the hardware. Then they spent the rest of the budget tuning it. Each tweak added a little speed. None of them replaced WMMA, which uses less of the tensor cores and so caps the kernel’s speed.

Claude Code with Opus 4.6 did the same and stopped at 0.44–0.51× of the production FlashInfer kernel. Two systems built only for kernel work, K-Search and CUDAForge, did it too. In two runs each, neither produced a WGMMA kernel.

A coding agent improves a kernel by local search. It makes an edit, compiles, runs the tests and times the result, and it builds on the edit if the kernel is correct and faster. Each move is judged by the score it gets right away.

WMMA designs sit on a low hill. Small edits there compile, pass and add a little speed, so the search climbs. WGMMA designs sit on a higher hill, across a valley where nothing passes. Moving to WGMMA means getting the shared-memory layout, the descriptors and the register layouts right together, and any one of them wrong scores zero. Any single edit from a WMMA design toward WGMMA scores zero, so local search rejects it.

The model’s weights were set in training, which included reinforcement learning on coding tasks where passing tests is a common reward. None of that training scored this kernel’s speed, and the weights do not change during the run. A failed WGMMA attempt adds an error message to the context window and no gradient to the weights, so the tenth attempt runs on the same weights as the first.

Within a run, the model’s only memory is its context window. Every token it writes attends over the tokens before it through a softmax, so the attention weights on all earlier tokens sum to one. The longer the context, the thinner each old token’s share, and position encodings such as RoPE tilt the share further toward recent tokens. Long-context models are measurably worse at using what sits in the middle of a long context.

A new session is the extreme case. Its context starts with the task and whatever files it is told to read. A finding that is not in those files is not in the context, so it gets no attention.

The supervisor cannot change the weights. It changes three inputs instead: the design each team starts from, the edits each role may commit, and the files each new session reads first.

The paper describes any agent team as three choices:

• Roles: what each agent is responsible for.

• Coordination: how agents hand work to each other. A pipeline (research, then implement, then profile), parallel branches, or both.

• Knowledge management: where findings are written, and who must read them.

Most multi-agent setups fix all three before the run starts. Here a supervisor agent changes them during the run. It runs when a team finishes and at fixed intervals, and each time it follows the four steps below.

There are no predefined roles. The supervisor invents them from what it diagnoses. On the decode kernel it tried more than 100 team configurations. Some of the roles it created:

Table 3 of the paper lists 22 roles in all, from a Roofline Analyst to a Compiler Specialist.

Under every team sits the shared file system in the figure above. Each new team starts from everything earlier teams found.

After the supervisor added the Disciplinarian, the kernel’s speed against FlashInfer fell from 0.15× to 0.065×. The 0.065× kernel was the first correct WGMMA kernel, and every later version was built on it.

The supervisor numbers its teams V1, V2, V3 and so on. From V3, every team ran into the same wall: getting the P·V multiply onto WGMMA. V3, V4 and V5 each tried and failed on the same root cause.

Team V4 also wrote down a fix. Its report recommended a register-source WGMMA, which keeps the scores (P) in registers. Teams V5, V6 and V7 ignored the recommendation. It sat in V4’s report. It never reached the shared learnings document, the file later teams read.

The supervisor’s diagnosis: “Lost knowledge between teams is the biggest structural weakness.” The learnings document kept single facts. It did not keep strategic advice that spanned experiments.

So the supervisor changed the knowledge rules. It added a Knowledge Integrator and a new file, SYNTHESIS.md, that joins every agent’s findings into one plan. Every later team had to read it.

The model was the same from V7 to V8. What changed was one file, SYNTHESIS.md, and the rule that every team reads it.

The main comparison is the MLA decode kernel on an Nvidia H100, scored on 47 production DeepSeek-V3 workloads from FlashInfer-Bench. Every system had the same token budget. 1.0× would match production FlashInfer.

The fixed four-role team is the useful control. Its four roles were Profiler, Hardware Researcher, Planner and Implementer, and they never changed. It ran a newer model than the evolving team. It finished below Claude Code alone.

With more budget, the evolving team’s kernel reached 1.21× the speed of production FlashInfer on average. It was faster on 36 of the 47 workloads and at 0.86–0.99× on the other 11. The best earlier published result was 0.61×, from K-Search.

The authors also ran four further settings with newer models (Opus and Sonnet 5.5):

• KDA prefill, the kernel that reads the prompt for Kimi Delta Attention: 3.01× faster than vLLM’s production kernels on an AMD MI350X, and 3.44× faster than FlashKDA on an Nvidia B200.
• Serving a large model on a Mac: Qwen3.8-Flash-Next, about 79 GB of 4-bit weights, served on a 48 GB M4 Pro by streaming experts from SSD, at 30.3 tokens a second.
• RoboDojo, 42 simulated two-arm robot tasks: a control program scoring 62.1 on held-out seeds, against 55.3 for the best leaderboard entry.

In the paper, team design moved the result as much as the model did. The fixed team ran a newer model and scored 0.31×, less than half the evolving team’s 0.74×.

• When an agent stalls, ask why before adding tokens. Each of the supervisor’s changes answered a named failure. Drift got a Disciplinarian. A debugging problem that blocked all tuning got its own branch, so one agent debugged while another tuned. A lost insight got a synthesis file. A new design got a fresh profile, because the old bottleneck analysis no longer applied.

• Write findings where the next session reads. A new session reads the task and the files it is told to read. With Claude Code or Codex, keep one file in the repo that every new session is told to read first, and update it when a finding changes the plan.

• Make the hard constraint someone’s job. Agents told to use WGMMA switched to WMMA after a few failed tests. In the paper, a second agent that rejected every commit leaving WGMMA kept the team on it.

• Splitting work across agents can hide a bug. The paper traces the fixed team’s slow start to one bug. The researcher knew the layout rule, the implementer wrote the layout, and neither read the other’s file. A single agent would have had the rule and the code in one context.

We wanted to see the effect with a model small enough to run on a laptop. We gave Qwen3.5-4B a toy tuning task with the same shape as the kernel: six settings, an easy design that tops out at 0.50×, and a fast design worth up to 1.06× that only works once three settings change together. Change one alone and it fails with a compile error or wrong output.

Each run got 40 model calls, and we ran each setup 20 times. The evolving team’s supervisor redesigned it three times per run, and its calls came out of the same 40.

The solo agent plateaued the way the paper describes. In 12 of its 20 runs it tried the fast design, watched it fail, and settled between 0.42× and 0.49× on the easy one. Both teams got past that wall about twice as often.

The supervisor did not beat the fixed team. A 4B model writes fluent diagnoses that are often wrong: in 12 of 20 runs it banned the fast design at least once. What it did do was cut tokens by 30%, because each role reads only its own history. With Qwen3.5-0.8B, no setup beat the solo agent at all.

Our harness, prompts and scorer are in a gist, and every run is replayed call by call in the demo below.

This is a synthetic task with a scorer we wrote, run on one Mac. It illustrates the idea; it does not reproduce the paper, whose supervisor read real compiler and profiler output. We had no part in the paper. For the real thing, read it and run the authors’ code.