Claude Code is a Beast: Lessons from Rewriting 300k Lines of Code in 6 Months

Author’s Note: This post is a curated summary of an exceptional Reddit post by u/JokeGold5455 titled “Claude Code is a Beast – Tips from 6 Months of Hardcore Use”. All credit for these techniques goes to the original author. They’ve also published a GitHub repository with implementation details.

This post highlights key insights, but I strongly encourage you to read the full Reddit post for the complete details, code examples, and the author’s full context.

Six months ago, a software engineer made what might have been an overly ambitious promise: completely redesign and refactor a 100k line internal web application. Solo. In a few months.

The project was rough - a college student-made codebase forked from a 7-year-old intern project. Zero test coverage. Insurmountable tech debt. Horrible developer experience.

Fast forward to today: 300-400k lines of modern, tested, production-ready code. React 16 → React 19 TypeScript. Material UI v4 → MUI v7. All done solo with Claude Code.

How? The author built a production-grade infrastructure that transformed Claude Code into a systematic development powerhouse.

Below are the highlights - but seriously, go read the full post for all the implementation details.

The Disclaimer (But Read It Anyway)

Before we dive in, the original author emphasizes:

“All the content within this post is merely me sharing what setup is working best for me currently and should not be taken as gospel or the only correct way to do things. It’s meant to hopefully inspire you to improve your setup and workflows with AI agentic coding. I’m just a guy, and this is just like, my opinion, man.”

They’re on the 20x Max plan, working on production web apps professionally for 7+ years. This isn’t vibe-coding - it’s systematic collaboration with Claude through planning, reviewing, iterating, and exploring different approaches.

With that context: let’s see what six months of hardcore use taught them.

The Game Changer: Skills Auto-Activation System

This deserves top billing because it completely transformed their workflow.

The Problem with Skills (As Released)

Anthropic released the Skills feature with a compelling vision: portable, reusable guidelines that Claude can reference for maintaining consistency across large codebases.

The author spent significant time with Claude writing comprehensive skills:

Frontend development best practices
Backend development patterns
Database operations guidelines
Workflow management standards

Thousands of lines of carefully documented patterns and examples.

And Claude wouldn’t use them.

They’d use exact keywords from skill descriptions. Nothing. Work on files that should trigger skills. Nothing. The skills just sat there “like expensive decorations.”

The “Aha!” Moment: Hooks + Skills

“If Claude won’t automatically use skills, what if I built a system that MAKES it check for relevant skills before doing anything?”

Enter: TypeScript hooks + skills auto-activation architecture.

How the System Works

Hook #1: UserPromptSubmit (BEFORE Claude sees your message)

// Analyzes your prompt for:
- Keywords and intent patterns
- Which skills might be relevant
- Injects formatted reminder into Claude's context

Now when the author asks “how does the layout system work?” Claude sees a big reminder before even reading the question:

🎯 SKILL ACTIVATION CHECK
Use project-catalog-developer skill

Hook #2: Stop Event (AFTER Claude finishes responding)

// Analyzes which files were edited
// Checks for risky patterns (try-catch, database ops, async functions)
// Displays gentle self-check reminder

Example output:

Did you add error handling?
Are Prisma operations using the repository pattern?

Non-blocking. Just keeps Claude aware without being annoying.

The Configuration: skill-rules.json

Central configuration defining every skill with:

{
  "backend-dev-guidelines": {
    "type": "domain",
    "enforcement": "suggest",
    "priority": "high",
    "promptTriggers": {
      "keywords": ["backend", "controller", "service", "API", "endpoint"],
      "intentPatterns": [
        "(create|add).*?(route|endpoint|controller)",
        "(how to|best practice).*?(backend|API)"
      ]
    },
    "fileTriggers": {
      "pathPatterns": ["backend/src/**/*.ts"],
      "contentPatterns": ["router\\.", "export.*Controller"]
    }
  }
}

Keywords: Explicit topic matches Intent patterns: Regex to catch actions File path triggers: Activates based on edited files Content triggers: Activates if file contains specific patterns

The Results

Before skills + hooks:

Claude used old patterns even with documented new ones
Had to manually tell Claude to check guidelines every time
Inconsistent code across 300k+ LOC
Too much time fixing “creative interpretations”

After skills + hooks:

Consistent patterns automatically enforced
Claude self-corrects before code is even reviewed
Can trust guidelines are being followed
Way less time on reviews and fixes

As the author puts it:

“The difference is night and day. No more inconsistent code. No more ‘wait, Claude used the old pattern again.’ No more manually telling it to check the guidelines every single time.”

Following Anthropic’s Best Practices (The Hard Way)

After getting auto-activation working, they discovered Anthropic’s official recommendation: keep main SKILL.md files under 500 lines and use progressive disclosure with resource files.

Whoops. Their frontend-dev-guidelines skill was 1,500+ lines. Several others exceeded 1,000 lines.

So they restructured:

frontend-dev-guidelines: 398-line main file + 10 resource files
backend-dev-guidelines: 304-line main file + 11 resource files

Now Claude loads the lightweight main file initially, pulling detailed resource files only when actually needed.

Token efficiency improved 40-60% for most queries.

Their Complete Skills Lineup

Guidelines & Best Practices:

backend-dev-guidelines - Routes → Controllers → Services → Repositories
frontend-dev-guidelines - React 19, MUI v7, TanStack Query/Router patterns
skill-developer - Meta-skill for creating more skills

Domain-Specific:

workflow-developer - Complex workflow engine patterns
notification-developer - Email/notification system
database-verification - Prevent column name errors (this one actually blocks edits!)
project-catalog-developer - DataGrid layout system

All auto-activate based on what they’re working on.

“It’s like having a senior dev who actually remembers all the patterns looking over Claude’s shoulder.”

If you’re working on a large codebase with established patterns, the author cannot recommend this system enough. Initial setup took a couple of days, but it paid for itself ten times over.

Want the implementation details? The author shares the complete skill-rules.json structure, TypeScript hook code, and more in the full Reddit post and their GitHub repo.

The Dev Docs System (Preventing Claude’s Amnesia)

The author calls this their second most impactful change after skills.

“Claude is like an extremely confident junior dev with extreme amnesia, losing track of what they’re doing easily. This system is aimed at solving those shortcomings.”

The Three-File System

For every large task or feature, three files are created:

[task-name]-plan.md - The accepted plan
[task-name]-context.md - Key files, decisions, integration points
[task-name]-tasks.md - Checklist of work items

All stored in ~/git/project/dev/active/[task-name]/

Why This Matters

Before this system:

“I had many times when I all of a sudden realized that Claude had lost the plot and we were no longer implementing what we had planned out 30 minutes earlier because we went off on some tangent for whatever reason.”

After:

Claude stays on track even through auto-compaction
Can continue work in new sessions seamlessly
Clear record of decisions and progress
Easy to review and catch mistakes early

The Planning Process

Step 1: Always Start with Planning Mode

“Planning is king. If you aren’t at a minimum using planning mode before asking Claude to implement something, you’re gonna have a bad time, mmm’kay.”

The author created a strategic-plan-architect subagent that:

Gathers context efficiently
Analyzes project structure
Creates comprehensive structured plans (executive summary, phases, tasks, risks, success metrics, timelines)
Generates three files automatically

Also created a /dev-docs slash command with the same prompt for use on the main instance (since you can’t see agent output and agents die if you reject the plan).

Step 2: Review the Plan Thoroughly

“Take time to understand it, and you’d be surprised at how often you catch silly mistakes or Claude misunderstanding a very vital part of the request or task.”

Step 3: Create Dev Docs (Starting Fresh)

After exiting plan mode, they’re usually at 15% context or less. But that’s okay - everything needed to start fresh goes into dev docs.

When Claude tries to jump in guns blazing, hit ESC immediately and run /dev-docs to create the three files with proper context.

Step 4: Implement Section by Section

“Depending on the size of the feature or task, I will specifically tell Claude to only implement one or two sections at a time. That way, I’m getting the chance to go in and review the code in between each set of tasks.”

Periodically have a subagent review changes to catch big mistakes early.

Step 5: Update Dev Docs Before Compaction

Running low on context? Run /update-dev-docs. Claude notes relevant context with next steps and marks completed tasks before compacting.

Then in the new session: just say “continue.”

PM2 Process Management (Backend Debugging Game Changer)

The author’s project has seven backend microservices running simultaneously.

The Problem

Claude didn’t have access to view logs while services were running. They couldn’t just ask “what’s going wrong with the email service?” - Claude couldn’t see logs without manual copy-paste.

The Intermediate Solution

Each service wrote output to timestamped log files using a devLog script.

This worked… okay. Logs weren’t real-time, services wouldn’t auto-restart on crashes, and managing everything was a pain.

The Real Solution: PM2

PM2 changed everything. All backend services run via PM2 with a single command: pnpm pm2:start

What this gives:

Each service runs as a managed process with its own log file
Claude can read individual service logs in real-time
Automatic restarts on crashes
Real-time monitoring with pm2 logs
Memory/CPU monitoring with pm2 monit
Easy service management (pm2 restart email, pm2 stop all, etc.)

Example PM2 configuration:

// ecosystem.config.js
module.exports = {
  apps: [
    {
      name: 'form-service',
      script: 'npm',
      args: 'start',
      cwd: './form',
      error_file: './form/logs/error.log',
      out_file: './form/logs/out.log',
    },
    // ... 6 more services
  ]
};

The Debugging Workflow

Before PM2:

You: "The email service is throwing errors"
You: [Manually finds and copies logs]
You: [Pastes into chat]
Claude: "Let me analyze this..."

With PM2:

You: "The email service is throwing errors"
Claude: [Runs] pm2 logs email --lines 200
Claude: [Reads the logs] "I see the issue - database connection timeout..."
Claude: [Runs] pm2 restart email
Claude: "Restarted the service, monitoring for errors..."

Night and day difference. Claude can autonomously debug issues without you being a human log-fetching service.

One caveat: Hot reload doesn’t work with PM2, so they still run the frontend separately with pnpm dev. But for backend services, PM2 is incredible.

This is just scratching the surface. The author goes into much more detail about PM2 configuration, debugging workflows, and specific examples in the original Reddit post.

The Hooks System (#NoMessLeftBehind)

The author’s project is multi-root with ~8 repos. They’re constantly bouncing around making changes across multiple repos per feature.

The problem:

“One thing that would annoy me to no end is when Claude forgets to run the build command in whatever repo it’s editing to catch errors. And it will just leave a dozen or so TypeScript errors without me catching it.”

Then hours later:

“There are several TypeScript errors, but they are unrelated, so we’re all good here!”

“No, we are not good, Claude.”

Hook #1: File Edit Tracker

Post-tool-use hook that runs after every Edit/Write/MultiEdit operation, logging:

Which files were edited
What repo they belong to
Timestamps

Initially ran builds immediately after each edit, but that was “stupidly inefficient” (Claude makes edits that break things before quickly fixing them).

Hook #2: Build Checker

Stop hook that runs when Claude finishes responding:

Reads edit logs to find which repos were modified
Runs build scripts on each affected repo
Checks for TypeScript errors
If < 5 errors: Shows them to Claude
If ≥ 5 errors: Recommends launching auto-error-resolver agent
Logs everything for debugging

Result:

“Since implementing this system, I’ve not had a single instance where Claude has left errors in the code for me to find later. The hook catches them immediately, and Claude fixes them before moving on.”

Hook #3: Prettier Formatter ⚠️ (Updated)

Originally ran Prettier automatically after every response to format all edited files.

Update from original author: After publishing, readers shared data showing file modifications trigger <system-reminder> notifications that can consume significant context tokens. In some cases, Prettier formatting led to 160k tokens consumed in just 3 rounds due to system-reminders showing file diffs.

The author removed this hook from their setup. Not worth the token cost. Better to let formatting happen when you manually edit files anyway.

Hook #4: Error Handling Reminder

The “gentle philosophy hook”:

Analyzes edited files after Claude finishes
Detects risky patterns (try-catch, async operations, database calls, controllers)
Shows gentle reminder if risky code was written
Claude self-assesses whether error handling is needed
No blocking, no friction, just awareness

Example output:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📋 ERROR HANDLING SELF-CHECK
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

⚠️  Backend Changes Detected
   2 file(s) edited

   ❓ Did you add Sentry.captureException() in catch blocks?
   ❓ Are Prisma operations wrapped in error handling?

   💡 Backend Best Practice:
      - All errors should be captured to Sentry
      - Controllers should extend BaseController
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

The Complete Hook Pipeline

Here’s what happens on every Claude response:

Claude finishes responding
  ↓
Hook 1: File edit tracker logs changes
  ↓
Hook 2: Build checker runs → TypeScript errors caught immediately
  ↓
Hook 3: Error reminder runs → Gentle self-check for error handling
  ↓
If errors found → Claude sees them and fixes
  ↓
If too many errors → auto-error-resolver agent recommended
  ↓
Result: Clean, error-free code

And the UserPromptSubmit hook ensures Claude loads relevant skills BEFORE even starting work.

No mess left behind.

CLAUDE.md Evolution & Documentation Strategy

Six months ago, the author’s CLAUDE.md was “quickly getting out of hand and trying to do too much.” They also had a massive BEST_PRACTICES.md file (1,400+ lines) that Claude would “sometimes read and sometimes completely ignore.”

The Reorganization

What Moved to Skills:

Previously in BEST_PRACTICES.md:

TypeScript standards
React patterns (hooks, components, suspense)
Backend API patterns (routes, controllers, services)
Error handling (Sentry integration)
Database patterns (Prisma usage)
Testing guidelines
Performance optimization

Now all in skills with auto-activation hooks ensuring Claude actually uses them.

What Stayed in CLAUDE.md:

Now laser-focused on project-specific info (~200 lines):

Quick commands (pnpm pm2:start, pnpm build, etc.)
Service-specific configuration
Task management workflow (dev docs system)
Testing authenticated routes
Workflow dry-run mode
Browser tools configuration

The New Structure

Root CLAUDE.md (100 lines)
├── Critical universal rules
├── Points to repo-specific claude.md files
└── References skills for detailed guidelines

Each Repo's claude.md (50-100 lines)
├── Quick Start section pointing to:
│   ├── PROJECT_KNOWLEDGE.md - Architecture & integration
│   ├── TROUBLESHOOTING.md - Common issues
│   └── Auto-generated API docs
└── Repo-specific quirks and commands

The magic: Skills handle “how to write code” guidelines. CLAUDE.md handles “how this specific project works.” Separation of concerns for the win.

Documentation Philosophy

The author still has 850+ markdown files, but now they’re laser-focused on project-specific architecture rather than repeating general best practices better served by skills.

Documentation now works WITH skills, not instead of them:

“How to create a controller” → backend-dev-guidelines skill
“How our workflow engine works” → Architecture documentation
“How to write React components” → frontend-dev-guidelines skill
“How notifications flow through the system” → Data flow diagram + notification skill

For more on documentation strategy, including specific examples and the complete file structure, check out the full Reddit post.

Scripts Attached to Skills

One pattern picked up from Anthropic’s official skill examples: attach utility scripts to skills.

Example from backend-dev-guidelines:

### Testing Authenticated Routes

Use the provided test-auth-route.js script:

node scripts/test-auth-route.js http://localhost:3002/api/endpoint

The script handles all complex authentication steps:

Gets refresh token from Keycloak
Signs token with JWT secret
Creates cookie header
Makes authenticated request

When Claude needs to test a route, it knows exactly what script to use and how.

“No more ‘let me create a test script’ and reinventing the wheel every time.”

The author plans to expand this pattern - attach more utility scripts to relevant skills so Claude has ready-to-use tools instead of generating them from scratch.

Prompt Tips from the Trenches

Be Specific

“You wouldn’t ask a builder to come out and build you a new bathroom without at least discussing plans, right?

‘You’re absolutely right! Shag carpet probably is not the best idea to have in a bathroom.’”

When you don’t know the specifics, tell Claude to research and come back with several potential solutions. Use specialized subagents or other AI chat interfaces for research.

Don’t Lead

Try not to lead in your prompts if you want honest, unbiased feedback.

Bad: “Is this good or bad?” Good: Describe the situation neutrally and ask for thoughts or alternatives.

“Claude tends to tell you what it thinks you want to hear, so leading questions can skew the response.”

Sometimes You Just Need to Step In

“Look, AI is incredible, but it’s not magic. There are certain problems where pattern recognition and human intuition just win. If you’ve spent 30 minutes watching Claude struggle with something that you could fix in 2 minutes, just fix it yourself. No shame in that.”

Logic puzzles and problems requiring real-world common sense are prime examples.

“Don’t let stubbornness or some misguided sense of ‘but the AI should do everything’ waste your time. Step in, fix the issue, and keep moving.”

Re-prompt Often

You can hit double-ESC to bring up previous prompts and branch from one.

“You’d be amazed how often you can get way better results armed with the knowledge of what you don’t want when giving the same prompt.”

Self-Reflect Before Blaming the Model

The author had their share of terrible prompting, usually towards the end of the day when getting lazy and not putting effort into prompts. And the results showed.

“So next time you are having these kinds of issues where you think the output is way worse these days because you think Anthropic shadow-nerfed Claude, I encourage you to take a step back and reflect on how you are prompting.”

As some wise dude somewhere probably said:

“Ask not what Claude can do for you, ask what context you can give to Claude” ~ Wise Dude

The Holy Trinity: Agents, Hooks, and Slash Commands

Agents (The Specialized Army)

Quality Control:

code-architecture-reviewer - Reviews code for best practices
build-error-resolver - Systematically fixes TypeScript errors
refactor-planner - Creates comprehensive refactoring plans

Testing & Debugging:

auth-route-tester - Tests backend routes with authentication
auth-route-debugger - Debugs 401/403 errors and route issues
frontend-error-fixer - Diagnoses and fixes frontend errors

Planning & Strategy:

strategic-plan-architect - Creates detailed implementation plans
plan-reviewer - Reviews plans before implementation
documentation-architect - Creates/updates documentation

Specialized:

frontend-ux-designer - Fixes styling and UX issues
web-research-specialist - Researches issues on the web
reactour-walkthrough-designer - Creates UI tours

The key: Give agents very specific roles and clear instructions on what to return.

“I learned this the hard way after creating agents that would go off and do who-knows-what and come back with ‘I fixed it!’ without telling me what they fixed.”

Hooks (The Quality Guardrails)

Without hooks:

Skills sit unused
Errors slip through
Code inconsistently formatted
No automatic quality checks

With hooks:

Skills auto-activate
Zero errors left behind
Automatic formatting (updated: removed Prettier hook due to token cost)
Quality awareness built-in

Slash Commands (The Productivity Boosters)

Most Used Commands:

Planning & Docs:

/dev-docs - Create comprehensive strategic plan
/dev-docs-update - Update dev docs before compaction
/create-dev-docs - Convert approved plan to dev doc files

Quality & Review:

/code-review - Architectural code review
/build-and-fix - Run builds and fix all errors

Testing:

/route-research-for-testing - Find affected routes and launch tests
/test-route - Test specific authenticated routes

“The beauty of slash commands is they expand into full prompts, so you can pack a ton of context and instructions into a simple command. Way better than typing out the same instructions every time.”

Tools That Complete the System

SuperWhisper (Mac): Voice-to-text for prompting when hands are tired from typing. Claude understands rambling voice-to-text surprisingly well.

Memory MCP: Used less over time now that skills handle “remembering patterns,” but still useful for tracking project-specific decisions and architectural choices that don’t belong in skills.

BetterTouchTool:

Relative URL copy from Cursor for sharing code references
Double-tap CAPS-LOCK → copies relative URL, prepends ’@’, focuses terminal, pastes
Double-tap hotkeys to focus apps (CMD+CMD = Claude Code, OPT+OPT = Browser)
Custom gestures for common actions

“Honestly, the time savings on just not fumbling between apps is worth the BTT purchase alone.”

Scripts for Everything:

Command-line tool to generate mock test data
Authentication testing scripts (get tokens, test routes)
Database resetting and seeding
Schema diff checker before migrations
Automated backup and restore for dev database

Pro tip: When Claude helps write a useful script, immediately document it in CLAUDE.md or attach it to a relevant skill. Future you will thank past you.

The Real Talk: Quality and Consistency

The author acknowledges recurring themes in forums: frustration with usage limits, concerns about declining output quality.

“I want to be clear up front: I’m not here to dismiss those experiences or claim it’s simply a matter of ‘doing it wrong.’ Everyone’s use cases and contexts are different, and valid concerns deserve to be heard.”

But their experience:

“CC’s output has actually improved significantly over the last couple of months, and I believe that’s largely due to the workflow I’ve been constantly refining.”

The Reality of Stochastic Models:

Sometimes Claude completely misses the mark for various reasons:

Stochastic randomness: Sometimes you get poor quality through no fault of your own
Prompt structure: Slight wording differences can lead to vastly different outputs
Ambiguous phrasing: Misword something, get inferior results

The author’s confession:

“I’ve had my fair share of terrible prompting, which usually happens towards the end of the day where I’m getting lazy and I’m not putting that much effort into my prompts. And the results really show.”

The System in Action: What It Enables

This infrastructure enabled one developer to:

Solo rewrite 300-400k LOC in 6 months, transforming:

React 16 JS → React 19 TypeScript
React Query v2 → TanStack Query v5
React Router v4 w/ hashrouter → TanStack Router w/ file-based routing
Material UI v4 → MUI v7
ZERO test coverage → Decent test coverage
Insurmountable tech debt → Manageable tech debt
HORRIBLE developer experience → Command-line tools for test data generation + dev mode

From a project with “insurmountable tech debt” to production-ready code with:

Strict adherence to best practices
Comprehensive test coverage
Excellent developer experience
All sorts of jank… gone

And the author’s life expectancy? ~5 years shorter. But they’re “incredibly happy with how things have turned out.”

The Essentials vs. Nice-to-Haves

The Essentials:

Plan everything - Use planning mode or strategic-plan-architect
Skills + Hooks - Auto-activation is the only way skills work reliably
Dev docs system - Prevents Claude from losing the plot
Code reviews - Have Claude review its own work
PM2 for backend - Makes debugging actually bearable

The Nice-to-Haves:

Specialized agents for common tasks
Slash commands for repeated workflows
Comprehensive documentation
Utility scripts attached to skills
Memory MCP for decisions

Read the Full Story

This summary only scratches the surface of what the author shares. The original Reddit post contains:

Complete code examples for hooks and skills
Detailed TypeScript hook implementations
Full skill-rules.json configuration
Specific prompt templates
Real-world examples from their 300k LOC project
The author’s full context and reasoning
Community discussion and Q&A

Plus, check out their GitHub repository with working implementation examples.

Key Takeaways (From This Summary)

This system isn’t about using Claude Code “the right way.” It’s about building infrastructure that gives Claude the best possible chance to succeed:

Context through comprehensive docs and skills
Guardrails through hooks and automated checks
Clarity through dev docs and systematic planning
Specialization through domain-specific agents
Consistency through auto-activation and quality checks

The result? One developer solo rewrote 300k lines of code in 6 months with consistent quality.

If you’re working on large codebases or ambitious projects with Claude Code, this system is worth studying. But don’t just read this summary - go read the full Reddit post for all the implementation details and the author’s complete insights.

All credit goes to u/JokeGold5455 for this incredible write-up. This blog post is simply highlighting key points to encourage you to explore their work.

Original Reddit Post: Claude Code is a Beast – Tips from 6 Months of Hardcore Use

GitHub Repository: claude-code-infrastructure-showcase

Further Reading: