How To Use Claude Like a Senior Engineer, Not a Chatbot

Most people type into Claude like it’s a search box. Senior engineers treat it like a junior teammate with root access powerful, fast, and dangerous if you don’t set the rules.

Suggested Medium tags: Claude, AI, Software Engineering, Claude Code, Developer Tools
Cover image idea: A terminal window on the left with a Claude session running, and a calm senior engineer reviewing a diff on the right. Caption: “Delegate, then verify.”

There are two ways to use Claude.

The first is the way most people use it:

“Write me a function that does X.”

Copy.

Paste.

Hope it compiles.

The second is the way experienced engineers use it: as an agent that can read the repo, plan the work, run commands, edit files, and hand you a reviewable diff

while you stay in control of what actually ships.

The gap between those two workflows is enormous.

And in 2026, the tooling around Claude has moved so fast that the “chatbot” mental model is now the main thing holding people back.

This is a practical guide to the second way.

No hype, no “AI will replace developers” takes just how to actually get senior-level output from Claude today.

Inside BUZZ, Block’s Open-Source Workspace for Humans and AI
Jack Dorsey’s latest app -> Most people run AI agents the same way: one chat window, one agent, one task at a time.

Step 1: Know which Claude you’re actually talking to

Before technique, get the model right.

Using the wrong tier is the most common way people waste time and money.

As of mid-2026, the lineup you care about is:

• Claude Sonnet 5 → the default for Free and Pro, with a native 1M-token context window and strong agentic coding at Sonnet pricing. It launched at introductory pricing of $2 per million input tokens and $10 per million output tokens through August 31, 2026, then $3/$15. This is your daily driver.
• Claude Opus 5 → the recommended model for hard agentic coding and enterprise work, with high reasoning effort on by default and an xhigh tier for the nastiest problems.
• Claude Haiku 4.5 → the fast, cheap tier for high-volume, latency-sensitive tasks like classification or simple transforms.
• Claude Fable 5 (Mythos-class) → a tier above Opus for the hardest, longest-horizon reasoning, priced at roughly double Opus. Most teams do not need it.

The practical rule:

Sonnet 5 for most work. Opus 5 when a task is genuinely hard or long-horizon. Haiku for cheap, high-volume calls.

One gotcha worth knowing: Sonnet 5 and Opus 4.7+ use an updated tokenizer, so the same text can map to roughly 1.0–1.35× more tokens than older models.

Anthropic set Sonnet 5’s introductory pricing to make the switch roughly cost-neutral, but if you’re watching a bill closely, don’t assume token counts are identical to last quarter.

Step 2: Stop prompting. Start briefing.

A senior engineer does not hand a junior a one-liner and walk away.

They give context, constraints, and a definition of done.

Do the same with Claude.

Weak:

Add caching to this API client.

Add caching to this API client.

Senior-level:

You are working in an existing Swift package. Do not restructure the module.

Task: Add a lightweight in-memory response cache to APIClient.

Constraints:
- Cache only GET requests.
- TTL should be configurable, default 60 seconds.
- Thread-safe. Assume concurrent access.
- No new third-party dependencies.
- Keep the public API backward compatible.

Definition of done:
- Existing tests still pass.
- Add unit tests for cache hit, cache miss, and expiry.

Before writing code, list your plan and the files you will touch.

You are working in an existing Swift package. Do not restructure the module.

Task: Add a lightweight in-memory response cache to APIClient.

Constraints:
- Cache only GET requests.
- TTL should be configurable, default 60 seconds.
- Thread-safe. Assume concurrent access.
- No new third-party dependencies.
- Keep the public API backward compatible.

Definition of done:
- Existing tests still pass.
- Add unit tests for cache hit, cache miss, and expiry.

Before writing code, list your plan and the files you will touch.

The second version works because it gives Claude the same things a good ticket gives a human: scope, boundaries, and acceptance criteria.

That last line “list your plan before writing code” is the single highest-leverage habit in this whole article.

More on that next.

Step 3: Use effort control instead of hoping

The recent generations replaced fixed “thinking token budgets” with adaptive reasoning: Claude evaluates how hard a problem is and decides how much to think.

You steer it with an effort level rather than a raw token budget

think of it as a slider from low to max.

In practice xhigh sits between high and max: it’s for hard tasks that need extra reasoning but don’t justify maximum spend.

Opus 5, for example, runs high effort by default and exposes an xhigh tier for the nastiest problems.

How to use this in practice:

• Standard / high ➝ most coding, refactors, and everyday questions.
• xhigh ➝ a gnarly bug, a tricky architecture decision, a subtle concurrency issue.
• max ➝ reserve for genuinely brutal, one-off problems where you’d happily pay for extra compute.

In Claude Code, the pattern looks like:

/effort xhigh

/effort xhigh

Then give it the hard task.

The mistake most people make is running everything at maximum effort “to be safe.” That’s slower and more expensive for no benefit.

Match effort to difficulty, the same way you’d match a senior engineer to a hard problem and a junior to a simple one.

Step 4: Learn Claude Code ➝ this is where the real leverage is

If you only use Claude in a chat window, you’re using maybe 20% of it.

Claude Code is Anthropic’s agentic coding tool. It runs in your terminal, desktop app, or IDE, and it can read files, run commands, edit code, and call external tools through an agentic loop that chooses tools, accumulates context, and manages long sessions.

Here are the features that actually change how you work.

Plan mode

Plan mode is a read-only state: Claude can read and analyze files but physically cannot edit, write, or run commands until you approve.

It explores your codebase and proposes a numbered plan without executing anything

ideal for scoping work before you let it touch files.

Toggle it with Shift+Tab (press twice) or /plan.

Workflow:

1. Enter plan mode.
2. Describe the feature or bug.
3. Read the plan. Correct its assumptions.
4. Only then let it implement.

This one habit prevents most “the AI went rogue and rewrote half my project” disasters.

Checkpoints

Claude Code automatically snapshots your workspace before each change, and you can roll back instantly by pressing Esc twice or running /rewind.

You can revert just the code, just the conversation, or both.

This is your safety net.

It’s what lets you approve bold refactors without fear, because “undo” spans hours of work, not one edit.

Permission modes

Default mode asks before each file write and shell command.

Other modes trade oversight for speed.

There’s also an Auto mode where a separate classifier reviews each action and lets safe ones through while blocking risky ones.

My advice for anything important: keep permissions tight. The convenience of full autonomy is not worth an agent running a destructive command on your repo.

There are already public horror stories of coding agents deleting data when given too much rope.

Subagents

Claude Code can spawn subagents that work in parallel and they now run in the background by default, so the main session keeps working while they run.

For big jobs, dynamic workflows can orchestrate many subagents from a script Claude writes, enabling codebase-scale migrations.

You don’t need this on day one.

But knowing it exists changes how you scope large refactors: instead of one long serial slog, you can fan the work out.

Step 5: Give Claude the right context, not all the context

More context is not automatically better.

The skill is giving Claude the right slice.

Two features make this easy.

Projects

In claude.ai, Projects hold your files, and as they approach the context limit, Projects automatically switch to retrieval mode — Claude searches the project and pulls only the passages it needs.

That raises effective capacity dramatically without manual setup.

Use Projects for: a codebase you keep returning to, product specs, style guides, or domain docs.

Artifacts

Artifacts render code, docs, diagrams, and interactive content in a side panel with a live preview.

As of 2026 you can edit an artifact in place: highlight the part you want changed, type the instruction, and Claude edits inline.

Use Artifacts for: iterating on a component, a script, a diagram, or a small tool where you want to see the rendered result and tweak it directly.

The mental model: Projects are long-term memory; Artifacts are the workbench.

Step 6: Connect Claude to your real tools with MCP

This is the part that separates a toy from a workflow.

MCP (Model Context Protocol) is an open standard that connects Claude to external systems — GitHub, databases, browsers, and internal services. The MCP server handles the integration; Claude reasons about what to do with it.

Practical examples:

• Connect a GitHub MCP server so Claude can read issues, open PRs, and check CI.
• Connect a database MCP server (read-only) so Claude can answer questions against a real schema.
• Use Claude in Chrome so it can read console errors, network requests, and DOM state to help debug.

A word of caution, because it matters: an MCP tool is a real capability, not a suggestion.

Expose the narrowest useful tools, prefer read-only where possible, and gate anything destructive behind human approval.

If you wouldn’t hand the raw credential to a new hire on day one, don’t expose it as an unguarded MCP tool.

Step 7: Review like it’s a junior’s PR ➝ because it is

Here’s the mindset shift that ties everything together.

Claude is fast and often excellent.

It is also confidently wrong sometimes, and it can produce output that is close enough to look right and wrong enough to cause problems

the kind of bug that passes a glance but breaks in production.

So treat every meaningful change like a pull request from a talented junior:

1. Read the diff, not just the summary. The summary is the story Claude tells about its work. The diff is what actually happened.
2. Run the tests yourself. Don’t take “tests pass” on faith.
3. Ask it to review its own work in a fresh session. Running a review separately from the session that wrote the code reduces the chance it just validates its own flawed logic.
4. Be extra careful around money, auth, and persistence. For anything touching financial data or credentials, human review is non-negotiable.

A useful command exists for exactly this

a code-review pass that reports correctness bugs.

Use it, but treat it as a second opinion, not a stamp of approval.

A realistic end-to-end workflow

Here’s how these pieces fit together on a normal feature:

1. Open Claude Code in the repo. Default to Sonnet 5.
2. Enter plan mode. Describe the feature with scope, constraints, and definition of done.
3. Read the plan. Fix wrong assumptions before any code is written.
4. Let it implement with permissions on so you approve file writes.
5. If it hits a genuinely hard problem, bump to Opus 5 at xhigh effort.
6. Run the tests. Read the diff.
7. Kick off a fresh-session code review for a second opinion.
8. If something breaks, rewind to a checkpoint and adjust the brief.
9. Commit — with your name on it, because you reviewed it.

Notice what you’re doing here: you’re not typing code, you’re directing and reviewing it.

That’s the senior-engineer move.

The five habits that separate power users from chatbot users

If you remember nothing else:

1. Brief, don’t prompt. Scope, constraints, definition of done.
2. Plan before code. Always make it show the plan first.
3. Match effort to difficulty. Don’t run everything at max.
4. Keep permissions tight. Especially around anything destructive or sensitive.
5. Review the diff. You are the last line of defense, not the model.

The people getting 10x out of Claude aren’t using secret prompts.

They’re running a disciplined workflow: delegate aggressively, verify relentlessly, and keep a human hand on the parts that matter.

Claude in 2026 is genuinely capable of senior-level work.

Whether you get senior-level results depends entirely on how you drive it.

If this was useful, follow me for more no-fluff guides on AI tooling, iOS development, and shipping software that survives production.

Follow me on Medium Jerry PM for more iOS/AI/Tools and developer writing.

Thank you for reading! , If this saved you from guessing at your tags, If you enjoyed it, please consider clapping and following for more updates! 👏