Claude Code Operator Playbook, Part 1: Planning & Extreme Decomposition
Claude Code is still a massive leverage tool. But as performance gets more variable, you need to stop prompting and start operating.
If you’ve felt Claude Code get more variable lately, you’re not alone.
I use Claude Code every single day to build Enki IQ, an AI-powered sales intelligence platform that runs on AWS. I’m not an engineer by training. I’m a sales professional who taught himself to build production software using AI coding agents. So when model performance gets inconsistent, I don’t have the luxury of muscling through it. I need a workflow that produces reliable output regardless of how the model is performing on any given day.
Over the past several months I’ve developed a system for operating Claude Code that has fundamentally changed the quality and consistency of my output. This is Part 1 of a 4-part series where I’m going to share the entire framework.
The Premise: Reliability Beats Brilliance
Here’s what I’ve learned: Claude can be absolutely amazing. But it’s not consistent enough to run on trust.
In a real production codebase, the failure mode isn’t one wrong line of code. It’s cascading drift. A broken invariant here. Out-of-date docs there. Mismatched infrastructure assumptions. Missing tests. By the time you notice something is off, the damage has spread across a dozen files and you’re spending hours untangling what happened.
The core mindset shift that changed everything for me: stop treating Claude Code like a conversation. Start treating it like a system you operate.
That means building repeatable processes, automated guardrails, and a documentation architecture that keeps the model’s context sharp. Not hoping for a good session.
Boris Cherny’s Point, Extended
Boris Cherny recently made the point that you should spend more time in planning mode than you think you need. He’s right. And I think it matters even more now. As model performance varies, the clarity of your expectations becomes the single biggest stabilizer.
But I’d push the idea further. “Planning mode” shouldn’t be a paragraph of instructions. It should be a fully itemized task graph. A contract between you and the model about exactly what’s going to happen, in what order, touching what files, and how you’ll know each step succeeded.
Planning Mode, Weaponized: Deconstruct Until It Can’t Be Misunderstood
My rule is simple: never accept “implement X.”
When Claude produces a plan, I force it to decompose the work until every single unit of work is:
Small enough to review in under 2 minutes. If I can’t quickly verify the output, the step is too big.
Locally scoped. Each step should touch a clear, limited set of files and surfaces. No “update the codebase” steps.
Verifiable. There’s an explicit pass/fail check. A test that passes. A build that succeeds. A command that returns the expected output.
Reversible. If something breaks, I can roll back that specific step without unwinding everything else.
This is the part most people skip. They get a plan from Claude that says “Step 1: Set up the database. Step 2: Build the API layer. Step 3: Add the frontend.” That’s not a plan. That’s a wish list.
My Planning Checklist
Before any implementation starts, I make Claude produce a structured planning document that includes:
1. Goal and non-goals. What are we doing? Just as importantly, what are we NOT doing? This prevents scope creep, which is one of the most common failure modes with AI coding agents. Claude loves to “improve” things you didn’t ask it to touch.
2. Assumptions and constraints. Explicit statements like “do not touch the auth layer,” “no refactoring of existing code,” “no API contract changes.” These are the guardrails. If Claude violates one, I know immediately that something went wrong.
3. Atomic step-by-step plan. Every step is a single, reviewable unit of work. Not “build the feature.” More like “add the DynamoDB table definition to the CloudFormation template with the following schema.”
4. For each step: files touched, validation command, and expected outcome. This is where it gets specific. Step 3 touches template.yaml and handler.js. To validate, run sam build && sam local invoke. Expected outcome: 200 response with the new schema fields. If I can’t state this for every step, the plan isn’t detailed enough.
5. Risk register with mitigations. What could go wrong? What are the dependencies? Where are the landmines? This sounds heavy, but in practice it’s 3-5 bullet points that save you from the “oh no, I didn’t think about that” moment 4 steps in.
6. Required doc updates and test checkpoints. Which documentation needs to be updated as a result of this change? Which tests need to be written or modified? This gets defined upfront, not as an afterthought.
Why This Level of Decomposition Matters
I know what you’re thinking. This is a lot of overhead. Why not just let Claude build the thing?
Because the cost of fixing cascading drift is 10x the cost of planning. Every time.
When you decompose work this aggressively, three things happen:
First, you catch problems at the step level, not the project level. If Step 4 fails validation, you know exactly what went wrong and where. You’re not staring at a broken build wondering which of the last 15 changes caused it.
Second, you create natural review points. Each completed step is a checkpoint. You can review, test, and confirm before moving to the next one. This is especially important when model performance is variable, because you’re not betting the entire change on one long session.
Third, you build a paper trail. When something goes wrong three weeks later, you have a documented plan with clear decisions and assumptions. You can trace back to exactly where things diverged. I also keep a running log of all changes agents implement using Entire - this allows me to see exactly what they’ve done and, specifically, where they compounded errors in every session, whenever something goes wrong.
What This Looks Like in Practice
Here’s a real example. I just built a full billing and quota system for Enki IQ this week. Stripe integration, usage quotas per AI operation, frontend gating, the works. Instead of telling Claude “build a billing system,” here’s what the decomposed plan actually looked like:
Step 1: Define the Aurora billing tables. Files: supabase/migrations/20260404000000_billing_tables.sql. Validate: deploy via RDS Data API script. Create usage_quotas, quota_transactions, and stripe_events tables with RLS policies, user_id filtering, and AI cost tracking columns. Quotas track per-operation monthly allowances with separate included and pack balances.
Step 2: Build the shared quota library and Stripe backend Lambdas. Files: aws/layers/enki-shared/nodejs/shared/quota.js, aws/functions/enki-manage-billing/index.js, aws/functions/enki-stripe-webhook/index.js. Validate: cfn-lint on updated stack template. quota.js in the shared layer handles quota checks, decrements, and reset logic. The billing Lambda handles checkout session creation, customer portal, and quota queries. The webhook Lambda processes Stripe events and syncs subscription state to Clerk metadata.
Step 3: Add Lambda definitions to CloudFormation Stack 1. Files: aws/infrastructure/lambda-stack-1-core.yaml. Validate: cfn-lint + aws cloudformation validate-template. Add both function resources with log groups, IAM roles, and environment variables for Stripe secret references.
Step 4: Add quota enforcement to AI operation Lambdas. Files: aws/functions/enki-start-research-job/index.ts, aws/functions/enki-enrich-contact-apollo/index.ts, aws/functions/enki-generate-foresight/index.js, aws/functions/enki-generate-pipegen-plan/index.ts. Validate: verify each function compiles, confirm quota check is gated before the expensive AI call. Each Lambda imports the shared quota library and calls checkAndDecrementQuota() before invoking Gemini or Claude. Returns a 429 quota-exceeded response if the user’s balance is zero.
Step 5: Build frontend billing hooks, gate components, quota UI, and plan selection page. Files: src/hooks/billing/useBilling.ts, src/hooks/billing/useQuotas.ts, src/components/billing/PlanGate.tsx, src/components/billing/QuotaGate.tsx, src/components/billing/QuotaUsageBar.tsx, src/pages/PlanSelection.tsx, src/lib/featureAccess.ts. Validate: TypeScript compilation, route registered in App.tsx. PlanGate redirects unsubscribed users to plan selection. QuotaGate wraps AI actions and shows remaining balance or an upgrade prompt. PlanSelection renders tier cards with monthly/annual toggle and redirects to Stripe Checkout.
Step 6: Address PR review feedback. Files: all billing files above. Validate: PR review comments resolved, Sentry integration verified. Addressed automated review comments from CodeRabbit and Sentry. Improved error handling in webhook and quota code, added Sentry spans to billing operations, fixed quota gate edge cases, and tightened subscription hook type safety.
Six steps. Each one scoped to a clear surface area. Each one with explicit files and a validation check. If the Stripe webhook breaks in Step 2, I’m not digging through frontend components to figure out why. If the quota gate has an edge case in Step 5, I’m not worried about whether it affected the database migration in Step 1.
That’s what extreme decomposition looks like on a real feature in a real codebase. Not theory. This shipped yesterday.
Coming Up Next
This is Part 1 of a 4-part series on how I operate Claude Code in a real production codebase:
Part 2: Why Claude.md should be a router, not an encyclopedia, and the doc routing pattern that keeps context sharp
Part 3: Automated review with hooks and auditor agents (including a case study on preventing cascading failures across CloudFormation stacks)
Part 4: A full day-in-the-life walkthrough of a real change using this entire framework
If you build with Claude Code, follow me so you don’t miss the rest of the series.
And I’m curious: what does your planning process look like before you let Claude Code touch your codebase? Are you decomposing to this level, or running on vibes? Drop your approach in the comments.
Alex Gold is the founder of Enki IQ and a sales professional who taught himself to build production software with AI coding agents. He writes about GTM AI systems and the reality of building as a non-technical founder.