LLM code reasoning: lifecycle across Qwen, Llama and DeepSeek

From Brewing to Resolution: Tracing the Internal Lifecycle of Code Reasoning in LLMs, submitted 16 Jun 2026 by Siyue Chen and 11 coauthors, maps how decoder-only Transformer models carry code answers internally before producing them. The paper applies a dual diagnostic framework to six code-reasoning task families across 16 models spanning Qwen, Llama, and DeepSeek architectures.

What is the brewing-to-resolution lifecycle?

The lifecycle is a two-phase pattern: models first "brew" an answer, making it linearly recoverable many layers before it becomes self-decodable, and then the computation diverges into one of four resolution outcomes. The four outcomes the authors identify are Resolved, Overprocessed, Misresolved, and Unresolved, and the paper stresses that similar task accuracies can mask fundamentally different failure modes.

The brewing stage acts like a scaffold inside the network, a period where the target solution can be extracted by probing even if the model has not yet produced it in its output tokens. That scaffold persists for a substantial, consistent fraction of the model depth across architectures the authors tested.

How did the authors measure the lifecycle and what did they find?

They introduce a dual diagnostic framework pairing layer-wise linear probing with Context-Stripped Decoding (CSD) and run controlled sweeps across structure, depth, and operators. This framework was applied to six code-reasoning task families on 16 models drawn from Qwen, Llama, and DeepSeek families.

Using those diagnostics the authors report that the overall fraction of tasks that end in the Resolved outcome is 41.5%, with several task families scoring below 30% Resolved. The brewing scaffold remained stable across all 16 models, with a normalized brewing duration ranging from 24% to 42% of model depth. By contrast, resolution success varies: for Function Call tasks, Resolved drops from 61.1% at call depth one to 2.5% at call depth three, revealing a sharp task-specific bottleneck.

Those controlled sweeps exposed other task-specific failure points tied to structure, depth, and operator sets. The paper emphasizes that while the brewing scaffold is an empirical regularity across the tested decoder-only Transformer families, whether that scaffold leads to a correct final output depends on capability, scale, and training.

Why it matters

A single accuracy number can hide how and where a model fails. Two models with the same task accuracy may reach that score by very different internal routes: one might reliably brew and resolve correct answers, while the other brews then misresolves or overprocesses them. That distinction matters for diagnosing model weaknesses, designing targeted interventions, and for safety-critical or correctness-sensitive code reasoning where internal failure modes predict real-world errors.

The paper’s finding that brewing duration is a stable scaffold but resolution success covaries with capability and training suggests diagnostics should separate internal representation quality from the model’s final decoding behavior. That separation gives researchers a finer lever: improve resolution mechanisms or training to convert brewing signals into correct outputs instead of treating low accuracy as a single uniform failure.

What to watch

Look for follow-ups that test whether the same brewing scaffold appears beyond the tested decoder-only Transformer families and for interventions that specifically raise the Resolved fraction without changing brewing duration. Also watch for replication of the extreme drop in Function Call Resolved rates as call depth increases, which the paper records falling from 61.1% to 2.5%.

The authors provide code alongside the paper to reproduce their diagnostics and sweeps, enabling other teams to probe whether these lifecycle patterns hold across more architectures, scales, and training regimes.