How to prompt LLM coding agents for more reliable results

thijs · September 2, 2026, 12:17am

Based on contributions by thijs.

LLM coding agents (like Claude Code, Copilot, or Cursor) often produce better or worse code purely based on how you prompt them. This guide gives practical rules of thumb for getting reliable results, based on the idea that these models work like a “20 Questions” process: each piece of evidence you give narrows down what a correct answer looks like.

Check: the mental model below (“attention as Bayesian inference”) is one specific theoretical framing, based on the papers linked at the end. Treat the practical advice as generally useful prompting habits; treat the underlying “geometry” explanation as one hypothesis about why they work, not settled fact.

What you need

Access to an LLM coding agent (Claude Code, GitHub Copilot, Cursor, etc.).
No special setup — these are prompting habits, not a specific tool configuration.

The mental model: 20 questions

When you send a prompt, an LLM coding agent effectively:

Starts with a wide space of possible interpretations of your request.
Eliminates interpretations that don’t fit your prompt as it processes it.
Produces an answer based on whatever interpretations are left.

In-context learning, few-shot examples, and chain-of-thought prompting are all versions of the same thing: giving the model evidence that eliminates wrong interpretations faster.

Steps: six practices for more reliable output

1. Give evidence that eliminates, not evidence that repeats

Each example you provide should rule out a category of wrong interpretation.

Use diverse examples that span the range of what you want, not near-duplicates of each other.
A few varied, high-quality examples beat many similar ones.
Examples of edge cases help more than examples of the “obvious” middle case.

2. Break complex tasks into steps

An LLM coding agent has a fixed amount of processing per response. A task that’s too complex to solve in one pass increases the chance of a confident-but-wrong answer (a hallucination).

Ask the agent to “think step by step” on non-trivial problems.
Split a big problem into sub-problems the agent can solve with high confidence individually.
Let it show intermediate reasoning rather than jumping straight to a final answer.

3. Keep each prompt domain-focused

Mixing unrelated types of work in one prompt (e.g. “write the spec, design the architecture, implement it, and write tests” all at once) tends to produce weaker results than doing them one at a time — even within “writing code”, tasks like planning, architecture, implementation, and debugging behave differently.

Prefer spec → architecture → implementation → tests as separate, sequential requests over one sprawling request.
A single prompt with several steps is fine when the steps are tightly coupled; separate prompts work better when tasks are complex or cross sub-domains.
For agentic tools like Claude Code, the execute → observe → decide loop gives some natural separation already, but you still get cleaner results from explicit phases on complex features: “first write a spec for X”, then “now implement it”.
Iterate between prompts, not within one: "Write a spec for X" → "Implement it" → "This broke because Y, revise the spec" → "Re-implement".

Working with existing code: when adding to an established codebase, ask for a tactical change rather than a rewrite. The existing code is itself useful context — it shows the agent what conventions and patterns to follow. A typical workflow:

Update the spec (for your own understanding).
Show the agent the relevant existing code as context.
Ask for a specific, tactical change: “Given this spec and this code, add feature X.”

Reach for a full re-implementation only when the architecture is genuinely wrong, existing cruft makes changes harder than starting over, or the codebase is small enough that a rewrite is cheap.

4. Provide rich context upfront

More explicit constraints and context generally produce more reliable output.

State constraints and requirements explicitly rather than assuming they’re obvious.
Give examples that bound the expected behavior.
Avoid vague requests that leave many valid interpretations open.

5. If the agent is hallucinating, decompose further

If you’re getting confident-sounding but wrong answers:

Break the task into more, smaller steps.
Add clearer constraints.
Add an explicit verification step: “double-check by…”.

6. Let the agent ask questions

Tools like Claude Code can ask clarifying questions before committing to an approach (e.g. via AskUserQuestion). Encourage this rather than forcing the agent to guess.

Let the agent ask clarifying questions instead of demanding an immediate answer.
Answer its questions — each answer removes ambiguity.
If it isn’t asking when it probably should, prompt it explicitly: “ask me if anything is unclear.”

Quick reference

Situation	What to do
The task is complex	Break it into steps, or ask for step-by-step reasoning
You’re mixing several types of work in one prompt	Split into separate, focused requests
The agent seems to be guessing	Add examples, constraints, and context
The agent is producing confident-but-wrong output	Decompose further, add a verification step
The agent is guessing instead of asking	Explicitly invite clarifying questions

Going deeper: why this works (optional)

This section explains the underlying idea from the source papers below; skip it if the practical advice above is all you need.

LLMs represent text internally as vectors in a high-dimensional space. The cited papers report that these internal vectors don’t scatter randomly — they organize along structures that resemble Bayesian inference: an internal “confidence” axis where more evidence (context, examples, constraints) moves the model’s internal state toward a more certain, more reliable region, and vague prompts leave it in a more uncertain region.

Under this framing:

Chain-of-thought works because each reasoning token is another full pass through the model — more opportunities to narrow down the answer before committing to one, rather than jumping to a conclusion in one step.
Mixed-domain prompts may create interference if different kinds of tasks (planning vs. implementing vs. debugging) engage different internal “tracks” that don’t combine cleanly.
Hallucinations correspond to reaching a final answer with too much uncertainty left — the model has to commit to something even though multiple interpretations were still plausible.
Clarifying questions are the model recognizing it’s in a high-uncertainty region and requesting more evidence before committing, instead of guessing.

This is one interpretation of the papers listed under Source papers below, translated into prompting advice. Treat it as a useful mental model, not a verified mechanism.

Project template

To make an LLM coding agent like Claude Code follow these practices automatically, add this to your project’s .claude/CLAUDE.md file:

## Working style

You are working with a coding agent that gets more reliable with more evidence. When uncertain, gather more evidence before committing to an approach.

### Ask before guessing

When requirements are ambiguous or the approach is uncertain:
- Use `AskUserQuestion` to clarify before implementing.
- Don't guess at requirements — each clarification removes a wrong interpretation.
- One good clarifying question beats implementing the wrong thing.

### Phase separation for complex tasks

For non-trivial features, propose phases before diving in:
1. Spec/requirements (what)
2. Architecture/design (how, broadly)
3. Implementation (how, concretely)
4. Tests/verification (did it work)

Ask: "Should I start with a spec for this, or jump straight into implementation?"
Complete one phase before starting the next; iterate between phases, not within one.

### Use existing code as evidence

Before modifying code:
- Read the relevant existing files first.
- Follow established patterns and conventions.
- Prefer a tactical change over a rewrite.

### One domain at a time

- While writing a spec, don't start implementing mid-spec.
- While implementing, don't drift into refactoring unrelated code.
- While debugging, focus on the specific issue before suggesting other improvements.

### When facing complexity

If a task feels too complex to get right in one pass:
- Break it into smaller sub-tasks.
- Propose the breakdown before starting.
- Complete each sub-task before moving to the next.

### Iteration protocol

After completing a phase or an implementation:
1. Summarize what was done.
2. Ask whether it meets the requirements.
3. If not, gather specific feedback on what's wrong.
4. Revise based on that feedback.

### Anti-patterns to avoid

- Guessing at ambiguous requirements instead of asking.
- Mixing spec and implementation in one pass.
- Ignoring existing code patterns.
- One giant implementation instead of verifiable steps.
- Rewriting when a tactical change would work.

Source papers

This mental model is derived from a set of papers proposing that transformer attention implements Bayesian inference:

Authors: Naman Agarwal (Google DeepMind), Siddhartha R. Dalal (Columbia), Vishal Misra (Columbia).