---
title: 'Simple-RTC: Reasoning Before Coding'
url: https://www.emergentmind.com/topics/simple-reasoning-then-coding-simple-rtc
type: topic
---

# Simple-RTC: Reasoning Before Coding

Simple-Reasoning-Then-Coding (Simple-RTC) is a staged inference baseline in which a large language model first produces an explicit reasoning artifact—most centrally an algorithm design or pseudocode—and only then generates executable code from that intermediate representation. In the literature, the term is introduced explicitly for graph reasoning, where it is proposed as a simple and strong baseline that “guides LLMs to design graph algorithms first and then code to address graph reasoning tasks” [2509.24260]. More broadly, the label is useful for a family resemblance across recent work on code generation: separate problem analysis from implementation, treat reasoning as an intermediate object rather than hidden latency, and delegate repetitive execution to code rather than to natural-language simulation.

## 1. Canonical definition and conceptual basis

In its canonical formulation, Simple-RTC is motivated by a contrast between two ways of using LLMs on graph problems. Prior language-based graph reasoning is framed as
\[
\mathcal{M}(\mathcal{G}, \mathcal{Q}) \rightarrow \mathcal{A},
\]
while code-augmented methods are framed as
\[
\mathcal{M}(\mathcal{G}, \mathcal{Q}) \rightarrow \mathcal{C}, \text{exec}(\mathcal{C}) \rightarrow \mathcal{A}.
\]
Simple-RTC is a particular code-producing approach, but it does not ask the model to code directly from the raw graph instance. Instead, it inserts an explicit algorithm-design stage between task understanding and execution [2509.24260].

The graph input is represented as
\[
\mathcal{G}=(\mathcal{V}, \mathcal{E}, \{s_i\}, \{t_i\}),
\]
where \(\mathcal{V}\) is the node set, \(\mathcal{E}\) is the edge set, \(s_i\) are node text features, and \(t_i\) are edge text features [2509.24260]. The central claim is that many prior graph-reasoning evaluations ask LLMs to do the wrong kind of work: not to design graph algorithms, but to replicate graph algorithm execution in natural language. The paper characterizes this failure mode as one of “repetitive iterative and backtracking operations,” which becomes increasingly brittle as graphs become larger or denser [2509.24260].

The distinction between **replicating graph algorithms** and **designing graph algorithms** is therefore foundational. In the former, the model is implicitly asked to simulate traversal, dynamic programming, or search in text. In the latter, the model is asked to identify the graph-theoretic structure, choose an algorithmic paradigm, specify data structures, and write pseudocode, leaving exact execution to Python. This separation is the defining principle of Simple-RTC [2509.24260].

## 2. Four-stage pipeline and intermediate artifacts

The baseline consists of four steps: **Formatting**, **Extracting**, **Reasoning**, and **Coding** [2509.24260]. These steps are not merely rhetorical labels; they define distinct artifacts that mediate between the original natural-language problem and the final executable program.

**Formatting** converts a natural-language graph problem into a standardized, data-free formulation with normalized input and output descriptions. The appendix prompt requires the model to output only an `Input` section and an `Output` section, thereby turning an instance-specific description into a reusable task schema [2509.24260].

**Extracting** generates a Python program that uses regular expressions to recover the actual instance data from the natural-language statement and rewrite it into standardized stdin format. The paper specifies that the extractor should take `problem_path` and `standard_input_path` as positional `argparse` arguments and cautions about details such as replacing spaces in node names with `_`, handling periods in node names, and removing example edges such as `(i,j)` when they appear in the statement [2509.24260]. A related extraction prompt also produces a “Pure Problem” by substituting data with variables.

**Reasoning** is the core “Reasoning-Then” stage. The model is prompted to “Think step by step, design an efficient algorithm to solve this problem, write a corresponding pseudocode,” and then summarize the result under a `Pseudocode` header [2509.24260]. The explicit intermediate representation is therefore not free-form chain-of-thought but pseudocode: an algorithm description containing the core logic, key data structures, and step-by-step solution approach.

**Coding** then consumes the problem formulation and the pseudocode. The coding prompt instructs the model to “Write Python code to solve the problem according to the pseudocode” and output only a fenced Python block [2509.24260]. The final answer is obtained by running this generated solver on the standardized input produced by the extractor.

This staging makes the intermediate artifact inspectable. In the appendix example for TSP, the reasoning step derives a state-compression dynamic programming algorithm over subsets before the coding step implements it, illustrating the intended labor split: abstract design in language, repetitive computation in code [2509.24260].

## 3. Benchmarking and empirical performance

The paper introducing Simple-RTC is simultaneously a benchmark critique and a benchmark proposal. It argues that existing graph reasoning suites—such as NLGraph, Talk like a Graph, GraphWiz, GraphArena, and GraphInstruct—mostly evaluate standard textbook graph problems and can therefore underestimate base model capability when the reasoning target is misaligned [2509.24260]. To address this, it constructs **GraphAlgorithm**, described in the main text as comprising **239 different graph problems and 3,041 test instances collected from 4 competition platforms**; an appendix table reports **238** problems, so both figures appear in the paper [2509.24260].

The main benchmark results are as follows.

| Benchmark | GPT-4o-mini | Simple-RTC |
|---|---:|---:|
| NLGraph | 41.4 | 99.3 |
| Talk like a Graph | 61.3 | 99.9 |
| GraphInstruct | 59.9 | 99.9 |
| GraphWiz | 51.6 | 92.7 |
| GraphArena | 35.1 | 97.5 |
| GraphAlgorithm | 14.3 | 33.7 |

These numbers support two distinct conclusions. First, on legacy graph benchmarks, Simple-RTC achieves near-perfect accuracy, with especially strong scores on NLGraph, Talk like a Graph, and GraphInstruct [2509.24260]. Second, on the harder GraphAlgorithm benchmark, performance remains far from saturated: Simple-RTC reaches **33.7**, substantially above **GPT-4o-mini** at **14.3**, but well below its own results on prior suites [2509.24260].

Fine-grained results clarify where difficulty remains. On GraphWiz, Simple-RTC is perfect on Cycle, Connect, Bipartite, Topology, Shortest, Triangle, and Flow, but only **42.3** on Hamilton and **91.8** on Subgraph [2509.24260]. On GraphArena, it remains very strong on both polynomial-time and NP-complete tasks, including **100.0 / 95.2** on TSP for small/large graphs, but drops to **97.0 / 68.6** on MCS [2509.24260]. The paper also reports that replacing the reasoning-stage model with stronger reasoners such as **o3-mini-high** or **DeepSeek-R1**, while keeping extraction and coding fixed, yields further gains on GraphAlgorithm, reinforcing the claim that the reasoning stage is the primary bottleneck [2509.24260].

## 4. Relation to adjacent methods and terminological distinctions

A necessary distinction is terminological. In “Unsupervised Evaluation of Code LLMs with Round-Trip Correctness,” **RTC** means **round-trip correctness**, an unsupervised evaluation framework for code LLMs, not Simple-Reasoning-Then-Coding. That work formalizes evaluation through a forward model \(M:\mathbb{X}\rightarrow\mathbb{Y}\), a backward model \(M^{-1}:\mathbb{Y}\rightarrow\mathbb{X}\), and a semantic similarity function, and explicitly states that it does **not** introduce or discuss a method called “Simple-Reasoning-Then-Coding” [2402.08699].

At the methodological level, Simple-RTC occupies the minimal end of a broader spectrum. “Code-enabled language models can outperform reasoning models on diverse tasks” presents **CodeAdapt**, which combines **CodeAct**—an inference framework where models interleave natural-language reasoning with code execution in a multi-step fashion—with **Generalization-guided Few-shot Learning (GFL)**. That method explicitly instructs the model to “Think and plan in natural language,” then write code cells, then return an answer, but its dominant empirical pattern is iterative alternation rather than one-pass reasoning followed by coding [2510.20909]. Likewise, **CoRT** defines trajectories of repeated text-program-output triples,
\[
\tau_t = \{(n_1, p_1, o_1), \ldots, (n_t, p_t, o_t)\},
\]
and trains models against delayed code computation and code result distrust, again moving beyond a strict single handoff from reasoning to code [2506.09820]. “Towards Effective Code-Integrated Reasoning” formalizes a similar loop with
\[
c_t = f_\theta(q, h_t), \quad r_t = \mathcal{I}(c_t), \quad h_{t+1} = h_t \cup c_t \cup r_t,
\]
emphasizing adaptive code triggering and tool-augmented RL rather than a fixed two-stage architecture [2505.24480].

Other lines of work preserve the staged intuition while varying how the intermediate reasoning artifact is obtained. **SVRC** and **CodeThinker** define reasoning-augmented code generation as generating a sequence of reasoning steps \(\mathit{R}=\{r_1,\dots,r_n\}\) and a final code \(\mathit{C}\) derived from \(\mathit{R}\); their contribution is structured, SDLC-guided supervision rather than an inference-only baseline [2503.14838]. **SRA-MCTS** is even closer to Simple-RTC at the representation level: it first generates a natural-language step-by-step solution plan, then generates code from that plan, but obtains the plan via Monte Carlo tree search and uses the resulting Question–Plan–Code triples for self-training [2411.11053]. **RHDA** similarly treats hypotheses \(h^t\) as explicit intermediate objects that are decomposed, translated into executable form via \(g:\Sigma^* \rightarrow \Sigma_\mathcal{E}^*\), validated with tools, and amended iteratively [2502.13170]. **Thinking with Reasoning Skills** reduces online planning further by retrieving compact skill cards—Trigger, Do, Avoid, Check, Risk—before solving coding tasks, effectively replacing fresh long-form reasoning with reusable distilled heuristics [2604.21764].

This suggests a useful taxonomy. Simple-RTC is the minimal staged baseline: standardized problem, intermediate pseudocode, implementation. Adjacent systems preserve the same separation of concerns but add search, tool feedback, reflection, retrieval, or explicit process supervision.

## 5. Assumptions, failure modes, and misconceptions

A common misconception is that the “simple reasoning” stage in Simple-RTC is intrinsically reliable because it is conceptually easier than full code generation. Recent evidence cuts against that assumption. “Frontier LLMs Still Struggle with Simple Reasoning Tasks” shows that even frontier thinking models consistently fail on procedurally generated tasks that are easy for humans, including counting, first-order logic, proof trees, and travel planning, for reasons such as **statistical shortcuts, errors in intermediate steps, and difficulties in processing long contexts** [2507.07313]. The paper’s travel-planning results are particularly salient: at \(S=20, N=8\), only **o1** remains materially above zero among the main reported models, while several frontier systems collapse to **0.00** pass@5 [2507.07313]. This directly matters for any Simple-RTC pipeline whose first stage must derive a plan before coding it.

The graph-reasoning results reveal the same tension from another angle. Simple-RTC nearly saturates earlier graph benchmarks, but remains at **33.7** on GraphAlgorithm, only **42.3** on GraphWiz Hamilton, and **68.6** on large-graph MCS in GraphArena [2509.24260]. The method is also presented as a simple staged pipeline rather than an iterative repair agent: the description includes no self-consistency module, no debugging loop, and no dedicated training on the reasoning step [2509.24260]. The authors explicitly note that they do not conduct dedicated training on that stage.

Another misconception is terminological: because “RTC” already denotes round-trip correctness in code-LLM evaluation, the term can be read incorrectly as an evaluation protocol rather than a reasoning-before-coding baseline. The literature is explicit that these are different notions [2402.08699]. A further misconception is architectural: several successful reasoning-with-code systems are not evidence that a strict one-pass Simple-RTC control flow is always optimal. Works such as CodeAdapt, CoRT, and CIR repeatedly show gains from interleaving reasoning, code execution, and revision, rather than from a single reasoning block followed by a single coding block [2510.20909].

## 6. Methodological significance

Simple-RTC is methodologically significant because it operationalizes a broad principle that recurs across current research: **problem framing and algorithm design should be separated from mechanical implementation**. In scientific coding guidance, this appears as the claim that “Framing a problem in a programmatic way and coding are not the same thing,” and the recommendation to begin coding sessions by first understanding and articulating the problem and thinking through how it might be solved [2510.22254]. In reasoning-augmented code generation, it appears as the formal requirement to generate reasoning steps \(\mathit{R}\) and final code \(\mathit{C}\) where \(\mathit{C}\) is derived from \(\mathit{R}\) [2503.14838].

Within that broader landscape, Simple-RTC matters for two reasons. First, it shows that a relatively small architectural change—forcing an explicit pseudocode stage—can radically change what existing benchmarks measure. Second, it provides a transparent baseline against which more elaborate systems can be compared. When stronger systems later add search, tool use, reflection, or learned value models, the question becomes whether those additions improve on the staged decomposition or merely compensate for weaknesses in the initial reasoning artifact.

A plausible implication is that Simple-RTC also suggests an evaluation principle. If a system claims that its intermediate reasoning is useful, then one can ask whether that intermediate representation preserves enough semantics to support correct downstream reconstruction, in the spirit of round-trip correctness [2402.08699]. Another plausible implication is that the most important open problem is not whether code execution helps, but how to make the intermediate reasoning artifact—pseudocode, plan, edit description, or retrieved skill—both informative and reliable under distribution shift, long contexts, and combinatorial structure.

In that sense, Simple-RTC is best viewed not as the endpoint of reasoning-and-coding research, but as its simplest interpretable baseline: reason about the abstract task first, express that reasoning as an explicit artifact, and only then compile it into executable code.

Source: https://www.emergentmind.com/topics/simple-reasoning-then-coding-simple-rtc