If you've ever watched Claude Code spiral into a mess of conflicting instructions, forgotten context, and half-finished refactors — you're not alone. After building Buddy (an open-source Google Ads agent on Claude) and spending hundreds of hours in Claude's agentic coding environment, I've settled on a workflow that keeps projects clean, makes Claude's outputs predictable, and dramatically cuts the time I spend untangling its mistakes. Here's exactly how I do it.
A common question in the r/ClaudeAI community is some variation of: "Why does Claude keep breaking things it already fixed?" or "How do I stop Claude from going off in the wrong direction mid-session?" The answer is almost never about Claude's capability — it's about workflow structure.
Claude Code is genuinely powerful. But it's also context-sensitive in a way that punishes unstructured use. When you dump a vague task into a fresh session, give it no guiding constraints, and let it free-form its way through your codebase, you're essentially asking a very capable contractor to renovate your house without blueprints. They'll do something — it just might not be what you wanted.
The practitioners who get the most out of Claude Code aren't the ones with the best prompts in isolation. They're the ones who've built a repeatable system around how they engage Claude from session start to session end.
The single biggest improvement to my Claude Code workflow came from treating context as a first-class artifact — something I maintain and version-control, not something I type fresh each session.
Claude Code natively reads a CLAUDE.md file from your project root at the start of every session. This is your persistent memory layer. My CLAUDE.md files typically include:
For Buddy specifically, my CLAUDE.md includes a section on Google Ads API conventions — rate limits, entity hierarchy expectations, and which campaign types the agent supports. Without that, Claude would routinely suggest approaches that are technically valid Python but completely wrong for the Ads API context.
CLAUDE.md at the end of each productive session. Capture what changed, what decisions were made, and what's in-progress. Treat it like a ship's log — the next session's Claude is reading it cold.Beyond the project-level CLAUDE.md, I keep a /tasks folder with markdown files for larger work items. When I start a session on a specific feature, I'll tell Claude: "Read tasks/budget-optimizer.md before we begin." That file contains:
This keeps Claude's working context laser-focused. Instead of it wandering through your entire repo trying to understand what matters, you're handing it a curated briefing.
How you start a Claude Code session determines 80% of how well it goes. I follow a consistent initialization sequence for every non-trivial session.
My first message is never a task. It's an orientation prompt:
"Read CLAUDE.md and the files in /tasks. Then tell me what you understand about the current project state and what we're working on today. Don't write any code yet."
That last sentence — "don't write any code yet" — is crucial. Without it, Claude will often start coding before it's fully oriented, locking in assumptions that become expensive to unwind later.
After Claude summarizes its understanding, I explicitly confirm or correct the scope. This is where I catch misalignments before they become 200-line diffs I have to review and partially revert. A typical correction looks like:
"Close — but we're only touching the reporting module today. Don't refactor the authentication layer even if you see improvements there. Capture those in CLAUDE.md for a future session."
For any task that touches more than 2-3 files, I ask Claude to outline its plan before writing a single line of code. The format I use:
"Before coding, give me a numbered list of every file you plan to create or modify, what change you'll make to each, and in what order. Flag anything you're uncertain about."
This takes 60-90 seconds and saves an average of 20-30 minutes of review and rollback per complex session in my experience. The plan itself becomes a checklist I can track against as work progresses.
Even with a solid initialization, long sessions drift. Claude's context window is large but not infinite, and agentic coding tasks can accumulate complexity quickly. Here's how I manage mid-session quality.
I break larger tasks into atomic subtasks and commit after each one. My pattern:
This is especially important for marketing automation codebases (like Buddy) where a bad change to a campaign management function could theoretically cause real spend issues. Atomic commits give you clean rollback points and force Claude to stay focused on one thing at a time.
When I sense a session is drifting — Claude is asking clarifying questions that suggest it's lost the thread, or its outputs are getting increasingly off-spec — I stop it with:
"Stop. Don't write any more code. Summarize what we've done so far this session, what the current state of the task is, and what you think the next step is."
Half the time this surfaces a misalignment I can correct without losing the work. The other half, I realize we've drifted enough that a fresh session with updated context is more efficient than trying to course-correct.
Claude is very good at inferring conventions — but it will override its inferences when it thinks a "better" approach exists. If there's a constraint that truly matters (never use global state, always return typed dicts, don't install new packages without asking), put it in CLAUDE.md AND say it again explicitly at task time. Redundancy is a feature here, not a bug.
This is where most workflows break down. A single-session, single-file task is easy. A feature that spans 10 files across 4 sessions is where structure pays compounding dividends.
At the end of every productive session, before I close out, I ask Claude to generate a handoff note:
"We're wrapping up. Write a brief handoff note I can use to start the next session — what we completed, what's in progress, what decisions we made and why, and what the next steps are. Format it so I can paste it into CLAUDE.md."
Claude is genuinely excellent at this. It will produce a clean, structured summary that takes me 2 minutes to review and commit. Future-session-me is always grateful past-session-me did this.
For complex refactors, I ask Claude to produce an impact map before touching anything:
"Before we change the campaign budget calculation function, map out every file that imports it, every test that covers it, and every downstream function that depends on its output format."
This is particularly valuable in marketing automation work where functions that seem isolated (like a budget cap calculator) turn out to touch bid strategies, alert thresholds, and reporting pipelines simultaneously.
/sessions folder in your repo (gitignored) with dated session notes. After 10-15 sessions on a project, you'll have a searchable log of every architectural decision and why it was made — something most teams don't have even for human-written code.The workflow above is amplified significantly by a clean environment setup. Here's what I run with:
| Element | My Setup | Why It Matters |
|---|---|---|
| Version Control | Git with frequent atomic commits | Clean rollback points for every Claude subtask |
| Project Context | CLAUDE.md + /tasks folder | Persistent memory across sessions |
| Testing | Pytest with coverage reporting | Lets Claude verify its own changes don't break things |
| Linting | Ruff (Python) or ESLint (JS) | Gives Claude fast, objective feedback on style compliance |
| Environment Vars | .env with .env.example committed | Claude can read the example to understand configuration shape |
| Session Notes | /sessions folder (gitignored) | Running log of decisions and progress |
As practitioners often discuss in the r/ClaudeAI community, it's worth being intentional about which interface you use for which tasks. My rough heuristic:
I sometimes run a Claude chat session in parallel with a Claude Code session — the chat session is for thinking through approach, the Code session is for execution. They complement each other well.
If you're using Claude Code to build marketing automation (campaign management scripts, reporting pipelines, bid strategy tools, API integrations), a few additional considerations apply:
When I built the budget optimization module for Buddy, I had Claude write 15 test cases covering edge conditions (zero-budget campaigns, campaigns with shared budgets, campaigns in learning phase) before a single line of implementation was written. The resulting code was significantly more reliable than my usual approach of testing after the fact.
If you're ready to overhaul your Claude Code workflow, here's a concrete action plan:
The upfront investment in structure pays back immediately and compounds over time. Claude Code is genuinely capable of production-quality work — but like any powerful tool, it rewards the people who learn to use it systematically.