
Building AI products means I'm always looking for smarter ways to code. Claude Code has become a key tool for me. After a lot of trial and error, I've found a few methods that really make a difference. These focus on planning, giving Claude clear instructions, and using agentic patterns that match how complex a task is.
Core Methodologies
1. Plan Mode First, Always
This is my golden rule. Before I write any significant code, I always go into plan mode. It stops me from wasting time on code that doesn't fit the goal. Think of it like drawing a blueprint before you start building a house.
My good plan workflow looks like this:
- I start with
/plan. - Then, I clearly state what I want to achieve and any limits I have.
- I review the plan Claude suggests. I don't just accept it.
- I ask questions and challenge its choices. We talk about it.
- I refine the plan until I feel confident.
- Only then do I exit plan mode and let Claude execute, usually with auto-accept on the changes.
This step prevents big reworks later on. It makes sure Claude and I are on the same page from the start.
2. The RIPE Workflow
When I'm working on new features, especially in areas I haven't explored much, I use a pattern called RIPE. It's proven itself in production.
- Research: I have a subagent explore the existing codebase. It finds patterns and relevant files for me.
- Iterate (Plan Mode): I draft the implementation plan and refine it, often going back into plan mode here.
- Polish: This is where I write the code. I run tests often and review the code changes at each step.
- Execute: Finally, I run the full test suite. If everything looks good, I create the pull request with all the context Claude helped me gather.
3. Spec-Driven Development
For more complex features, I use Claude's /spec command. It helps map out everything before I write code.
- I type
/specand describe the feature in plain English. - Claude then creates user stories, acceptance criteria, and details any edge cases.
- I review and approve this specification.
- Then I use
/implement-spec. Claude codes according to that spec. - Finally, I use
/verify-spec. Claude checks its own work against the spec it helped create.
Prompt Engineering Best Practices
How I talk to Claude matters a lot. A well-structured prompt gets much better results.
The 4-Block Pattern
I structure every complex prompt using four main blocks. It gives Claude a clear map.
INSTRUCTIONS
CONTEXT
TASK
OUTPUT FORMAT
Here's how I think about it, like a template:
- Goal: What exactly do I want to end up with? I'm very specific about the final output.
- Context: What's the tech stack? What type of project is this? What files are important? I often use
@fileto point to specific files. - Constraints: What should Claude avoid? Are there existing patterns it needs to follow?
- Output: Do I want a whole file, just a code snippet, or maybe three different options to choose from?
Key Principles
These principles have the biggest impact on the code Claude produces:
- Specificity: Being vague gets vague results. I'd say, "build a login form with email and password fields, validation rules, and error states, using our existing authentication library." I would never just say, "build a login form."
- XML tags: I use tags like
<instructions>,<context>,<example>, and<output>a lot. This is how Claude likes to organize information, and it helps it understand my prompt better. - Few-shot examples: One or two good examples that match my exact use case are much better than ten general ones. They show Claude exactly what I want.
- Context engineering: What Claude reads matters more than how I phrase things. Referencing files with
@ensures Claude has the right information. - One task per prompt: If I ask for multiple features at once, Claude often gives me partial implementations of each. I break down big tasks into smaller, focused prompts.
Agentic Workflow Patterns
I pick my workflow pattern based on how complex the task is.
| Pattern | Agents | Human Involvement | Best For |
|---|---|---|---|
| Sequential | 1 | After each step | Staged tasks, documentation |
| Operator | 1 | Minimal | Tool-heavy single complex tasks |
| Parallel | Multiple | Before and after | Independent tasks running simultaneously |
| Teams | Multiple | Orchestrator only | Complex tasks needing role separation |
| Autonomous | Multiple | Near zero | Scheduled, batch, repeated tasks |
For my work with React, Next.js, and AI, parallel agents often work well. I use them in git worktrees to build a few features at the same time. I usually cap it at two or three, though, because that's how many I can review properly.
Advanced Tactics
CLAUDE.md Configuration
I keep my CLAUDE.md file short, around 60 lines. It contains stable rules only. I let Claude add new lessons to it after encountering bugs. Things I include are:
- Our team's coding conventions.
- What we expect from tests.
- Our preferred file structure.
- Common mistakes to avoid.
Context Hygiene
Managing Claude's context is crucial for good results.
- I start a new session for each new topic. I don't mix debugging with planning a new feature.
- If Claude fails to correct something twice, I clear the session and start fresh.
- I try to keep the context usage around 50 percent. If it gets too big, Claude can get confused.
- For noisy research, I use subagents. This keeps my main context clean and focused.
Verification Loop
I always ask for proof. I never just accept Claude saying "it works."
- I'll say, "Show me the test output." I need to see the evidence.
- My plans always include rollback steps. I ask, "How do we undo this if it breaks?"
- I list all affected files upfront. This helps me understand the potential impact.
- I make sure to flag any irreversible steps, like database migrations or schema changes.
Automation with Hooks
Some things just have to happen. CLAUDE.md and skills are requests, not guarantees. So, I use hooks for things like:
- Pre-commit checks.
- Running tests automatically.
- Enforcing linting rules.
- Deployment gates.
Practical Example for My Stack
Let's say I'm building an AI outbound calling feature for Placewise AI. Here's a prompt I might use:
@src/voice/agent.ts @src/ai/prompts.ts
INSTRUCTIONS:
Build a new voice agent endpoint that integrates with our existing AI calling system.
CONTEXT:
- Using Azure AI Foundry for LLM
- Existing agent pattern in @src/voice/agent.ts
- Prompt templates in @src/ai/prompts.ts
- Need to handle call state, transcription, and AI responses
TASK:
Create /api/voice/outbound-agent endpoint with:
- Webhook for call events (connected, transcription, hangup)
- Stream responses back to caller
- Use existing prompt engineering patterns
- Add error handling and logging
CONSTRAINTS:
- Match existing code style in @src/voice/agent.ts
- TypeScript only
- No new dependencies
- Must pass existing test suite
OUTPUT:
- Complete implementation file
- Test file with 3+ test cases
- Brief explanation of design decisions
This prompt is specific, anchors Claude to my existing code, and clearly defines the output. When I do this, I often get production-ready code on the first try.
Common Mistakes to Avoid
I've learned a lot by making mistakes. Here are some to steer clear of:
- Making vague requests without pointing to specific files.
- Trying to mix planning and actual implementation in the same prompt.
- Not breaking down tasks that would take more than two hours into smaller prompts.
- Accepting "it works" without seeing actual test evidence.
- Letting Claude's context get too big without clearing or compacting it.
The most valuable habit I've picked up is this: I put a lot of effort into the plan. That way, Claude can often implement the code perfectly in one go. It saves me a ton of time and leads to much better results.
I do this kind of work for other teams too. If you need a senior AI engineer on your product, or someone to fix code an AI wrote, here’s how to hire me.
Essays on shipping software and building products. No schedule, no filler.