Skills Engineers Need to Run Claude Opus in Claude Code

A team buys Claude Opus seats, wires up Claude Code, and waits for the productivity curve to bend. Six weeks later the curve is flat. The model is fine. The problem is that nobody on the team has learned the new motor skills that make an agentic coding tool actually compound. Running Opus inside Claude Code is not the same job as writing code by hand, and it is not the same job as chatting with a model in a browser tab. It is a supervisory craft, and the people who are good at it have deliberately built a different muscle.

This post is about that muscle. Which skills genuinely shift, which hires you need, and how to grow the capability inside a team that already has strong engineers but has never run a long-lived autonomous agent on its own codebase.

Why the old skill profile stops paying off

The instinct for most senior engineers is to treat Claude Opus as a faster autocomplete. They type a function signature, accept a suggestion, move on. That captures maybe a tenth of the value. Claude Code is built to take a goal — "add rate limiting to the public API and write the tests" — plan it, touch many files, run the suite, read the failures, and iterate. The bottleneck is no longer typing speed. It is the engineer's ability to specify intent precisely, to bound the work, and to verify the result.

That inverts the usual seniority signal. The person who is fastest at hand-writing a parser is not automatically the person who gets the most out of an agent. The person who can write a crisp, testable specification and design a check that proves the agent did the right thing — that person pulls ahead. Teams that notice this early reorganize who does what. Teams that don't keep their best engineers babysitting suggestions one line at a time.

The four skills that actually shift

When you watch people who are genuinely good at this, four capabilities show up again and again. None of them are exotic, but most engineers have never been asked to develop them on purpose.

flowchart TD
  A["Engineer's goal"] --> B["Spec & constraints skill"]
  B --> C["Claude Opus plans in Claude Code"]
  C --> D{"Eval / test gate"}
  D -->|Fails| E["Read failure, refine prompt"]
  E --> C
  D -->|Passes| F["Supervised review & merge"]
  F --> G["MCP plumbing feeds context"]
  G --> B

First, specification fluency: turning a fuzzy ask into an unambiguous brief with explicit constraints, file boundaries, and a definition of done. Second, eval design: writing the checks — unit tests, golden outputs, lint gates, a quick script — that let the agent and the human know whether the work is correct without reading every line. Third, context plumbing: configuring MCP servers, skills, and project files so the agent has the right tools and the right knowledge in front of it. Fourth, agent supervision: knowing when to let a run continue, when to stop it, and how to decompose a task so a single agent or a fleet of subagents stays on the rails.

Specification fluency is the new typing speed

The single highest-leverage skill is writing a brief the model cannot misread. Vague prompts produce confident wrong work, and confident wrong work is more expensive than no work because someone has to find the error. Good practitioners front-load constraints: which files are in scope, which patterns to follow, what the existing tests expect, and what "done" looks like in a sentence a test could check.

You can teach this. Have engineers write the spec first, in a comment or a scratch file, before they invoke Opus. Review the spec the way you would review a design doc. The teams that institutionalize "spec before run" see fewer wasted agent loops and far less rework, because the model spends its reasoning budget building the right thing instead of guessing at the requirement.

Evals are the skill nobody hires for — yet

The hardest cultural shift is treating evaluation as a first-class engineering activity. An agent that can write code can also write code that looks plausible and fails subtly. The only scalable defense is an automated check that runs after the agent and gates the merge. An eval here just means a repeatable test that decides whether the output meets the bar — sometimes a unit test, sometimes a golden-file comparison, sometimes a small script that asserts an invariant.

Most teams have test engineers; few have people who think about evals for agent output specifically. That is the emerging hire. Look for people who are comfortable defining "correct" precisely and who enjoy building the harness that proves it. If you can't hire for it, grow it: ask every engineer to ship the check alongside the change, and make the check the thing the agent has to pass before a human even looks.

MCP plumbing and the rise of the agent platform engineer

Claude Code reaches external systems through the Model Context Protocol. The Model Context Protocol is an open standard, introduced in late 2024, that lets Claude connect to external tools and data through MCP servers, while Agent Skills teach it how to use those tools well. Wiring this up — which servers to expose, what permissions they get, which skills to package — is real platform work, and it determines how capable your agents are day to day.

On mature teams a new role appears: someone who owns the agent platform the way a build engineer owns CI. They curate the MCP servers, write and version the shared skills, define the hooks and guardrails, and keep the whole setup secure. You do not necessarily hire this from outside. Often your strongest infrastructure engineer migrates into it, because the instincts — least privilege, reproducibility, good defaults — transfer directly.

The reason this role pays off is leverage. A single well-built skill — say, one that teaches Claude how to follow your migration conventions or generate your API clients correctly — improves every run across every team that uses it. Without an owner, each engineer reinvents that context in their own prompts, inconsistently, and the gains never compound. With an owner, the platform gets better every week and the whole organization rides the improvement. That is the difference between treating Claude Code as a personal tool and treating it as shared infrastructure.

Agent supervision is a learnable judgment, not a personality trait

The last skill is the one people assume can't be taught: knowing when to let a run continue and when to stop it. It looks like intuition, but it is mostly pattern recognition you can develop on purpose. A run that is making steady, legible progress against a clear gate should be left alone. A run that is thrashing — editing the same file repeatedly, re-deriving the same wrong assumption, or wandering outside the stated scope — should be stopped and re-specified rather than nudged.

The teachable instinct is to treat a thrashing agent as a signal that the input was wrong, not the model. Nine times out of ten the fix is a sharper spec or a missing piece of context, not a cleverer prompt mid-run. Engineers who learn to recognize the thrash pattern early stop wasting agent loops and stop burning tokens on runs that were never going to converge. This is exactly the kind of skill that grows fast with deliberate reps and feedback, which is why the rotation model below works.

How to grow the capability without a reorg

You don't need to fire anyone or post five new req. The practical path is a rotation. Pick one team, give them a month, and have them work agent-first on real tickets while writing down what they learn. Pair an engineer strong on testing with one strong on architecture so the eval skill and the spec skill cross-pollinate. Capture the good prompts and the good skills as shared assets so the next team starts ahead.

Measure the right thing while you do it. Not lines accepted — that rewards verbosity. Track rework rate, time from ticket to merged-and-passing, and how often a run needed human rescue. Those numbers tell you whether the skills are landing. When they improve, you have proof to spread the practice; when they don't, you usually find the gap is spec quality or eval coverage, both of which are teachable.

Frequently asked questions

Do we need to hire prompt engineers to use Claude Opus with Claude Code?

Rarely as a dedicated title. The skills that matter — clear specs, good evals, sound context setup — sit better inside your existing engineers and a platform owner. A standalone prompt engineer often becomes a bottleneck; embedding the skill in the whole team scales further.

Which existing role adapts most naturally to supervising agents?

Engineers who already think in terms of tests and contracts adapt fastest, because supervising an agent is mostly about defining "correct" and verifying it. Strong reviewers and test-minded developers tend to take to it before pure feature-velocity coders do.

How long until a team is genuinely productive with this setup?

Plan for a few weeks of deliberate practice, not a day. The model works immediately; the human skills of specification, eval design, and supervision take a rotation or two to settle before the productivity curve actually bends.

Bringing agentic AI to your phone lines

The same skills — precise specs, real evals, careful tool plumbing — are what make CallSphere's voice and chat agents reliable: multi-agent assistants that answer every call and message, use tools mid-conversation, and book work around the clock. See it live at callsphere.ai.

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.