I see this all the time: people blame Claude Code for buggy output, but the real problem is the way they’re instructing it. If you give vague prompts, you get vague (and risky) changes—especially in a real production repo with lots of moving parts. In this video, I walk through the exact framework I use on client builds to get clean, predictable code changes without letting Claude “make decisions it shouldn’t be making.” I demo it on a real product search app that has two pipelines: single search and bulk search. I had already optimized the bulk pipeline, but the single pipeline didn’t get those updates—so the goal is to mirror the bulk logic without touching anything else (API contracts, UI, Docker, database, etc.). The key step most developers skip is creating a structured plan document in Markdown: a clear goal, a concise summary of how the current bulk pipeline works (functions/endpoints/workers), the exact updates to make, hard rules (including “ask clarifying questions”), and a definition of success with validation/tests. This gives Claude the context it needs up front, and it massively reduces the chance of a jumbled mess in your repo.