Code-as-Thought (CaT) Reasoning

• Code-as-Thought (CaT) is a reasoning paradigm where the intermediate thought process is encoded in code, allowing explicit management of variables, control flow, and state tracking.
• This approach integrates code execution and simulation to verify logic steps, reducing errors like numerical hallucination and enhancing precision in algorithmic tasks.
• Empirical results show CaT’s significant gains in performance, demonstrating its flexibility and effectiveness as a conditional reasoning strategy across various task regimes.

Code-as-Thought (CaT) uses code as the intermediate reasoning representation. In this paradigm, code is not merely a final artifact emitted after reasoning; the code itself is the reasoning scaffold, serving as a structured, inspectable, and often verifiable symbolic thought process. Recent work frames this as an alternative to text-based chain-of-thought, especially when a task benefits from explicit variables, control flow, state tracking, and interpreter-backed computation rather than free-form verbal rationales (Tang et al., 11 Sep 2025, Li et al., 2023).

1. Conceptual foundations

CaT is motivated by a recurring limitation of text-based reasoning: the intermediate steps of textual chain-of-thought are difficult to verify, and they can remain plausible even when the underlying numbers, state updates, or symbolic transformations are wrong. In chart understanding, this problem is tied directly to numerical hallucination; in general reasoning, it appears as brittleness in arithmetic, symbolic manipulation, and long-horizon state tracking. Code is attractive because it provides a general syntactic structure to build complex programs and an interface by which existing APIs paired together with an interpreter can be used to perform precise algorithmic computations (Tang et al., 11 Sep 2025, Li et al., 2023).

Within this framing, CaT is broader than “generate some code after reasoning.” In the code-centric view, the model reasons through variables, loops, helper functions, conditionals, and state transitions. The resulting trace is therefore more structured than ordinary natural-language CoT, and some portions can be executed exactly rather than inferred token by token. The literature surrounding CaT repeatedly treats this shift as a move from narrative intermediate steps to program-shaped intermediate cognition (Li et al., 2023).

A central qualification is that code is not always appropriate. The chart-understanding literature states explicitly that a fixed, code-only implementation consistently fails on complex charts where symbolic representation is unsuitable. This makes CaT not a universal replacement for text or direct perceptual reasoning, but a reasoning mode whose utility depends on whether the problem can be faithfully translated into symbolic form (Tang et al., 11 Sep 2025).

2. Intermediate representations and the meaning of “code”

The most literal form of CaT represents the intermediate reasoning trace as code or pseudocode. “Chain of Code” encourages models to write code to solve the problem, then executes that code via a code interpreter when possible and via an LM when not. Its key idea is to format semantic sub-tasks in a program as flexible pseudocode that the interpreter can explicitly catch and hand off to simulate with an LM, called the LMulator. In this setting, executable code and non-executable semantic operators coexist inside a single program-shaped trace (Li et al., 2023).

A second form is semantically structured planning for code generation. “Semantic Chain-of-Thought” introduces semantic information of code, such as data flow and control flow, to guide code synthesis. Its motivation is that semantic information describes more precise program execution behavior, intention and function, and that this information can be automated through the intrinsic capabilities of LLMs via in-context learning rather than through complex static or dynamic code analysis. This suggests a code-centered intermediate representation even when the representation itself is a semantic scaffold about code rather than executable code proper (Ma et al., 2023).

A third form is explicitly hybrid. “Human-Think Language” argues that people think through the logic in natural language before writing it as code, and proposes a new generation paradigm that uses full CoT reasoning to control code generation. Its PoT stage is therefore not unconstrained direct program synthesis; it is code generated from a prior thought representation, with Focus Attention directing model attention to the CoT reasoning during PoT to generate more logical code (Li et al., 2024).

Taken together, these systems indicate that “code” in CaT can denote several closely related objects: executable programs, flexible pseudocode with undefined semantic operators, or program-semantic plans that later condition code synthesis. A plausible implication is that CaT is best viewed as a family of code-centered intermediate representations rather than a single format.

3. Execution, self-examination, and routing architectures

The operational core of many CaT-style systems is not just code generation but code-mediated inference. In Chain of Code, the inference pipeline has two stages: generation and execution. An LM first generates code or pseudocode; execution then proceeds line by line, with Python used when a line is executable and the LMulator used when execution fails or raises an exception. Python and the LMulator share the same evolving program state, allowing arbitrary interweaving, including control flow like for-loops and if-statements. The preferred final answer is taken from a variable named answer, with an LM fallback only in case of irrecoverable errors (Li et al., 2023).

For code generation, CodeCoT addresses a different failure mode: reasoning traces that are logically helpful but syntactically contaminating. Its pipeline consists of CoT Prompt, Test Cases Generation, Code Generation, and Self-Examination. The model generates code and test cases in the same prompt, the code is executed against those test cases in the local environment, and if the local environment raises error information such as invalid syntax, the system iteratively refines the code based on the feedback information. The iterative procedure is user-specifiable, with a default of five iterations (Huang et al., 2023).

In chart understanding, CaT is routed adaptively rather than applied unconditionally. “Visual Programmability” defines a learnable property that determines if a chart-question pair is better solved with code or direct visual analysis. The resulting framework allows a VLM to choose between the CaT pathway and a direct visual reasoning pathway, and trains that selection policy with reinforcement learning using a dual-reward system that combines a data-accuracy reward with a decision reward (Tang et al., 11 Sep 2025).

These architectures share a common premise: code-centered reasoning becomes materially more useful when paired with explicit runtime mechanisms. Those mechanisms can take the form of exact execution, LM-based semantic simulation, local bug detection and repair, or a learned router that decides when symbolic reasoning should be used at all.

4. Empirical evidence and task regimes

The strongest broad evidence for CaT-style reasoning comes from Chain of Code. On BIG-Bench Hard, Chain of Code achieves 84%, a gain of 12% over Chain of Thought. Its gains are especially large on algorithmic tasks, where CoC Interweave reaches 95% average against 71% for CoT, while on NLP tasks it is roughly on par with CoT at 74%. The ablations are also diagnostic: Python only reaches 48%, LM only 57%, and Interweave 84%, indicating that neither pure execution nor pure language-model simulation is sufficient on its own (Li et al., 2023).

For code generation, CodeCoT reports that ordinary CoT can degrade executability even when the logic flow is correct, and that its self-examination loop improves pass@1 on HumanEval from 75.6% to 79.3%. The improvement is attributed not to changing the logical plan alone, but to systematically catching syntax and execution errors through locally generated test cases and iterative repair (Huang et al., 2023).

Hybrid planner-to-program methods show a related pattern. HTL reports an average improvement of 6.5% on the Llama-Base model and 4.3% on the Mistral-Base model across 8 mathematical calculation datasets. Its evidence supports the claim that direct Program-of-Thought can reduce calculation errors yet introduce more reasoning errors, and that conditioning code generation on a full CoT plan can recover some of that lost semantic reliability (Li et al., 2024).

In chart understanding, the case for adaptivity is unusually sharp. A Code-as-Thought specialist is reported at 71.6% on ChartX but only 18.4% on CharXiv. The interpretation offered there is that code excels when the chart can be faithfully converted into a symbolic representation, but can be harmful when symbolic translation itself is unreliable (Tang et al., 11 Sep 2025).

SeCoT’s abstract places semantic planning inside the same empirical trend. It reports experimental study on HumanEval, HumanEval-ET and MBPP, and states that SeCoT can achieve state-of-the-art performance while focusing on ChatGPT and WizardCoder as representative GPT-style models (Ma et al., 2023).

5. Failure modes, limitations, and common misconceptions

A persistent misconception is that code automatically makes reasoning faithful. The recent literature rejects that view. In chart understanding, a fixed code-only strategy fails when the model writes code encoding the wrong data and then reasons perfectly over that false symbolic world; the failure mode is numerical hallucination in the symbolic representation itself (Tang et al., 11 Sep 2025).

Another misconception is that direct Program-of-Thought uniformly improves reasoning. HTL argues the opposite: using PoT introduces more reasoning errors, such as incorrect formulas or flawed logic, compared to CoT. The cited failure modes include incorrect question comprehension, flawed reasoning, bias in question interpretation during code generation, recurrent mistakes in variable initialization, incorrect formulas, and logically inconsistent code. In this diagnosis, execution only guarantees faithful arithmetic conditional on the program being right; it does not guarantee the right program (Li et al., 2024).

The literature also distinguishes semantic difficulty from syntactic difficulty. CodeCoT observes that CoT can help code generation with logic flow but hurt executability because models may produce outputs that mix explanatory text, pseudocode-like structure, and invalid Python. Its self-examination loop is designed precisely because logically correct reasoning is not enough when the final object must obey strict syntax (Huang et al., 2023).

Even strong code-centric systems are not uniformly superior. Chain of Code states that many semantic tasks are rather difficult, and at times nearly impossible, to express in code. Its task-level results show cases where CoC does not help or underperforms CoT, including Causal Judgement, Formal Fallacies, Ruin Names, and Salient Translation Error Detection. A plausible implication is that CaT is best treated as a conditional reasoning strategy whose success depends on the match between task structure and symbolic decomposability (Li et al., 2023).

6. Relation to adjacent methods and terminological boundaries

The current CaT landscape is best understood as a design space rather than a single algorithm. Chain of Code is one of the clearest examples of code as the primary intermediate representation of reasoning, but it is a hybrid executable-plus-simulated system rather than a strict “everything must be machine-executable” formulation. Its own wording is that the method enables the LM to “think in code” (Li et al., 2023).

SeCoT occupies a nearby position. It is highly relevant to CaT because it replaces direct text-to-code mapping with an intermediate semantic layer centered on program behavior, control flow, and data flow. The supplied description positions it as a close variant or adjacent precursor to CaT rather than a pure direct instance, because the intermediate object is semantic reasoning about code rather than code itself (Ma et al., 2023).

HTL functions as a corrective to naive code-as-thought. Its thesis is not that code alone should be the thought medium, but that natural language is often the planner and code the execution substrate. In that formulation, the ordering is question $\rightarrow$ CoT $\rightarrow$ PoT, and the main technical objective is to make PoT generation rely on the CoT answer (Li et al., 2024).

The term should also be distinguished from unrelated uses of similar acronyms. “CaTT contexts are finite computads” concerns CaTT, a dependent type theory for weak $\omega$-categories, and not Code-as-Thought in the reasoning-and-code sense. There, CaTT is a syntactic formalism for weak $\omega$-categories, and the title’s “CaTT” refers to a categorical and type-theoretic framework rather than LLM reasoning with code (Benjamin et al., 2024).

Across these adjacent literatures, the recurring technical pattern is stable: introduce an intermediate representation between raw language and final answer, make variables, dependencies, and state transitions explicit, and use execution, simulation, or routing mechanisms to determine when code should carry the reasoning burden.