Stop treating Claude like a fancy Google

The first mistake is subtle. You open Claude, type a fuzzy question, skim the answer, and move on. That is a search engine workflow. The model happily plays along because it is trained to be helpful on almost anything you throw at it. Claude can do that, but it is like using a race car to pick up dry cleaning: technically allowed, and a waste of what you paid for.

This post is about a single shift: moving from "ask the internet" to "assign work to a collaborator." Once that clicks, quality jumps, frustration drops, and you stop blaming the model for answers that were never scoped as engineering work in the first place.

Why the Google habit sticks

Search rewarded vague queries. You type a few keywords, scan ten blue links, patch together an answer, forget the journey. There is no memory, no repo, no definition of done.

Claude looks like a chat box, so your brain reuses the old pattern. The difference is that Claude can iterate, hold context in a thread, reason about your constraints, and (with Claude Code) touch real files. If you never give it constraints or a deliverable, you get a very eloquent search snippet.

Give it a job, not a vibe

Weak prompts sound like moods: "any tips on React?" Strong prompts sound like tickets.

Try the same idea reframed:

• Bad: any tips on React?
• Better: I am building a one-page email signup in Next.js App Router and Tailwind. I want accessible labels, inline errors, and a disabled submit until the email regex passes. List three patterns I should use, then show a minimal component sketch.

Same model. Totally different outcome, because you forced scope, stack, and acceptance criteria into the request.

Ask for tradeoffs, not fortune cookies

If you want durable decisions, make the model disagree with itself a little.

Example prompts that work:

• "Compare two approaches for caching this read-heavy route in Next.js: tag revalidate vs short revalidate seconds. Tradeoffs for a site with under 10k daily visitors."
• "I am choosing between Zod-only validation vs mixing Zod with form libraries. What breaks first at scale?"

You are not asking for a horoscope. You are asking for options with failure modes. That is how senior engineers talk.

Close the loop: iteration beats one-shots

The magic is iteration. Read the answer, run the code, paste the stack trace, say what you changed, ask for the smallest fix. One-shot prompts are where beginners stall and pros get bored, because the first draft is never where the truth lives.

A simple loop you can repeat forever:

1. Do the smallest runnable step from the reply.
2. Observe what broke or what surprised you.
3. Paste the error or behavior in plain language.
4. Ask for the next smallest change.

That is pair programming. The chat is the IDE sidebar, not a replacement for running the project.

Red flags in your own prompts

If you notice these, rewrite before you send:

• You could paste the same prompt into Google and get "good enough."
• You never named your framework, hosting, or data layer.
• You never said what "done" looks like in one sentence.
• You are asking for "best practices" without a real bottleneck.

Your homework for the next session

Pick one real task you were going to ask vaguely. Rewrite it with: goal, stack, constraints, definition of done, what you already tried. Send it once, iterate twice. Measure the difference in how actionable the answers feel.

If you only take one line from this: treat Claude like a senior engineer in your repo, not a magic paragraph generator. Your next hour will feel completely different.