Claude Code MCP tools need a blast radius, not a vibe check
MCP makes Claude Code more useful, but every server also widens the blast radius. Treat MCP tools as production access paths with allowlists, approval gates, call logs, and rollback notes.
MCP makes Claude Code more useful, but every server also widens the blast radius. Treat MCP tools as production access paths with allowlists, approval gates, call logs, and rollback notes.
AI code generation is manageable when it suggests code. The risk changes when agents can edit files, run commands, call tools, and open pull requests.
A Claude Code diff is not enough evidence for production review. Ask for the objective, permission boundary, tool trace, tests, failures, cost, and rollback path before approving agent work.

Claude Code: Building Production Agents That Actually Scale is now live on Amazon Kindle. Here is who it is for and why I wrote it.
If a Claude Code agent can change production-shaped code, the prompt should say how to undo the work. Rollback is not paperwork after the diff. It is part of the task boundary.
Claude Code cost problems usually start before the model call: vague tasks, wide-open tools, repeated repo exploration, and no stop rule. Treat spend as a workflow bug, not just a pricing problem.
Production Claude Code evals should not begin with abstract benchmarks. Start with the agent runs that scared you, reduce them into replayable cases, and use them to tune permissions, prompts, tools, and review gates.
Claude Code permission modes can look safer than they are. The real production risk lives in tool scope: paths, network access, secrets, deploy files, and what reviewers actually approve.

If a Claude Code agent changes production code, the useful artifact is not the chat transcript. It is a flight recorder: intent, boundaries, commands, diffs, tests, approvals, and rollback notes.
A Claude Code demo is easy to love. You describe a feature, the agent edits files, runs commands, fixes its own mistakes, and suddenly the repository has moved. The first time you see it work, it feels like software engineering has skipped a generation. But the demo is not the hard part. The hard part is making that same capability safe enough, repeatable enough, and observable enough that you would trust it inside a real engineering workflow. That is where the actual product begins. ...