Talking to Claude

Most people use Claude the way they used Google in 2005. They type a vague question, hit enter, and hope for magic. Then they get a generic answer, decide AI is overhyped, and go back to doing everything manually.

The problem isn’t Claude. The problem is how you’re talking to it.

I run a software engineering studio. Every day I use Claude for client emails, technical strategy, code review, contract analysis, hiring posts, product specs, and a dozen other things that used to eat hours of my time. The output is consistently excellent — not because I know some secret trick, but because I learned how to communicate with this thing properly.

The mental model: Claude is a brilliant new hire with amnesia

Forget the word “chatbot.” Here’s the analogy that works:

Claude is the most brilliant employee you’ve ever hired, with total amnesia at the start of every conversation.

This person is incredibly smart, well-read, and capable of doing excellent work across a huge range of tasks. But every morning, they walk in having forgotten everything. They don’t know who you are. They don’t know your company, your preferences, your projects, or what you asked them yesterday.

So you give them context. You explain the situation. You tell them what role they’re playing, what you need, and what good output looks like. The more specific you are, the better their work.

That’s prompting. That’s it.

The people who get amazing results aren’t using magic words. They’re giving clear context, specific instructions, and concrete examples — the same way you’d brief a smart human starting from zero. The people who get garbage results say “write me a marketing email” with no other context. Of course the output is generic.

How Claude works (the 60-second version)

You don’t need to understand transformer architecture to use Claude well. But knowing a few basics changes how you think about prompting.

Claude is a next-token predictor. Given everything in the conversation — your prompt, the history, any attached documents — Claude computes the most likely next word. It does this thousands of times per response. The model trained on so much text, with so many layers of reasoning, that the emergent behavior is remarkably intelligent. It can follow complex instructions, maintain coherent arguments across pages, write code, and catch logical errors — all through this mechanism.

The context window is Claude’s working memory. Everything in your current conversation lives in a single window. Every message, every response, every uploaded file. Current models offer up to 200K tokens (roughly 150,000 words) for standard usage and up to 1 million tokens on paid plans. When it fills up, older context starts getting compressed or lost.

Claude has no memory between conversations unless you use Projects or Memory. Each new chat starts from zero.

The model’s knowledge has a cutoff date. It doesn’t know what happened after that unless you tell it or it uses web search.

Which Claude to use

Three main models as of April 2026:

Opus 4.7 — the flagship. Best reasoning, best writing, best at complex multi-step tasks. Use for strategy documents, contract analysis, code architecture, anything requiring deep thinking. Slower and pricier, but the quality gap is real.

Sonnet 4.6 — the workhorse. Fast, capable, significantly cheaper. Handles 80% of everyday tasks well: emails, code, summaries, data analysis.

Haiku 4.5 — the speedster. Fastest and cheapest. Best for simple tasks and high-volume API workflows.

My rule: start with Sonnet. Switch to Opus when the task is complex or high-stakes. Use Haiku for automated workflows where speed matters more than nuance.

Be clear, direct, and specific

This is the most important idea in this chapter. Everything else refines it.

The clearer your prompt, the better Claude’s output.

Anthropic’s own documentation calls this the “Golden Rule” of prompting: Show your prompt to a colleague with minimal context and ask them to follow it. If they’re confused, Claude will be too.

A vague prompt like “write me a marketing email about our new feature” gives Claude nothing to work with. What feature? For what audience? What tone? How long?

A specific prompt names the feature, describes the audience, sets the tone, specifies the CTA, and defines the length. Same task, completely different output quality. The difference isn’t that the specific prompt is longer — it’s that it gives Claude the context it needs to do excellent work.

Tell Claude what TO do, not what NOT to do. “Write in flowing paragraphs” works better than “don’t use bullet points.” Positive framing gives the model a clear target. Negative framing just eliminates options without pointing anywhere.

XML tags: Claude’s structure superpower

Claude was specifically trained to understand XML-style tags, and using them to organize your prompt dramatically improves how well it follows instructions.

The idea is simple: wrap different sections of your prompt in descriptive tags so Claude can parse what’s what. Separate your role, context, documents, instructions, and output format into labeled sections. The tags act like labeled file folders — Claude can reach into exactly the right section when it needs context.

You can name tags anything you want. There are no “official” names. Use whatever makes sense: <background>, <rules>, <examples>, <task>. Just be consistent. Nesting works too.

Role prompting: tell Claude who it is

Assigning Claude a specific role focuses the model’s attention and shapes the style, depth, and perspective of its response. The knowledge is already there — the role directs how it’s applied.

“You are a senior litigation attorney specializing in SaaS vendor agreements” produces fundamentally different output than “You are a helpful assistant.” The specificity matters. A generic “expert” does almost nothing. A specific “fractional CFO for Series A startups with 20-50 employees, experienced in SaaS metrics and board reporting” produces output shaped for exactly your situation.

When I use Claude for client communication, I set the role to something like: “Direct, professional communicator who writes concise business emails. No corporate filler, no parallel constructions. Short sentences. Warm but not flowery.” This alone saves me from rewriting every draft.

Show, don’t tell: the power of examples

If there’s one technique more effective than people expect, it’s giving Claude examples of what good output looks like.

You could spend 500 words describing the exact tone, format, and content you want. Or you could show three examples and say “like this.” The examples communicate more precisely, in less space, with less ambiguity.

Anthropic recommends 3-5 examples for most tasks. Three rules for good examples: make them relevant to your actual use case, make them diverse so Claude generalizes rather than pattern-matching, and show both input and output.

Chain of thought and extended thinking

For complex reasoning — “Should we migrate our PHP codebase to Laravel or rewrite in React?” — you want Claude to think through the problem step by step before answering.

Chain of thought is simple: ask Claude to reason through the problem. “Think step by step” works. Better: specify the reasoning steps. Best: separate thinking from output using tags.

Extended thinking is a model feature where Claude allocates dedicated reasoning tokens before writing its visible response. Think of it as Claude going into a back room to think before coming out with an answer. When it’s active, you’ll see a “thinking” indicator.

A counterintuitive tip from Anthropic: when using extended thinking, prefer general instructions like “think deeply about this” over prescriptive step-by-step guidance. The model’s own search strategy often exceeds what you would script manually.

Projects: your persistent workspace

Projects are where Claude goes from a one-off conversation tool to a persistent work environment. A Project includes Knowledge (files Claude can reference in every conversation), Instructions (behavioral rules that apply to every conversation), and separate memory per project.

Every active client of mine gets a Project. I upload the contract, codebase docs, team roster, and past invoices. The Instructions tell Claude my role, the client context, and my output style. When I open a conversation, Claude already knows who the client is and how I write. No more re-explaining context in every chat.

Memory, Styles, and Preferences

Memory lets Claude remember facts between conversations — your name, your role, your preferences, ongoing projects. It’s scoped per Project, can be edited or deleted, and works as a helpful aide-mémoire (not a reliable database).

User Preferences apply account-wide: behavioral rules and formatting preferences that load on every conversation.

Custom Styles control tone and formatting at a granular level. You can switch between styles depending on the task.

Multi-turn conversation strategy

Claude re-reads the entire conversation on every turn. This has practical implications.

Front-load stable context. Put reference documents and persistent rules in the first message or in Project Knowledge. They’ll be processed on every turn regardless.

Put your current task at the end. Anthropic’s testing shows a 30% quality improvement when long documents are placed at the top and the query at the bottom.

Start new conversations when you switch topics. A database migration conversation that pivots into marketing copy carries all that irrelevant context as dead weight.

Restart when Claude gets stuck. If Claude is confidently wrong and won’t course-correct, the “wrong” answer is baked into the context. A fresh start with a clearer prompt usually solves it.

Document analysis done right

When Claude analyzes a document, there’s a pattern that dramatically reduces hallucination.

The evidence-first pattern: Ask Claude to first extract the relevant quotes from the document, then answer using only those quotes. This forces Claude to ground its analysis in actual text rather than generating plausible-sounding interpretations.

For multiple documents, label each one with an index. Put all documents at the top, your question at the bottom.

Give Claude permission to say “I don’t know.” One line like “If the answer isn’t clearly supported by the documents, say so rather than guessing” dramatically reduces hallucination. I learned this after Claude confidently told me a contract had a 90-day termination clause when the actual clause said 30 days.

Context engineering: the graduation point

Anthropic describes a discipline they call “context engineering,” and it reframes the whole conversation.

Prompt engineering is about crafting the words you send to Claude. Context engineering is about crafting the entire environment: the prompt, the system instructions, the reference documents, the examples, the tools, the memory, the conversation history. All of it competes for Claude’s attention. More context isn’t automatically better. The right context, structured well, is what matters.

This is why Projects with curated Knowledge bases outperform copy-pasting documents into every conversation. Why 3 great examples beat 15 mediocre ones. Why a specific role definition beats a vague one.

The question graduates from “What should I write in my prompt?” to “What’s the minimum configuration of context, tools, and memory that reliably produces the outcome I want?”

What not to do

Common failure modes, all sharing a theme: they make Claude guess.

Vague instructions. “Write something about our product” gives Claude nothing to aim at.

Conflicting instructions. “Be concise but thorough” forces arbitrary tradeoffs. Pick a direction. If you need both, specify where each applies.

Stacking negatives. “Don’t use jargon. Don’t be too long.” Reframe as positives: “Use plain language. Keep it under 300 words.”

Treating Claude like a search engine. “Laravel migration best practices” ignores Claude’s reasoning capability. Give it your specific situation instead.

Repeating a failing prompt. If Claude gives bad output, diagnose why — don’t resend the same prompt.

The debugging ladder

When Claude gives bad output, run through this in order:

1. Is the role specific enough?
2. Is the task unambiguous?
3. Are there examples?
4. Is the format specified?
5. Is the prompt order right — context at top, task at bottom?
6. Did you enable thinking for a reasoning task?
7. Is there conflicting context from earlier in the conversation?

If none of those fix it, paste your prompt into Claude and ask: “What’s ambiguous or underspecified about this prompt?” Claude’s self-diagnosis is often startlingly accurate.

The bottom line

Claude is not a search engine and it’s not a chatbot. It’s a reasoning engine that responds to structure, specificity, and examples — the same way a brilliant human responds to a clear brief.

Set up one Project properly. Write one well-structured prompt. See the difference in output quality compared to your usual approach. That moment — when you see what Claude can produce when given proper context — is when it clicks.

Everything after that is refinement. And refinement, applied to enough of your workflows, is how you start to aify.

---

This is the free web edition of Chapter 1. The full text — with worked examples, prompt templates, XML tag patterns, and real-world walkthroughs — is available in 42: The AI Builder’s Stack, coming Q3 2026 on Amazon in hardcover, paperback, and digital.