The same words describe three quite different activities. Knowing which one you mean tells you what to do.

Meaning one: steering Claude inside a conversation

This is the everyday kind. You read Claude’s answer and reply with what to change: shorter, warmer, more detail on step three, a different structure. The feedback goes straight into the conversation, and Claude uses it to produce a better next answer. This is the most important skill, and most of this guide is about it.

Meaning two: telling Anthropic about your experience

Claude apps usually include simple controls, such as thumbs-up and thumbs-down buttons, that let you rate a response and share comments with the company. This kind of feedback is a message to the people who build and improve the product. It is not a command to Claude in the current chat.

Meaning three: helping other people give better feedback

Many people also use Claude as a helper when they need to give feedback to others, such as a colleague, a student or a teammate. Claude can help structure comments so they are clear, kind and useful. We cover this near the end.

A bonus: asking Claude to give feedback to you

You can also reverse the direction and ask Claude to critique your writing, plan, code or ideas. Getting honest, useful critique from an assistant takes some care, and we will see how.

Understanding what happens behind the scenes helps you set the right expectations.

Claude is a large language model, often shortened to LLM. It is a computer program that learned patterns of language from a huge amount of text, and it writes each reply fresh, one small piece at a time, based on everything visible in the current conversation. That everything is called the context.

An important point: chat feedback is not retraining

When you correct Claude in a conversation, the correction helps that conversation. It does not rewrite the underlying model. The model itself is built and improved by Anthropic through a separate process, and your single chat does not change it. This is why a correction you give today may not appear automatically in a brand-new chat tomorrow, unless you use a feature that saves your preferences. We will look at those later.

One picture of the whole cycle, so you know what to do at each point.

The diagram below shows a healthy feedback loop. Notice that the human is at the centre of it. Claude produces drafts, but you judge them against your real goal, and your judgement decides the next step.

flowchart TD
    A["State your goal, audience and format"] --> B["Claude produces a first answer"]
    B --> C["You compare the answer with your goal"]
    C --> D{"Good enough?"}
    D -- "Yes" --> E["Use it and verify facts"]
    D -- "Partly" --> F["Say what to keep and what to change"]
    D -- "No" --> G["Restate the goal or add missing context"]
    F --> H["Claude revises"]
    G --> H
    H --> C
    E --> I{"Same fix needed often?"}
    I -- "Yes" --> J["Save it as a standing preference or instruction"]
    I -- "No" --> K["Done"]
    

Reading the diagram step by step

Start with a clear goal. The better your first request, the less correction you need later.

Compare, do not just react. Check the answer against what you really wanted. This stops you from changing things that were already fine.

Choose the right kind of response. If the answer is partly right, say what to keep and what to change. If it is far off, the problem is usually missing context, so restate the goal rather than patching details.

Verify before you rely on it. Even a polished answer needs fact-checking when accuracy matters.

Notice patterns. If you keep giving the same correction, such as “shorter please”, save it as a standing preference so that you do not repeat yourself.

Strong feedback has a simple shape. Learn it once and use it everywhere.

Imagine telling a tailor, “This jacket is bad.” The tailor cannot fix anything with that. Now imagine saying, “The sleeves are too long by two centimetres, and I like the colour.” Now the tailor knows exactly what to adjust and what to leave alone. Feedback to Claude works the same way. Good feedback has four parts.

A before-and-after example

Weak feedback: “This is not what I wanted. Try again.” Claude must guess what was wrong and may change everything, including the parts that were fine.

Strong feedback: “The opening paragraph is good, so keep it. The middle section is too technical for a beginner audience, so explain the two terms in plain words and add one everyday example. Also cut the conclusion to two sentences.” Every instruction can be followed, and nothing good is lost.

Most corrections fall into a few families. Knowing the family helps you phrase it quickly.

Small changes in wording make a big difference to the result.

Words that help

• “Keep”: protects the parts you like.
• “Only”: limits the scope, as in “only change the second paragraph”.
• “Because”: gives a reason that Claude can reason from.
• “Instead of… use…”: swaps one choice for another clearly.
• “Before you rewrite, tell me what you plan to change”: lets you approve the plan first.

Sometimes the problem is not style but substance. Here is how to handle errors well.

When Claude gets a fact wrong

Language models can produce a hallucination, which is a confident statement that is not true, such as a wrong date, an invented reference or a function that does not exist. Anthropic trains Claude to be honest and to admit uncertainty, but errors can still happen. When you spot one, say exactly what looks wrong and, if you know it, what the correct information is.

A good pattern is: “In paragraph two you said the event happened in 1998. I believe it was 2001. Please check and correct it, and tell me how confident you are.” This gives Claude a precise target and invites an honest answer about certainty.

When you disagree and Claude is right

You are not always right, and Claude is not always wrong. If you push back with a mistaken claim, a well-behaved assistant should explain its reasoning politely instead of simply giving in. Anthropic has said it wants Claude to be honest even when that is not what the user hopes to hear. Treat this as helpful. If Claude holds its position, ask for the reasoning and the evidence, then check them yourself.

When you disagree and Claude is wrong

Give your reasons, not just your conclusion. “I think that is incorrect” is weaker than “The official documentation for this tool says the setting is off by default, so your step two would not work. Can you re-check?” Reasons give Claude something to reconsider.

Watch out for agreeable answers

Assistants can lean toward agreeing with the person they talk to, a habit called sycophancy. If you push back hard, you may sometimes get a quick change of answer that is polite rather than correct. To protect yourself, ask neutral questions after a correction, such as “Please re-check this independently and explain which version is right and why.” Do not treat a changed answer as proof that the new answer is true.

Real work takes several rounds. These habits keep each round productive.

Feedback on code

When you work on software with Claude, good feedback is especially valuable. Include the exact error message, what you expected to happen, what actually happened and the relevant part of your setup. “It does not work” gives almost nothing. “The program stops at the login step and shows this message, and I expected it to open the dashboard” gives a lot. Report what you changed since the last working version, and say which tools and versions you use.

Feedback on plans and ideas

For strategy and planning, feedback often takes the form of constraints that Claude did not know: budget, team size, deadlines, legal limits or past attempts. “That plan assumes three engineers, but I have one. Re-plan with one engineer and a six-week limit.” Each new fact reshapes the answer.

Sometimes the fastest way to explain what you want is to show it.

Words can be slippery. “Professional but friendly” means different things to different people. An example removes the ambiguity. Paste a sample of the style you like, and say: “Match this style and length.” You can also show what you do not want. A good example and a bad example together teach more than a paragraph of description.

Useful ways to use examples

• Style samples: paste something you wrote or admire and ask Claude to follow its rhythm and tone, with your own content.
• Format templates: paste a layout you want, such as a report skeleton or an email structure, and ask Claude to fill it in.
• Before and after pairs: show a rough sentence and your improved version, and ask Claude to apply the same kind of improvement to the rest.
• Negative examples: say “avoid phrases like this one” and paste the sentence that annoyed you.

If you keep repeating the same correction, you are doing unnecessary work.

Because a correction inside one chat does not automatically carry into new chats, repeated feedback can become tiring. Typical examples are “keep answers short”, “use simple English”, “do not use bullet points” and “always show the reasoning”. Claude products often provide ways to record such standing preferences so that they apply more widely, for example through settings for personal preferences or through memory features that you can switch on or off. The names and exact behaviour of these features can differ between products and can change, so check the app and the official help centre at support.claude.com for the current options.

What makes a good standing preference

• Specific: “Explain technical terms in one sentence the first time they appear” is better than “be clear”.
• Stable: choose things that are true for most of your work, not just one project.
• Short: a few clear lines work better than a long essay.
• Honest: ask for style, format and tone. Do not ask for flattery or for the assistant to hide problems, because that defeats the purpose of getting useful help.

Keep your own style sheet

Another reliable approach is to keep a short document with your preferences: tone, length, spelling style, key terms and things to avoid. Paste it at the start of important conversations. It works in any product, it stays under your control, and you can improve it over time.

A different kind of feedback, aimed at the people who build the product rather than at the current chat.

Claude apps typically include rating controls on responses, such as thumbs-up and thumbs-down buttons. Using them tells Anthropic that an answer was helpful or that it was not, and the thumbs-down option is a way to flag problems. This feedback is separate from the conversation. It does not change that particular chat, and it is not a replacement for telling Claude directly what to fix.

The diagram below shows where different kinds of feedback should go. Choosing the right route gets your message to the right place and gets you the right result.

flowchart TD
    A["You notice a problem or a success"] --> B{"What do you want to happen?"}
    B -- "Fix this answer now" --> C["Reply in the chat with specific feedback"]
    B -- "Tell the product team about quality" --> D["Use thumbs up or thumbs down on the response"]
    B -- "Report a wrong, unsafe or harmful output" --> E["Use thumbs down and add a clear comment"]
    B -- "Account, billing or access problem" --> F["Contact support through the help centre"]
    B -- "Remember my preference next time" --> G["Save a standing preference or style sheet"]
    C --> H["Better answer in this chat"]
    D --> I["Signal to improve future versions"]
    E --> I
    F --> J["Support helps with your account"]
    G --> K["Fewer repeated corrections"]
    

Reading the diagram step by step

To fix this answer now, reply inside the chat. That is the only route that changes the current conversation.

To tell the product team about quality, use the rating buttons. A thumbs-up on a particularly good answer is useful information too, not only complaints.

To report a serious problem, such as a harmful, deceptive or clearly wrong output, use the thumbs-down control and add a short, clear comment about what happened.

For account or billing problems, rating buttons are the wrong tool. Use the support channels described in the official help centre.

To avoid repeating yourself, record a standing preference or keep your own style sheet.

What happens to this feedback?

Companies typically review feedback to find problems and improve their products. How Anthropic handles feedback, what it may include and how it relates to your privacy settings are described in its official policies and help pages. Read them if you care about the details, because they can change. A good starting point is support.claude.com.

When you do send feedback to the product team, a few clear sentences are far more useful than a single word.

People who read feedback may see a great many comments. A clear, specific comment is easier to understand and act on. Use this simple pattern.

Kinds of problems worth reporting

• Wrong or invented information presented with confidence.
• Unsafe or harmful output that should not have been produced.
• Needless refusals, where a reasonable, harmless request was declined. This is sometimes called over-refusal.
• Biased or unfair answers, such as stereotypes.
• Technical glitches, such as broken formatting or features that fail.

And praise helps too

If an answer was especially clear, helpful or handled a hard request well, a thumbs-up tells the team what works. Balanced feedback gives a truer picture than complaints alone.

Feedback can contain more than you expect. Think before you send.

When you rate a response or write a comment, the feedback may be connected to the conversation that prompted it. That conversation might contain personal details, business information or other sensitive material. Before sending detailed feedback, think about what is in the chat and what you are comfortable sharing.

• Keep comments free of sensitive details. Describe the problem in general terms instead of quoting private data.
• Never include passwords, keys or financial account numbers in any chat or comment.
• Protect other people. Avoid names, contact details and private facts about colleagues, customers or family members.
• Respect your organisation’s rules. If you use Claude for work, check your company policy before reporting examples that contain business information.
• Review the official policies. How feedback is handled can change, so read the current privacy information on the official site and help centre.

The direction reverses. Now you want Claude’s honest opinion, and you need to ask in a way that earns it.

Claude can review essays, resumes, business plans, designs described in words, code and more. The difficulty is that a friendly assistant may be too gentle. If you ask “is this good?”, you may receive mostly praise. To get a useful critique, make your request specific and invite honesty.

How to ask for useful critique

• Name the purpose and audience. “This is a cover letter for a project manager role. Who will read it and what will they look for?”
• Ask for weaknesses first. “List the five weakest parts, ordered by importance.”
• Request a role. “Review this like a strict but fair editor”, or “Read this as a skeptical hiring manager.”
• Provide criteria. If you have a rubric, such as grading standards or company guidelines, paste it and ask Claude to score against it.
• Separate levels. Ask separately about big-picture structure, then sentence-level wording, then grammar, so that comments do not get mixed.
• Ask for evidence. “Point to the exact sentences that support each criticism.”
• Ask what to fix first. A ranked list of priorities keeps you from drowning in minor points.

How to read the critique

Treat feedback from Claude as input, not as a verdict. It reflects general patterns and the information you provided. It may miss context that only you know, such as your audience’s real expectations or your company’s culture. Check suggestions against your goals, and accept the ones that help.

Giving feedback to a colleague, student or friend is hard. Claude can help you phrase it well, while the judgement and the relationship remain yours.

Many people struggle to give feedback that is honest and kind at the same time. Too soft and the message is lost. Too harsh and the person becomes defensive. Claude can help you find clearer wording, but it only knows what you tell it, so the facts must come from you.

A simple structure: Situation, Behaviour, Impact

A widely used framework is called Situation, Behaviour, Impact, often shortened to SBI. First describe the situation, which is when and where it happened. Then describe the behaviour, meaning what you actually saw or heard, without judging the person’s character. Finally describe the impact, meaning the effect it had on you, the team or the work. For example: “In yesterday’s client meeting, you interrupted Priya twice while she was presenting. She lost her train of thought, and the client seemed unsure about our readiness.”

How Claude can help

• Organise your thoughts. Paste rough notes and ask for a clear structure with the situation, behaviour and impact separated.
• Soften without hiding the point. Ask for a version that is respectful and direct, with no vague hints.
• Prepare for the reaction. Ask what questions or objections the person might raise, and how you could respond calmly.
• Balance the message. Ask for suggestions on mentioning real strengths alongside the concern, without making the feedback sound false.
• Rehearse. Ask Claude to play the other person so that you can practise the conversation.

Feedback is powerful, but it is not magic. Here is a balanced view.

The central trade-offs

• Precision versus speed: detailed feedback takes longer to write but saves rounds. Quick feedback is fine for small tweaks.
• One long message versus several short ones: a single message with many changes is efficient, but many small steps are easier to check.
• Correcting versus restarting: patching a bad answer can cost more than restating the goal in a fresh chat.
• Agreement versus honesty: a pleasing answer feels good, but a useful one sometimes disagrees with you.

Eight habits that turn feedback from a chore into a superpower.

An anti-pattern is a habit that feels natural but gets worse results.

Myths worth clearing up

• “Claude learns permanently from every chat correction.” A correction helps within that conversation. Lasting changes to the underlying model come from Anthropic’s own development process.
• “If Claude changes its answer, it must have been wrong.” It might have been wrong, or it might have been too eager to agree. Verify.
• “Polite feedback is weak feedback.” Politeness does not reduce clarity. Clear and courteous works well.
• “Rating a response also rewrites it.” Rating controls send a signal to the product team and do not edit your chat.

Quick, clear answers to common questions.

Feedback is the steering wheel of every conversation with Claude. A first answer is only a starting point, and a few precise sentences from you can turn it into something truly useful. Beyond the chat, feedback also flows to the people who build the product, and it can flow outward again when you ask Claude to review your work or help you support others. Each route has its own purpose, and choosing the right one saves time and frustration.