A Claude developer is a systems engineer, not a prompt writer
Search for one and you get outsourcing pages listing model names. The actual job is building the structure around the model.
The short version
5 things that decide this
- 01Most of a Claude developer's time goes into tool design, MCP servers, eval suites and context management, not prompt writing.
- 02The prompt is the file that changes weekly. Tool definitions, permission boundaries and the eval set are what keep the system stable underneath it.
- 03MCP servers exist to give Claude access to your systems without handing it the keys to everything: a defined set of calls, not a shell.
- 04An eval suite is what lets you change a prompt or swap a model without re-testing by hand and hoping nothing broke.
- 05Job postings and vendor pages that stop at 'writes prompts for Claude' describe a fraction of the role and hire for the wrong skill.
What the job posting gets wrong
Search "hire Claude developers" and most results are outsourcing directories. They list Claude API, Claude Code and MCP as keywords, next to a rate card. None of them describe what the person actually does once hired.
That gap matters because prompt writing is real but small. A senior engineer can draft a working prompt for most tasks in an afternoon. The part that takes weeks, and the part that decides whether the system survives contact with real users, is everything around it.
On PremiumAudit, Claude reads insurance premium-audit documents and checks the figures inside a workflow where a human auditor stays in the loop. Writing the prompt that asks it to extract a number takes a few lines. Building the pipeline around it is the actual engineering. It decides which document Claude sees, what it may flag versus correct, and how a wrong extraction gets caught before the auditor.
That distinction is why a strong prompt writer can still ship a fragile system. The prompt can read perfectly and the tool behind it can still let the model overwrite a record it should only have flagged.
- A hiring page that lists only model and framework names is describing vocabulary, not the work.
Four things that make up the job
Tool design comes first. Claude does not act on your systems directly. It calls tools you define, and every tool is a decision about what the model may do and what it may never do. A tool that lets Claude update a database row is safe. A tool that lets it run arbitrary SQL is not, no matter how good the prompt around it is.
MCP servers extend that idea across systems. On Go4Gr8, a leadership coaching platform, MCP gave Claude access to specific tools rather than a general connection to the backend. The server defines the boundary once, and every client that connects to it inherits the same limits.
Context management is the third piece, and it is mostly subtraction. Claude's context window can hold a lot, but stuffing it with everything available slows retrieval and raises cost. The engineering is choosing what the model sees for a given task, not maximizing what it could see.
Eval suites are the fourth, and the one prompt-focused hires skip most often. Without a fixed set of test cases and a passing score, every prompt edit is a guess. With one, a model retirement or a prompt change becomes a run of the suite instead of a week of manual re-testing.
- 01Tool design: what Claude may call, and what it structurally cannot.
- 02MCP servers: one defined boundary that every connected client shares.
- 03Context management: choosing what the model sees, not maximizing it.
- 04Eval suites: a scored, repeatable check that catches a regression before a user does.
- ToolsDefined calls, not open access.
- MCP serverOne boundary, shared by every client.
- ContextWhat the model sees for this task.
- EvalsA scored suite, run on every change.
- PromptThe smallest file, and the one that changes most.
The prompt sits at the end of this list because it depends on everything above it, not the other way round.
What this changes about hiring
If prompt writing were the job, the skill would transfer instantly between candidates and the hiring decision would come down to rate. It does not transfer, because the harder skills sit underneath the prompt.
Ask a candidate to describe a tool they refused to build because the blast radius was too wide. Ask what their eval set looks like and how many cases are in it. Then ask how they decided what context Claude gets for a task, and what they left out. Vague answers to those three questions are the signal, not the resume.
A rate card cannot show you any of that. A working MCP server can. A short walkthrough of how a candidate would gate a risky tool call does the same job.
Questions this raises
01Is MCP required to build with Claude, or just one option?
MCP is one way to connect Claude to tools and data, and it is not required for every build. A single application with a small, fixed set of tools can wire them directly. MCP earns its cost when several clients need the same tool boundary, or when the toolset has to grow without re-plumbing each connection.
02How big should an eval suite be before launch?
Large enough to cover every failure mode you can name, which is usually a low number of hundreds of cases rather than thousands. Coverage of distinct situations matters more than raw volume. A suite that never gets updated after launch stops describing the job within a few months.
03Does a bigger context window remove the need for context management?
No. A larger window changes what fits, not what should be sent. Retrieval that returns the wrong passage, or too many passages, still degrades an answer even when there is technically room for all of it. The discipline of choosing what the model sees does not go away as windows grow.
Related
- Hire Claude developers →Engineers who build tools, MCP servers and eval suites around Claude, and treat the prompt as one small piece of that.
- Hire Claude Agent SDK developers →For agents that need permissions and stopping conditions set in code.
- Claude Agent SDK, reviewed →What the SDK gives you over a plain API loop, and where it is the wrong shape.
- Best Claude development agencies →Five signals ranked by how well each predicts a team can ship on Claude.
