Divide-and-Conquer + Few-shot: why explicit instructions work even for reasoning models

Basic Divide-and-Conquer

STEP 1: Decomposition → a list of subtasks in an explicit order
STEP 2: Solve the subtasks → a result for each subtask
STEP 3: Composition → the final answer built from the parts

Runs in a single prompt or as a chain of requests, depending on complexity.

DC + Few-shot

STEP 0: Few-shot examples → 2-3 samples of a complete solution
STEPS 1-3: As above → the model follows the pattern from the examples

DC + ReAct (iterative version)

STEP 1: Decomposition + solving → first version
STEP 2: Check → review the result for errors
STEP 3: Refine → fix if needed
LOOP: Repeat 2-3 until the result is solid

DC + Verification

STEPS 1-3: Basic DC → you have a result
STEP 4: Verification → the model reviews the result as a critic
STEP 5: Refinement → improve it if the critic found problems

Verification needs a separate request after the main solution.

Task: You're the managing partner of a digital agency in Chicago. A client wants your take on an idea: launch a podcast about the tech business in the US and monetize it through ads and listener donations. The launch budget is $5,000. You need a detailed analysis: is it worth the investment?

Prompt:

Analyze this business idea through step-by-step decomposition:

STEP 1 — MARKET:
- Estimate demand for tech podcasts in the English-language market
- Find 3-5 direct competitors, their audience and monetization
- Which niches are oversaturated and which are underserved

STEP 2 — ECONOMICS:
- Break the $5,000 into cost items (equipment, promotion, first episodes)
- Realistic forecast: how long until payback under 2 models:
  a) ads only
  b) ads + donations
- Break-even point in dollars/month

STEP 3 — RISKS:
- Execution risks (content quality, release consistency)
- Market risks (competition, platform algorithm changes)
- Financial risks (if it doesn't break even within N months)

STEP 4 — VERDICT:
Based on steps 1-3:
- Is it worth investing $5,000 now?
- If yes — under what conditions (be specific)
- If no — what alternatives (specific, with reasoning)

Work through the steps in order. After each step — an interim conclusion. At the end — a final recommendation with numbers.

Result:

The model will deliver the analysis in blocks, one per step:

• Market: specific competing podcasts (e.g., "Acquired", "How I Built This"), audience data, open niches
• Economics: a cost table (microphone $500, editing $800/month, promotion $2,000), two monetization scenarios with a forecast in months
• Risks: a list with likelihood (high/medium/low) and mitigation strategies
• Verdict: a clear "yes" or "no" with reasoning and numbers from the previous steps

LLM weakness: Models generate text well locally (sentence by sentence) but struggle to hold the global structure of a complex line of reasoning. Without an explicit plan, a model can "forget" an important aspect or break the logical sequence. It's especially visible in multi-step tasks — the model may solve step 3 without accounting for the result of step 1.

LLM strength: Models are excellent at following explicit step-by-step instructions and patterns from examples. Spell out the algorithm and show a sample, and the model reproduces the structure precisely. Few-shot does what few-shot does: the model sees the pattern and applies it to new data.

How the method works: DC turns an abstract task ("analyze the idea") into a concrete sequence of operations ("market first, then economics, then risks, then the conclusion"). The model doesn't invent the structure — it executes an algorithm. Few-shot reinforces this: the model sees not only the instructions but also the implementation — what a correct answer looks like at each step. ReAct adds checking and correction — the model finds and fixes its own mistakes.

Prompt control knobs:

• Number of steps: Cut it for simple tasks (3 instead of 5) → fewer tokens, faster answer
• Instruction detail: Drop specific sub-items ("find 3-5 competitors") → the model decides the depth itself, but may skip details
• Few-shot examples: Give 1 instead of 3 → faster, but a fuzzier pattern. Give 0 → worse results, especially on hard tasks
• ReAct iterations: Specify "at most 2 iterations" → cheaper, but risks a half-baked result
• Output format: Add "no explanations, facts only" → a compact answer. Remove it → you see the model's reasoning

Reasoning models vs explicit instructions:

Even the o-series and Gemini 2.5, trained to reason, gain +9-16% accuracy with DC + few-shot. Reasoning helps the model execute each step better, but it doesn't replace the right structure for the task. Analogy: an experienced programmer (reasoning) still works better with a clear spec (DC) than with "write something useful".

Basic DC (no few-shot)

Solve the task through step-by-step decomposition:

STEP 1 — {subtask_name_1}:
{what to do at this step}
{what format the result should take}

STEP 2 — {subtask_name_2}:
{what to do, using the result of step 1}
{what format the result should take}

STEP 3 — {subtask_name_3}:
{what to do, using the results of steps 1-2}
{what format the result should take}

STEP 4 — FINAL ANSWER:
Based on steps 1-3, give {specific format of the final output}

Work through the steps in order. After each step — an interim conclusion. At the end — the final result.

TASK: {your_task}

Placeholders:

• {subtask_name} — a short name for the stage (Analysis, Calculation, Assessment)
• {what to do} — specific instructions for the step
• {what format the result should take} — a list, table, number, text
• {your_task} — the task description

DC + Few-shot (3 examples)

You solve tasks through step-by-step decomposition. Here are examples:

=== EXAMPLE 1 ===
TASK: {example_task_1}

STEP 1 — {name}:
{how this step was solved in the example}

STEP 2 — {name}:
{how this step was solved in the example}

...

FINAL ANSWER: {result of example 1}

=== EXAMPLE 2 ===
TASK: {example_task_2}

STEP 1 — {name}:
{how this step was solved in the example}

...

FINAL ANSWER: {result of example 2}

=== EXAMPLE 3 ===
{same format}

=== YOUR TASK ===
TASK: {new_task}

Follow the same step structure. Work in order. After each step — an interim conclusion.

Placeholders:

• {example_task} — a similar task from your domain
• {how it was solved} — the concrete execution of the step, with data
• {result of example} — the example's final answer
• {new_task} — your actual task

🚀 Quick start — paste into the chat:

Here's a Divide-and-Conquer template with few-shot. Adapt it to my task: {your task}.
Ask me questions to fill in the fields and create 2-3 examples.

[paste the template above]

The LLM will ask:

• What key subtasks should your task be broken into?
• What result format do you need at each step?
• Can you provide 1-2 examples of similar tasks for few-shot?

It takes the decomposition pattern from the template and adapts it to your context — building the step structure and few-shot examples for your task.

DC + ReAct (with iterative checking)

Solve the task through step-by-step decomposition with self-checking:

STEP 1 — INITIAL SOLUTION:
{decomposition instructions, as in basic DC}

STEP 2 — CHECK:
Review the result of step 1:
- What are the potential errors or gaps?
- Do the connections between the parts make sense?
- Are there any contradictions?

STEP 3 — REFINE:
If you found problems in step 2, fix them. If everything is correct, move on to the final step.

STEP 4 — FINAL ANSWER:
{specific format of the final output}

Work through the steps in order. Show your reasoning at each step.

TASK: {your_task}

How it differs from basic DC: It adds an explicit checking step (the ReAct pattern: Act → Observe → Reflect → Refine). The model doesn't just solve — it reviews the solution and fixes mistakes.

DC + Verification (external critic)

This is a two-request process — first the solution, then the check.

Request 1 — Solution:

Solve the task through step-by-step decomposition:

{basic DC template from the first block}

TASK: {your_task}

Request 2 — Verification (in a new message):

You are a critic of the result. Review the solution above:

REVIEW CRITERIA:
- Completeness: are all aspects of the task covered?
- Logic: are there contradictions between steps?
- Accuracy: are the data and conclusions correct?
- Practicality: can the result be used in practice?

For each criterion:
1. Rating (✅ good / ⚠️ has issues / ❌ serious errors)
2. The specific problem (if any)
3. How to fix it (if needed)

Final verdict: ACCEPT / REVISE
If REVISE — provide a corrected version.

When to use: Critical tasks (business decisions, financial calculations, important texts) where mistakes are expensive. Verification adds +2-4% accuracy but doubles tokens and time.

⚠️ Not for every task: Simple questions ("What's the capital of Australia?") don't need decomposition. DC works for multi-step tasks where you need to connect several aspects or information sources. For simple tasks it adds needless complexity.

⚠️ Few-shot needs good examples: If the examples are bad (incomplete, wrong, off-topic), the model will copy the defects. Zero examples beat three bad ones. Good examples = the same steps, the same format, similar difficulty.

⚠️ Cost grows with the number of steps: DC with 5 steps + 3 few-shot examples = a lot of tokens. With GPT-4 that can be $0.10-0.30 per request instead of $0.02 for a simple prompt. Verification doubles the cost. Optimize: fewer steps for simple tasks, few-shot only where it's critical, Verification only for important results.

⚠️ Retrieval-enhanced methods can hurt: The study showed that if you filter information BEFORE giving it to the model (for example, keeping only the "relevant" columns in a database), the model can miss critical connections. Logic errors rose by 1.5-2% with the retrieval method. Better to give the model the full context and let it pick what it needs through DC than to trim the data up front.

⚠️ Latency grows nonlinearly: Complex tasks with DC + Verification take 2-5x longer than a simple prompt. For interactive scenarios (chatbots, live help) that's critical. If the user waits 20+ seconds, add a progress indicator or split the work into parts with interim results.

⚠️ Wrong answers take longer to generate: The study found a surprising effect — when the model gets it wrong, it spends 19.6% more time than on a correct answer. Translation: a long answer ≠ a good answer. If the model "thinks" for a very long time, it may be stuck going in the wrong direction. Add a timeout or an iteration limit to the ReAct loop.

A team from Bosch Research took 6 prompting strategies and tested them on 4 models: GPT-4o, o4-mini (reasoning), Gemini 1.5 Flash, Gemini 2.5 Flash. They used BIRD Mini-Dev — a benchmark of 500 Text2SQL tasks (translating natural-language questions into SQL queries against databases).

The logic of the experiment: Text2SQL is a good test bed for prompting strategies because the task is multi-step (understand the question → find the right tables → write the query → check the syntax) and objectively measurable (the query either runs and returns the right result, or it doesn't).

They compared 6 workflows:

1. Baseline (ReAct) — the basic "think → act → check → fix" loop
2. DC without few-shot — explicit decomposition instructions
3. DC + 3 few-shot — DC with three worked examples
4. Parallel Scaling — generating 5 candidates + voting
5. Verification — DC + a separate step critiquing the result
6. Retrieval-based — filtering the DB schema BEFORE generating the query

What they measured:

• Accuracy (Soft F1-Score) — how correct the result is
• Execution Error Rate — the share of syntax errors
• Latency — time to answer in seconds
• Token Count — how many tokens the method uses

Key findings:

1. DC + few-shot works for every model: Gemini 2.5 Flash: 65.75% → 68.12% (+2.37%) o4-mini: 56.27% → 65.53% (+9.26%) GPT-4o: 61.07% → 64.44% (+3.37%)

Even reasoning models (o-series, Gemini 2.5) improved. So a model's ability to "think" doesn't cancel out the benefit of explicit instructions for a specific task.

2. Verification beats the other complex methods: Verification added +0.5-1% accuracy for almost every model. Parallel Scaling gave mixed results (helped GPT-4o, hurt Gemini 2.5). Retrieval made results worse for every model — logic errors rose by 1.5-2%.

3. The base model matters more than the workflow: Gemini 2.5 Flash baseline (65.75%) beat GPT-4o's best workflow (64.95%). If the model is weak, even a sophisticated workflow won't save it. A strong model + simple DC beats a weak model + every technique in the book.

4. Complexity ≠ speed: Gemini Flash models: 5-14 seconds GPT-4o and o4-mini: 15-28 seconds

The retrieval method is the slowest — 33 seconds for GPT-4o, because it filters the data first and then generates. And it didn't pay off in accuracy.

A surprising insight: Wrong answers take 19.6% longer to generate than correct ones. That runs against intuition — you'd usually think "thinks for a long time = thorough = correct". In reality, when a model gets stuck going the wrong way, it can "spin" through faulty iterations. For production this means a long answer is no guarantee of quality — you need a timeout or an iteration limit.

Practical conclusion: Not every complex technique is worth the effort. DC + few-shot deliver 80% of the effect for 20% of the complexity. Verification is useful for critical tasks. Retrieval and Parallel Scaling depend on the context and the model. The most important thing is your choice of base model.

💡 Adaptation for writing articles:

DC works great for content production: structure → sections → final assembly.

Write an article about {topic} using decomposition:

STEP 1 — STRUCTURE:
Define:
- The target audience and their pain point
- The article's main thesis (1 sentence)
- 4-6 key blocks (a title + the gist of each in 1 sentence)
- The logical connection between blocks

STEP 2 — SECTIONS:
For each block from step 1, write:
- A subheading (a catchy one)
- The main content (2-4 paragraphs)
- Examples or data (concrete)
- A transition to the next block

STEP 3 — INTRO AND ENDING:
- Intro: a hook + a promise of value (2-3 paragraphs)
- Conclusion: a wrap-up + a call to action (2-3 paragraphs)

STEP 4 — ASSEMBLY AND POLISH:
Put everything together into one text. Check:
- Do the transitions make sense?
- Any repetition?
- Are the tone and style consistent?

Format: Markdown, no unnecessary formatting.

Why it works for articles: Writing is a classic multi-step task. Without structure the model can "lose the thread" halfway through, repeat itself or make an illogical jump. DC provides the skeleton, few-shot shows the style, and ReAct lets you polish.

💡 Adaptation for data analysis:

Analyze the dataset {name/description} using decomposition:

STEP 1 — RECON:
- How many rows and columns?
- What data types?
- Any missing values or outliers?

STEP 2 — PATTERNS:
- Correlations between columns (top 5)
- Anomalies and outliers (with explanations)
- Segmentation: natural groups in the data

STEP 3 — INSIGHTS:
Based on steps 1-2:
- The 3 main takeaways
- Which hypotheses are worth testing next?
- What additional data is needed?

STEP 4 — RECOMMENDATIONS:
Concrete actions based on the analysis.

Work through the steps in order. After each one — an interim result.

How it differs from a plain "analyze this": Without DC the model may jump straight to conclusions and skip the recon. Or start hunting for correlations without checking data quality. DC forces it to understand the data first, then look for patterns, then draw conclusions.

💡 Adaptation for debates and decisions:

Combine DC + Parallel + Verification for complex decisions that need several points of view.

Make a decision: {decision question}

STEP 1 — BREAK DOWN THE CRITERIA:
Define 3-5 key evaluation criteria:
- Criterion 1: {name} (weight: X%)
- Criterion 2: {name} (weight: Y%)
...

STEP 2 — PARALLEL REASONING:
Evaluate each option from three positions:

ROLE: Optimist
{evaluation against the criteria through rose-colored glasses}

ROLE: Pessimist
{evaluation against the criteria through the darkest lens}

ROLE: Realist
{a balanced evaluation against the criteria}

STEP 3 — CONSENSUS:
Compare the three evaluations:
- Where do all roles agree? (solid conclusions)
- Where do they diverge? (zones of uncertainty)
- Which criteria are the most contested?

STEP 4 — FINAL DECISION:
Based on the consensus, provide:
- A recommendation (a concrete action)
- Conditions under which to revisit it
- A Plan B in case the main plan fails

Work through the steps in order. Show all three roles in step 2.

The mechanics: Parallel reasoning via simulating three agents in a single request. The model doesn't just "analyze" — it plays three roles, which gives a three-dimensional view. The consensus separates solid vs contested conclusions.

🔧 Technique: An explicit counter → length control

From the CAPEL study (mentioned in the context of Text2SQL work): if you need precise length control (exactly N words, no more than M characters), add an explicit counter to the instructions.

Write a text of exactly 50 words about {topic}.

INSTRUCTIONS:
1. Write the text with numbered words: "1-word 2-word 3-word ..."
2. Stop at the 50th word
3. Output the clean text without numbers

Output format:
DRAFT: {text with numbers}
FINAL: {clean text}

Why it works: Models are bad at tracking length in the abstract ("about 50 words") but good at following concrete procedures ("count and stop"). The counter makes the task measurable at every step.

🔧 Technique: Faceless agents → characters

If you use a multi-agent prompt (as in parallel DC), replace faceless roles with specific characters.

❌ Weak:

ROLE: Critic
ROLE: Advocate

✅ Strong:

ROLE: Steve Jobs (product perfectionist, cuts everything unnecessary)
ROLE: William Zinsser (editor, sworn enemy of clutter and jargon, champions clarity)

Effect: The model plays the role more sharply when it has a specific archetype. "Critic" is a vague notion. "Jobs" is a distinct way of thinking. Models simulate well-known personalities better than abstract functions.

Where to find characters: Public figures with a distinctive style (entrepreneurs, media experts), pop-culture archetypes (characters from TV shows and movies), professional roles with well-known traits (surgeon vs general practitioner, startup founder vs corporate lifer).

Rethinking Agentic Workflows: Evaluating Inference-Based Test-Time Scaling Strategies in Text2SQL Tasks — the study compares 6 prompting strategies across 4 LLMs. It shows that Divide-and-Conquer + few-shot work even for reasoning models, while complex workflows don't always pay off.

Works referenced: DIN-SQL (Divide-and-Conquer for SQL), CHESS (retrieval-based reasoning), ReAct (Yao et al., 2023), Chain-of-Thought (Wei et al., 2022).

Authors: Jiajing Guo, Kenil Patel, Jorge Piazentin Ono, Wenbin He, Liu Ren Affiliation: Bosch Research North America, Bosch Center for Artificial Intelligence (BCAI)