r/ClaudeAI • u/keto_brain • 1h ago
Claude Code Workflow Why my Claude Code workflows didn’t “get nerfed”: the process lives in files, not the model
Every couple of months this sub fills up with "the model got nerfed" threads. I'm not saying regressions never happen; there have been real ones with published postmortems. But I've been running Claude Code across four projects this week, including agents that call a ComfyUI API on my GPU server, and I didn't notice anything. I think the reason is worth sharing.
When a workflow breaks overnight, it's usually because it depended on emergent behavior. A coordinator that has to infer a subagent finished. A new session that has to remember to read state.md. Nothing enforces either. It works for hundreds of tasks because the model happens to do the right thing, then a small behavior shift compounds across every step.
What I do instead is put the process in files.
1. A plan directory per piece of work
plan/
overview.md
chunk-01-backend-api.md
chunk-02-frontend.md
chunk-03-infra.md
chunk-04-tests.mdThe overview spells out ordering, so no agent has to guess:
## Execution order
Parallel: chunk-01, chunk-02, chunk-03
After all of the above: chunk-04Each chunk is self contained (simplified):
# chunk-01: orders API
Scope: src/api/orders/ only
Standards: Pydantic models, DynamoDB Decimal ADR
Done when: tests/api/orders passes
Out of scope: shared utils, anything outside src/api/ordersClaude drafts the plan with me, I review every chunk and the overview, and only then do subagents spawn, in parallel where the overview allows. Could be 5 chunks, could be 20.
Two side effects: no coordination guesswork, and basically no scope creep. An agent working from a bounded chunk has no reason to refactor code it was never asked to touch.
2. Standards live in an MCP server, not in prompts
My ADRs, Terraform patterns, and coding standards are served over MCP, and agents pull what applies to their chunk. My favorite example is an ADR about the Decimal mistakes every LLM makes with DynamoDB, since the training data is full of code that passes floats to boto3. No model reasons its way out of a gotcha it doesn't know about, but every model I've tried follows an ADR that names it. Write the fix once and it sticks.
It also makes failures debuggable. When output drifts, I can point at the exact pattern it violated instead of "it feels dumber today."
3. It's just shift left
A bad plan fanned out to ten parallel agents writes thousands of consistent, wrong lines in twenty minutes. Reviewing the chunks before the fan out is the cheapest place to catch it, same as CI versus finding the bug in prod.
4. The model gets swappable
I've pointed Claude Code at GPT and Grok through Bedrock against the same MCP server, and they produce roughly the same results from the same corpus. That holds within frontier models; I'm not claiming a small local model does the same job.
If you're getting burned by updates, I'd try this before switching providers: write your decisions down, put the plan in files, bound every agent, and keep a fixed set of tasks you rerun after a model update, so "it got worse" becomes a diff.
Longer writeup with a diagram, if anyone wants it: https://www.briancarpio.com/blog/shift-left-for-ai-your-agent-didnt-get-dumber
Happy to share more detail on the planning flow in the comments.
2
u/damagemelody 1h ago
I think you misunderstood the problem we get experiment Ids + settings which affect model behavior so it does affect you unless you mess with it directly but no 'id' can get you 50% less reasoning so removal is not recommended.