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. ...
It was a Tuesday, the kind where the London drizzle seemed to seep into your bones, even if you were miles away in Basingstoke (my home town). I was tasked with a rather daunting project, or not really as you will find out: designing and deploying a real-time Sentiment Analysis product for a major telecommunications company, and, oh, they needed it yesterday. Or so it felt. Now, usually, this would mean weeks of planning, coding, debugging, and endless cups of tea. But this time, something was different. I decided to try something I’d been experimenting with – something I now call “Vibe Coding.” ...