Skip to main content

Command Palette

Search for a command to run...

Stop Prompting Like a Beginner: The Plan-First Framework That 10x'd My Development Speed with Claude

Most developers use Claude like a magic autocomplete. Here's the framework that turned it into my most reliable engineering partner.

Published
14 min read
Stop Prompting Like a Beginner: The Plan-First Framework That 10x'd My Development Speed with Claude

I've been using Claude daily for over a year now. In that time, I've watched hundreds of developers — juniors and seniors alike — make the same mistakes over and over. They type something vague like "build me a login page" and then spend 45 minutes fixing the output. Sound familiar?

After months of trial, error, and refining my workflow, I've developed a framework that consistently produces production-ready code in a fraction of the time. The secret isn't about writing longer prompts. It's about planning before implementing — and it changes everything.

This post covers the exact system I use. No fluff. Just the workflow.


The Core Problem: Why Your AI Output Sucks

Let's be honest. Most of us prompt like this:

"Build me a dashboard with React and Node."

And then we're surprised when Claude gives us:

  • Generic Create React App boilerplate

  • No state management

  • Hardcoded data with no real API connection

  • Zero error handling

  • Not even close to production-ready

The issue isn't Claude. It's the input. Claude is a skilled contractor — not a mind reader. The quality of your output is directly proportional to the quality of your input.

Garbage in, garbage out. Every single time.


The C.R.A.F.T. Framework: Structure Your Prompts Like a PRD

Before you type a single word to Claude, think about five dimensions:

C — Context Your tech stack, versions, existing patterns, libraries in use. Don't just say "React" — say "React 18 + Vite + TypeScript + TailwindCSS."

R — Role Tell Claude WHO it should be. "Act as a senior full-stack developer who follows clean code principles and writes production-ready, well-documented code."

A — Architecture Folder structure, design patterns, scalability approach. "Use feature-based folders, separate business logic into a services layer, centralized error handling."

F — Functionality The exact features, edge cases, and validation rules. Not "add auth" — but "JWT access tokens (15-minute expiry) with refresh tokens (7-day) stored in httpOnly cookies. Rate limit login to 5 attempts per 15 minutes."

T — Testing & Types TypeScript types, unit tests, integration tests. "Strict TypeScript — no any types. Include Jest unit tests for the service layer."

You don't need all five every time. But the more dimensions you cover, the less cleanup you'll do later.

Here's what happens when you apply C.R.A.F.T.:

Before (vague prompt): 4 rounds of back-and-forth, ~19,000 tokens burned, generic output.

After (C.R.A.F.T. prompt): 1 round, ~3,500 tokens, production-ready code. Same result. 5x cheaper.


The Golden Rule: Plan First, Implement Second

This is the single most important concept in this entire post. Read it twice.

Never let Claude start writing code from your first prompt.

I know — it feels counterintuitive. You want code. But here's what happens when you skip planning:

  1. You send the prompt

  2. Claude creates 15 files immediately

  3. Wrong folder structure? Too late.

  4. Wrong package choice? Already installed.

  5. You're now debugging, not building.

Instead, add six words to the end of every prompt:

"Don't write any code yet."

That's it. Those six words change everything.

When you say this, Claude shifts from implementation mode to planning mode. Instead of generating code, it gives you:

  • A folder tree showing the proposed structure

  • A list of packages it would install, with rationale

  • Config files it would create

  • The architectural approach it would take

Now you can review, course-correct, and iterate — before a single line of code exists. Fixing a plan takes 30 seconds. Fixing an implementation takes 30 minutes.

The Two-Phase Workflow

Every task I do with Claude now follows this exact flow:

Phase 1 — Plan

I'm building [feature] using [tech stack].

[Requirements, specifics, constraints]

Plan the approach. Show me:
- File structure
- Key decisions and tradeoffs
- API contracts (if applicable)

Don't write any code yet.

I review Claude's plan. I give feedback: "Change X, keep Y, add Z." Claude revises the plan. This costs almost nothing in tokens because plans are short.

Phase 2 — Implement

Approved. Two changes:
- [modification 1]
- [modification 2]

Now implement following the plan.

Save the plan to docs/specs/[feature-name].md

That last line is crucial — I'll explain why in a moment.


Saving Specs to Git: The Team Context Problem (Solved)

Here's a problem nobody talks about: you spend 20 minutes crafting the perfect plan with Claude, implement a beautiful feature, push to git... and your teammate pulls the code with zero context about why it was built that way.

The fix is simple. When Claude creates a plan, save it as a markdown file:

docs/
  specs/
    01-project-setup.md
    02-database-models.md
    03-auth-module.md
    04-task-crud.md
    05-frontend-ui.md

Each spec contains:

  • Problem: What we're building and why

  • Approach: Architecture decisions made

  • Files Changed: Which files were created or modified

  • API Contracts: Endpoints, request/response shapes

  • Edge Cases: What could go wrong

When you commit specs alongside code, your whole team benefits. New developers clone the repo and immediately understand not just what was built, but why it was built that way.

If you're using Claude Code (the CLI tool), add this to your CLAUDE.md:

## Team Workflow
- Every feature must have a spec in docs/specs/ before implementation
- Read the relevant spec before modifying any module
- Update the spec if implementation deviates from the plan

Now Claude automatically checks specs before making changes. Every developer on the team gets consistent, context-aware AI assistance.


The Debug Template That Saves 30 Minutes a Day

The most common daily use case isn't building features — it's debugging. And most developers do it terribly:

"My app is broken."

Claude has literally zero context to help you.

Instead, use this 5-part structure every time:

  1. Exact error message (copy the full stack trace)

  2. The code that causes it (the relevant file, not your entire codebase)

  3. What you expected vs what actually happened

  4. Steps to reproduce

  5. What you've already tried

Here's a real example:

I'm getting this error when calling my login API:
Error: "Cannot read properties of undefined (reading 'password')"

Here's my auth controller: [paste code]
Here's the request body: { email: 'test@test.com', pass: '123' }

Expected: JWT token returned.
Got: 500 Internal Server Error.

Stack: Express + Mongoose + TypeScript.
Already tried: Checking req.body — it logs correctly.

With this format, Claude nails the fix in one response. Without it, you're doing 4-5 rounds of "can you show me the code?" and "what error exactly?"

Better debug prompts = fewer rounds = less time wasted = fewer tokens burned.


Prompt Chaining: Stop Re-Explaining Yourself

One of the most powerful (and underused) techniques is referencing Claude's previous output instead of re-describing everything.

Here's how it works in practice:

Prompt 1: "Build the User model with Mongoose. Email unique and indexed, password hashed with bcrypt..."

Prompt 2: "Using the User model you just created, build the auth controller with register, login, and refresh endpoints."

Prompt 3: "Using the auth middleware from above, build Task CRUD following the same controller pattern."

Prompt 4: "Following the same pattern, add a comments feature for tasks."

The key phrases:

  • "Using the X you just created..."

  • "Following the same pattern as..."

  • "In the same style as the auth module..."

This works because Claude's context window includes everything above. Referencing earlier output costs zero extra tokens compared to re-describing your stack and patterns from scratch.


Token Optimization: The Numbers That'll Change How You Prompt

If you're on a Claude Pro plan, API, or your team has usage limits, token optimization isn't optional. Here are the numbers:

  • 80% of tokens are wasted on the re-prompt cycle (vague prompt → wrong output → re-prompt → slightly better → re-prompt again)

  • Each re-prompt round re-sends the entire conversation history. So round 4 includes rounds 1, 2, and 3.

  • One well-crafted prompt produces the same result at 5x lower cost

The Cheat Sheet

Append these modifiers to any prompt:

Modifier Token Savings
"Code only. No explanations." 40-60%
"Show only changed lines with 3 lines of context." 80-90%
"Respond in under 50 lines." 50-70%
"No inline comments unless logic is complex." 15-25%
"List only file names and their purpose." 70-80%
"Give me type interfaces only, not implementation." 60-75%
"Use the same patterns from the auth module." 30-50%
"Yes, proceed with that approach." 95%+

That last one is the biggest unlock. When Claude proposes an approach and you agree, just say "Yes, proceed." Don't re-explain what Claude already said.


When NOT to Use Claude

This might be the most important section. Nobody talks about this enough.

Don't use Claude for learning fundamentals. If you can't write a for loop without AI, you have a knowledge gap — not a productivity gap. Use Claude to explain concepts, not to write code you don't understand. If you can't explain it to your manager during a production outage, you don't understand it well enough.

Don't trust Claude for security-critical logic. Auth flows, encryption, payment processing — always have a human security review. Claude is good, but not infallible. One wrong JWT implementation can expose your entire user base.

Don't let Claude make your architecture decisions. "Should I use SQL or NoSQL?" Claude can present the options beautifully. But you must decide based on your specific constraints, team skills, and scale requirements.

Know when to start fresh. If Claude goes off-track mid-conversation, don't try to fix a broken path. Start a new chat. Paste only the context you need. It's faster and cheaper than trying to redirect a derailed conversation.

Common Pitfalls

  • Hallucinating packages: Claude confidently suggests libraries that don't exist. Always verify with npm search.

  • Outdated API syntax: Claude might use React Router v5 syntax when you need v6. Always specify versions.

  • Over-engineering: Claude defaults to complex solutions. Add "Keep it simple. Minimum viable implementation first."

  • Confidently wrong code: Code compiles, looks correct, but has subtle logic bugs. Always run and test.


Claude Code: The CLI That Changes Everything

If you haven't tried Claude Code, you're missing out on the biggest productivity unlock.

Unlike claude.ai (where you copy-paste code), Claude Code runs in your terminal and can read, write, and execute code across your entire project. No more copy-pasting files back and forth.

The Setup (30 seconds)

npm install -g @anthropic-ai/claude-code
cd your-project
claude
# Type: /init

/init scans your codebase and generates a CLAUDE.md file — a persistent memory file that Claude reads at the start of every session. It contains your build commands, test instructions, folder structure, and coding conventions.

CLAUDE.md: Your Project's Brain

Commit CLAUDE.md to git. Your entire team benefits. Here's what mine looks like:

## Stack
React 18 + Vite + TS + Tailwind | Express + Mongoose + TS

## Build
cd client && npm run dev | cd server && npm run dev

## Rules
- No 'any' types. Named exports. Feature-based folders.
- Every feature needs a spec in docs/specs/ before implementation.
- Read the relevant spec before modifying any module.

You can scope rules at different levels:

  • ~/.claude/CLAUDE.md — Global (all projects)

  • ./CLAUDE.md — Project root (shared via git)

  • ./client/CLAUDE.md — Frontend-specific rules

  • ./server/CLAUDE.md — Backend-specific rules

Plan Mode: Think Before You Code

The killer feature. Press Shift+Tab twice to activate Plan Mode.

In Plan Mode, Claude can only read — it cannot write files or execute commands. It's forced to think first, propose a plan, and wait for your approval.

The workflow:

  1. Enter Plan Mode (Shift+Tab ×2)

  2. Claude researches your codebase + reads CLAUDE.md

  3. Claude proposes a structured plan

  4. You review, give feedback, iterate

  5. You approve → exit Plan Mode → Claude implements

This is the plan-first principle built directly into the tool.


Putting It All Together: The Complete Workflow

Here's the exact workflow I follow for every feature, from start to finish:

Step 1: Clone repo, run /init, enrich CLAUDE.md with team rules.

Step 2: Enter Plan Mode. Describe the feature. Claude reads codebase + CLAUDE.md, proposes a plan.

Step 3: Review the plan. Give feedback. "Change X, add Y, remove Z." Iterate until satisfied.

Step 4: Approve. Claude implements exactly what was agreed.

Step 5: Run review prompts — security audit, performance check, type safety.

Step 6: /clear (fresh context for next feature). Commit working code + spec. CLAUDE.md persists.

Repeat for every feature.

The cost of this workflow: ~2 extra minutes of planning per feature.

The savings: 30+ minutes of debugging, refactoring, and re-prompting. Per feature.


The Coding Standards Block (Copy This)

Add this to your Claude Project instructions or CLAUDE.md. Customize for your team:

## Coding Standards (Always Follow)
- TypeScript strict mode. No 'any' types ever.
- ESLint + Prettier (Airbnb base config)
- Functional components with hooks only (no classes)
- Named exports (no default exports except pages)
- All API calls wrapped in try-catch with typed errors
- Custom hooks for any reusable logic
- JSDoc comments on public functions & components
- Constants in UPPER_SNAKE_CASE, variables in camelCase
- Components in PascalCase, files match component name
- Centralized error handling (ErrorBoundary + middleware)
- Environment variables validated at startup with Zod

When you enforce standards in the prompt, Claude follows them. When you don't, Claude uses its own defaults — and those defaults rarely match your team's conventions.


TL;DR — The Framework in 60 Seconds

  1. Use C.R.A.F.T. to structure every prompt (Context, Role, Architecture, Functionality, Testing)

  2. Plan first, implement second. End every first prompt with "Don't write any code yet."

  3. Save specs to git. docs/specs/feature-name.md — your team gets full context.

  4. Chain your prompts. "Using the X you just created..." saves tokens and maintains consistency.

  5. Review AI output. Run security, performance, and type-safety audits on generated code.

  6. Use Claude Code + Plan Mode for anything beyond simple snippets.

  7. Know when NOT to use Claude. Fundamentals, security-critical logic, architecture decisions.

  8. Optimize tokens. "Code only, no explanations" + "Show only changed lines" = 80%+ savings.


What Changed for Me

Before this framework, I used Claude like a faster Stack Overflow — paste a question, get an answer, manually fix the gaps.

After adopting plan-first: I build features in a single cycle. My code reviews have fewer issues. My teammates understand the architecture because specs are committed to git. And I burn through significantly fewer tokens doing it.

The framework isn't complicated. It's just disciplined. And discipline, it turns out, is the only thing separating developers who are 2x productive with AI from those who are 10x.


If this was helpful, share it with a developer who's still prompting like it's 2023. And if you have your own Claude workflow tips, drop them in the comments — I'm always iterating.


Support My Work

If you found this guide on Claude helpful and would like to support my work, consider buying me a coffee! Your support helps me continue creating beginner-friendly content and keeping it up-to-date with the latest in tech. Click the link below to show your appreciation:

👉 Buy Me a Coffee

I appreciate your support and happy learning! ☕


That's a Wrap

If you made it this far, you're already ahead of 90% of developers using AI. The difference between someone who uses Claude and someone who masters it comes down to one habit: plan first, implement second.

Start small. Pick one technique from this post — C.R.A.F.T., the debug template, or just adding "Don't write any code yet" to your next prompt. Try it for a week. You'll never go back.

If this helped you, share it with a developer friend who's still copy-pasting "build me a login page" into Claude. They'll thank you later.

Happy building. 🚀


Follow me for more on AI-assisted development, frontend engineering, and building things that actually ship.

More from this blog