Code Synthesis Techniques: What Each AI Coding Tool Actually Does (Part 7 of 15)

By Dr. Sanju Abraham, Fractional CTO, investor, multiple exits. Published October 23, 2026. Part 7 of a 15-part series: Comparing Opencode, Claude Code, Codex, and Cursor: Is There a Clear Winner?

New to the series? Part 1 — AI Code Generation and Developer Productivity. Part 2 — Overview of the four tools. Part 3 — The Role of Language Models. Part 4 — Deep Learning Foundations. Part 5 — Training Data and Code Quality. Part 6 — Code Completion Compared — the four completion modes. This part goes one layer deeper: the synthesis techniques each tool uses to produce the code behind those modes.

Key takeaways

• “Code synthesis technique” is six things, not one. Context assembly, planning strategy, tool use, self-correction, model routing, and diff format are the six real techniques; everything else is marketing on top.
• Context assembly is the biggest hidden differentiator. How a tool decides which files to pack into the prompt — grep, repo index, LSP, semantic embeddings, or hybrid — explains most of why “the model is dumb on my repo” is almost always a wrapper problem.
• Planning strategies diverge sharply. Claude Code tends to plan first and show the plan; Codex iterates in a tighter loop with execution feedback; Opencode is pluggable; Cursor’s Composer plans visibly inside the editor.
• Self-correction is where modern tools earn their keep. Running tests, reading errors, and retrying — the “reflexion” pattern — is now standard. Tools differ on how aggressively they retry and how transparently they show it.
• No tool wins all six techniques. The pick depends on which techniques matter most for your workload, which maps back to the five-variable pick from Part 1.

The short answer: Code synthesis in late 2026 is not “the model writes code” — it is a six-step pipeline the wrapper orchestrates around the model: (1) context assembly (what files go into the prompt), (2) planning (how the model decides what to do), (3) tool use (how the model reads, writes, and runs), (4) self-correction (how failures are retried), (5) model routing (fast model for small jobs, strong model for hard ones), and (6) diff synthesis (patch vs. full-file rewrites). The four tools in this series — Opencode, Claude Code, Codex, Cursor — all run this pipeline, but each one makes different trade-offs at each step. This piece scores each of them on each technique and explains when those trade-offs matter.

What are the six real techniques behind modern code synthesis?

Any serious comparison of AI code synthesis starts by naming the techniques the tools actually implement — otherwise the comparison reduces to vendor marketing. The six that matter in late 2026:

• Context assembly. The wrapper decides which files, snippets, docs, and symbols to include in the prompt. Methods range from naïve grep to LSP-driven symbol resolution to semantic embeddings with a RAG step. The quality of context assembly explains most of the “my repo is big and the model is confused” complaints.
• Planning. The agent chooses whether to plan-first-then-execute (write a plan, show it, run it), react-and-adjust (take a step, observe, pick the next step), or something in between like tree-of-thoughts. Different planning strategies produce different failure modes.
• Tool use. The model emits structured tool calls — read file, write file, run shell, run tests, grep, apply patch — and the wrapper executes them. Modern tools use OpenAI function calling, Anthropic tool use, or the open Model Context Protocol (MCP).
• Self-correction. When a test fails or a file does not compile, the agent reads the error, revises its plan, and retries. This is the “reflexion” pattern from the 2023 Shinn et al. paper. It is one of the single biggest reasons late-2026 agents are more reliable than their 2024 ancestors.
• Model routing. The wrapper routes small, fast interactive work (completion, inline edits) to a cheap small model and reserves the strong-but-slow frontier model for hard planning or long multi-file tasks. Cursor and Codex both do this explicitly; Claude Code lets you pick per task; Opencode exposes every model you have configured.
• Diff synthesis. The agent emits changes as unified diffs, as search/replace blocks, or as full-file rewrites. Diff format decides reviewability — small diffs are easier to review than full-file rewrites, which matter at code-review time.

For the companion piece on where this entire pipeline sits inside the broader agent architecture, see Decision models in an agent stack.

How does context assembly differ across the four tools?

Context assembly is the single most under-discussed differentiator in AI code synthesis — and the one that most often decides whether a tool “feels smart” on your repo.

• Claude Code — long-context + explicit file reads. Anthropic’s long context window (hundreds of thousands of tokens) lets the agent pull many files into one prompt. The agent reads files it decides it needs rather than relying on a precomputed index.
• Codex — hybrid read + sandbox. The agent reads files on demand and runs grep, run-tests, and other tools in a sandbox. The cloud agent has a longer-horizon context budget than the local CLI.
• Opencode — pluggable, model-dependent. Context assembly is a config concern; Opencode supports MCP servers for retrieval and lets you plug in your own context providers. Quality tracks the setup.
• Cursor — repo-wide index + agent reads. Cursor maintains a semantic index of the open workspace that Composer and Agent both consult. This is why Cursor often “just knows” where a symbol lives without the user naming the file.

The practical implication: on very large repositories, Claude Code’s long-context reads and Cursor’s semantic index usually feel sharpest, in different ways. Codex and Opencode close the gap when context providers are configured well. For a related framing on how context quality shapes model behavior, see Training Data and Code Quality (Part 5).

What planning strategies do the agents use?

Each tool exposes a visibly different planning style, which is often the first thing a developer notices in their first hour with it.

• Claude Code — plan-first, show the plan. The agent typically produces an explicit plan (“I will do these five steps…”) before touching files, especially for multi-step work. The developer approves or revises the plan before execution.
• Codex — ReAct with execution feedback. Codex iterates in a tighter loop: take a step, run tests, observe the result, pick the next step. The cloud agent uses longer, deeper iteration budgets than the local CLI.
• Opencode — model-dependent. With Claude Sonnet, planning tends toward plan-first; with GPT-5, it tends toward ReAct-with-execution. Opencode exposes the pattern of whichever model you call.
• Cursor — Composer with visible planning. Agent mode inside Composer shows the plan and the steps as it executes; the review surface stays inside the editor.

No single planning strategy dominates. Plan-first wins when the task has clear requirements and the plan is cheap to review. ReAct-with-execution wins when tests exist and the fastest path is “try it and see.” Teams end up favoring tools whose default planning style matches their own development habits.

How does self-correction change the quality of generated code?

Self-correction — running the code, reading the error, revising the plan, retrying — is the single biggest reason late-2026 agents produce code that compiles and tests more often than their 2024 ancestors.

The pattern has a name in the literature: reflexion, from Shinn et al., 2023. The agent is prompted to reflect on failures and incorporate them into the next attempt. In practice, this means:

• The agent writes code and runs it (or runs the tests).
• When something fails, the agent reads the stderr or test output.
• The agent revises its plan or its code and retries.
• The loop terminates when tests pass or the retry budget runs out.

How each tool implements this differs:

• Claude Code retries with explicit summaries of what it tried and why it changed its approach.
• Codex iterates aggressively with execution feedback; the cloud agent has larger retry budgets than the local CLI.
• Opencode supports self-correction via tool use; the behavior depends on the model you pointed it at.
• Cursor retries inside Composer, with the retry visible in the editor pane.

The honest trade-off: more aggressive retries catch more real failures but spend more tokens and more time. Teams on tight budgets or short-feedback workflows benefit from capping the retry depth; teams running long autonomous tasks benefit from letting the loop run.

What role does model routing play in synthesis quality?

Model routing — sending each task to the right-sized model — is quietly one of the biggest performance improvements of the last twelve months.

Two patterns dominate in late 2026:

• Small-fast for interactive, big-slow for hard. Cursor sends inline tab completion to its own small models (cursor-small, cursor-tab) and routes Composer/Agent work to frontier Anthropic and OpenAI models. The user experience is “instant where it matters, strong where it matters.”
• Mixture of experts under the hood. Many frontier coding models (GPT-5-codex, several Claude variants) are themselves mixture-of-experts internally: a routing network inside the model sends each token to a subset of specialized “experts,” making a very large model behave like a smaller one at inference time.

Opencode and Claude Code expose model routing as a config/surface choice; Cursor and Codex do it opaquely as part of their product. The practical difference: when a bill shows up at the end of the month, teams on the vendor-locked tools have less lever on cost; teams on Opencode can pick a cheaper model for the easy work. For the cost-side treatment of this trade-off, see Part 9 of this series (coming soon).

What diff format does each tool use, and does it matter?

Diff format is a quiet but material differentiator — not for synthesis quality itself, but for how reviewable the output is.

Three patterns:

• Unified diff / patch. The agent produces output that applies cleanly as patch. Easy to review line by line in a code-review tool. Preferred by terminal-first developers and CI pipelines. Standard in Claude Code and Opencode’s terminal flows.
• Search/replace blocks. The agent emits “find this exact string, replace with this new string” pairs. Robust against context shifts in large files. Common in Codex and Aider-style tools.
• Full-file rewrites. The agent emits the whole file as a new version. Simple to apply, bad for review on long files, and dangerous when the rewrite “accidentally” drops a comment or helper the agent did not realize mattered.

Modern tools support multiple formats and pick based on the size of the change. The one honest warning: full-file rewrites on long files are the most common vector for silent regressions. Teams reviewing agent output on long files should insist on diffs, not rewrites, even when the tool defaults to the latter.

When does each tool win on synthesis technique?

Pick by the technique that matters most for your workload. The five-variable pick (editor, codebase, team shape, cost ceiling, security posture — see Part 1) continues to apply; this piece adds the synthesis dimension.

• Default to Claude Code when plan-first synthesis, explicit diffs, and long-context reads on a terminal-first workflow matter most. Enterprise defaults are a bonus.
• Default to Codex when execution-feedback loops, aggressive self-correction, and background-run budgets matter most. The cloud sandbox is a differentiator here.
• Default to Cursor when semantic repo indexing and visible-in-editor planning matter most. The IDE-native synthesis UX is unmatched.
• Default to Opencode when model-routing control and context-provider flexibility (via MCP) matter most. The agent is a tool you compose, not a product you buy.

For most teams the choice collapses to “where do you work?” plus “how big is your repo?” — the first picks the surface, the second picks the context strategy. Everything else is tuning.

Image placeholder

A clean, product-forward 6x4 scorecard infographic on an off-white background. The six rows are labeled context assembly, planning, tool use, self-correction, model routing, diff synthesis. The four columns are Opencode, Claude Code, Codex, Cursor. Each cell shows a pale emerald filled circle for 'strong,' pale slate half circle for 'adequate,' and empty outline for 'adequate-via-config' or 'not emphasized.' Short tagline above: 'The six-row synthesis scorecard, honestly filled in'. Palette: off-white background, pale slate borders, pale emerald accent, pale sand accent, navy ink. Linear or Stripe editorial feel. No AI robots.

• Aspect ratio: 16:9
• Source size: 1280 × 720 px (sharp on retina at 760 px display width)
• Format: PNG
• Target file size: under 500 KB

Save to /public/images/blog/<slug>/, then set src and alt on this <MediaFigure /> to swap it in. Keep the ratio prop so the browser reserves the right space.

Frequently asked questions

What is code synthesis in the context of AI coding tools?

Code synthesis is the end-to-end process by which an AI coding tool turns a prompt or task description into working code the developer can review and merge. In late 2026 it is a six-step pipeline: context assembly, planning, tool use, self-correction, model routing, and diff synthesis. Every modern tool — Opencode, Claude Code, Codex, Cursor — implements all six, but with different trade-offs at each step.

Why do the four tools produce different code for the same prompt?

Because they differ at every one of the six synthesis steps. Different context assembly strategies pull in different files; different planning strategies lead to different first steps; different self-correction behaviors catch different failure modes; different model routing sends the task to different models. Even on identical prompts, the four tools’ outputs diverge — which is why the honest pick depends on which synthesis technique matters most for your workload.

What is the reflexion pattern in AI code generation?

Reflexion, from Shinn et al. (2023), is a self-correction pattern where the agent writes code, runs it or the tests, reads the failure output, revises its approach, and retries. It is one of the single biggest reasons late-2026 coding agents produce code that compiles and tests more often than their 2024 ancestors. Every tool in this series implements some form of reflexion; the differences are in how aggressively they retry and how transparently they show the loop.

What is MCP, and why does it matter for synthesis?

MCP — the Model Context Protocol — is an open protocol for connecting AI tools to external context sources (files, databases, docs, APIs). It matters for synthesis because context assembly is the biggest hidden differentiator; MCP lets a tool like Opencode plug into third-party context providers rather than build every integration itself. Claude Code, Cursor, and others support MCP to varying degrees in late 2026.

Does model routing improve synthesis quality?

Usually yes, especially on cost and latency. Routing small, interactive work (inline completion, short edits) to a cheap small model and reserving the strong frontier model for hard planning or long multi-file tasks produces a user experience that is both instant and smart. Cursor and Codex route opaquely; Claude Code and Opencode expose routing as a config choice. The practical consequence is that model routing is one of the main levers teams have on cost at scale.

Is a unified diff always better than a full-file rewrite?

For reviewability, almost always yes. Unified diffs show exactly what changed, line by line, which is what a human reviewer needs. Full-file rewrites are easy to apply but hard to review on long files — they are the most common vector for silent regressions, where the agent “accidentally” drops a comment, a helper, or an import the review did not catch. Prefer tools and settings that emit diffs over rewrites, especially for anything load-bearing.

How can I evaluate a tool’s synthesis techniques before committing?

Run a two-day pilot on your own repo with your own prompts, and watch for four signals. First, context quality — does the tool pull in the right files without being told? Second, plan quality — is the plan it produces something a senior reviewer would also write? Third, self-correction — when a test fails, does the agent revise its approach or just retry blindly? Fourth, diff reviewability — can your team actually review the output in a code-review tool? These four signals are more predictive than any benchmark page.

---

If you are picking an AI coding tool for a team and the synthesis technique your workload needs is the deciding factor — context quality on a large repo, aggressive self-correction on test-heavy code, model routing for cost control — that is the kind of nuance a one-hour Fractional CTO call is for. For more pieces in this series as it publishes, follow the AI Strategy archive; the broader frame on where AI fits in a small or mid-market software business sits in AI strategy for SMB owners.