Simple-RTC: Reasoning Before Coding

• Simple-RTC is a staged inference approach that separates explicit algorithm design from code generation, improving clarity in tackling graph problems.
• It follows a four-stage pipeline—formatting, extracting, reasoning, and coding—to create an intermediate pseudocode artifact before producing executable code.
• Empirical evaluations show Simple-RTC achieves near-perfect scores on legacy benchmarks while highlighting challenges on more complex graph algorithms.

Simple-Reasoning-Then-Coding (Simple-RTC) is a staged inference baseline in which a LLM 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” (Hu et al., 29 Sep 2025). 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 (Hu et al., 29 Sep 2025).

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 (Hu et al., 29 Sep 2025). 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 (Hu et al., 29 Sep 2025).

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 (Hu et al., 29 Sep 2025).

2. Four-stage pipeline and intermediate artifacts

The baseline consists of four steps: Formatting, Extracting, Reasoning, and Coding (Hu et al., 29 Sep 2025). 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 (Hu et al., 29 Sep 2025).

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 (Hu et al., 29 Sep 2025). 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 (Hu et al., 29 Sep 2025). 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 (Hu et al., 29 Sep 2025). 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 (Hu et al., 29 Sep 2025).

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 (Hu et al., 29 Sep 2025). 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 (Hu et al., 29 Sep 2025).

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 (Hu et al., 29 Sep 2025). 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 (Hu et al., 29 Sep 2025).

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 (Hu et al., 29 Sep 2025). 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 (Hu et al., 29 Sep 2025). 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 (Hu et al., 29 Sep 2025).

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” (Allamanis et al., 2024).

At the methodological level, Simple-RTC occupies the minimal end of a broader spectrum. “Code-enabled LLMs 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 (Zhang et al., 23 Oct 2025). 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 (Li et al., 11 Jun 2025). “Towards Effective Code-Integrated Reasoning” formalizes a similar loop with

$$\mathcal{M}(\mathcal{G}, \mathcal{Q}) \rightarrow \mathcal{C}, \text{exec}(\mathcal{C}) \rightarrow \mathcal{A}.$$0

emphasizing adaptive code triggering and tool-augmented RL rather than a fixed two-stage architecture (Bai et al., 30 May 2025).

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 $$\mathcal{M}(\mathcal{G}, \mathcal{Q}) \rightarrow \mathcal{C}, \text{exec}(\mathcal{C}) \rightarrow \mathcal{A}.$$1 and a final code $$\mathcal{M}(\mathcal{G}, \mathcal{Q}) \rightarrow \mathcal{C}, \text{exec}(\mathcal{C}) \rightarrow \mathcal{A}.$$2 derived from $$\mathcal{M}(\mathcal{G}, \mathcal{Q}) \rightarrow \mathcal{C}, \text{exec}(\mathcal{C}) \rightarrow \mathcal{A}.$$3; their contribution is structured, SDLC-guided supervision rather than an inference-only baseline (Yang et al., 19 Mar 2025). 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 (Xu et al., 2024). RHDA similarly treats hypotheses $$\mathcal{M}(\mathcal{G}, \mathcal{Q}) \rightarrow \mathcal{C}, \text{exec}(\mathcal{C}) \rightarrow \mathcal{A}.$$4 as explicit intermediate objects that are decomposed, translated into executable form via $$\mathcal{M}(\mathcal{G}, \mathcal{Q}) \rightarrow \mathcal{C}, \text{exec}(\mathcal{C}) \rightarrow \mathcal{A}.$$5, validated with tools, and amended iteratively (Zhao et al., 17 Feb 2025). 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 (Zhao et al., 23 Apr 2026).

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 (Malek et al., 9 Jul 2025). The paper’s travel-planning results are particularly salient: at $$\mathcal{M}(\mathcal{G}, \mathcal{Q}) \rightarrow \mathcal{C}, \text{exec}(\mathcal{C}) \rightarrow \mathcal{A}.$$6, only o1 remains materially above zero among the main reported models, while several frontier systems collapse to 0.00 pass@5 (Malek et al., 9 Jul 2025). 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 (Hu et al., 29 Sep 2025). 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 (Hu et al., 29 Sep 2025). 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 (Allamanis et al., 2024). 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 (Zhang et al., 23 Oct 2025).

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 (Bridgeford et al., 25 Oct 2025). In reasoning-augmented code generation, it appears as the formal requirement to generate reasoning steps $$\mathcal{M}(\mathcal{G}, \mathcal{Q}) \rightarrow \mathcal{C}, \text{exec}(\mathcal{C}) \rightarrow \mathcal{A}.$$7 and final code $$\mathcal{M}(\mathcal{G}, \mathcal{Q}) \rightarrow \mathcal{C}, \text{exec}(\mathcal{C}) \rightarrow \mathcal{A}.$$8 where $$\mathcal{M}(\mathcal{G}, \mathcal{Q}) \rightarrow \mathcal{C}, \text{exec}(\mathcal{C}) \rightarrow \mathcal{A}.$$9 is derived from $$\mathcal{G}=(\mathcal{V}, \mathcal{E}, \{s_i\}, \{t_i\}),$$0 (Yang et al., 19 Mar 2025).

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 (Allamanis et al., 2024). 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.