Claude Code workflows: stop using chat-style prompting

I read a practical write-up arguing that teams (and solo devs) often lose the benefit of Claude Code by using it like ChatGPT: iterative back-and-forth where the model improvises over an undefined repo state.

The core shift is to make the repo drive the behavior. In practice, that means treating `CLAUDE.md` as the interface contract (what it should do, how it should structure outputs, and what “done” looks like), then relying on plan-oriented execution rather than conversational correction.

Where this shows up immediately for engineers: when you need a multi-file change (e.g., updating a FastAPI endpoint + tests + a small RAG component) and you want consistent diffs across runs. Chat-style prompting tends to re-litigate assumptions every turn; workflow-style prompting anchors the task once, then executes in a controlled loop.

What to look at first: - `CLAUDE.md` in the project root (it’s the entry point for task constraints) - a “plan mode” workflow that separates deciding from editing - a headless / non-chat execution path (so runs are less dependent on your exact wording)

If you’re building agent systems or production tooling, this is mostly an interface hygiene issue: fewer degrees of freedom during execution, more determinism from explicit repo metadata. It’s not that chat is “wrong”; it’s that Claude Code is best when you give it a stable specification and let it run.

I’m going to tighten my own `CLAUDE.md` templates to reflect this: clear goals, file expectations, and acceptance criteria before I ever ask for code edits.