Efficiency Patterns

Problem: Shipping near-identical features one at a time burns hours and leaves the code inconsistent between rounds.

Quick Win: Paste this block into your CLAUDE.md. Consistency lifts the moment Claude reads it:

# Component Generation Framework
 
When creating new [cards/forms/modals], follow the pattern in /components/examples/:
 
1. Copy the closest existing example
2. Replace data fields (keep structure identical)
3. Update types to match new data model
4. Run existing tests as template for new tests

A short rule like this stops Claude from reinventing patterns that already exist in your repo.

What Permutation Frameworks Are

A permutation framework is a trick. Hand-build 8 to 12 close-sibling features, then write a CLAUDE.md template that lets Claude spin up variation 11, 12, and 13 from the same mold. The pattern is captured once. Claude fills in everything else.

Your role shifts. You stop coding each feature and start reviewing the variations Claude drew from a known-good blueprint.

The Three Phases

Phase 1: Manual Foundation Building

Begin by coding 8 to 12 close-sibling features yourself. As you go, write down every decision, pattern, and constraint. That record becomes the reference library Claude learns from later on.

# Track your patterns
mkdir patterns/user-interfaces
# Build: LoginForm, SignupForm, ProfileForm, etc.
# Document decisions in each component

A SaaS dashboard with a handful of data tables makes it concrete. UsersTable, OrdersTable, InvoicesTable, ProductsTable. Build the first three by hand. Round after round, the same decisions resurface: column shape, sort handler signature, pagination component, empty state layout, loading skeleton.

By round three you can name what moves between instances (column definitions, data types, API endpoint) and what stays pinned (table wrapper, pagination logic, sort state, row selection). That inventory feeds Phase 2.

Before (building each table from scratch):

// Each table re-implements pagination, sorting, selection...
// UsersTable: 180 lines
// OrdersTable: 195 lines (slightly different pagination)
// InvoicesTable: 210 lines (different sort logic)

After (pattern extracted):

// Shared DataTable component: 120 lines
// UsersTable config: 35 lines (just column definitions + endpoint)
// OrdersTable config: 40 lines
// InvoicesTable config: 38 lines

Phase 2: Pattern Recognition and Templating

Comb back through the manual builds and extract:

• Repeated code structures that show up in every implementation
• Variable elements that shift from one instance to the next
• Quality guardrails (type safety, accessibility, test coverage)
• Checks that confirm each new variation actually works

Now write a CLAUDE.md section that encodes those patterns with real examples of what passes and what does not. The trick is concreteness. Skip "follow existing patterns." Point directly at files: "use the exact prop interface from UsersTable.tsx lines 12-28, replacing the entity type."

Weak framework instruction:

Create new table components following existing patterns.

Strong framework instruction:

# Data Table Framework
 
Reference: /components/tables/UsersTable.tsx (canonical)
 
To create a new [Entity]Table:
 
1. Props: { columns: ColumnDef<Entity>[], endpoint: string, defaultSort: SortConfig }
2. Use DataTable wrapper from /components/shared/DataTable.tsx
3. Column definitions follow the format in UsersTable lines 12-28
4. Include loading skeleton matching the column count
5. Empty state uses /components/shared/EmptyState.tsx with entity-specific message
6. Tests: copy UsersTable.test.tsx, replace User fixtures with [Entity] fixtures

Specificity is the whole difference. The strong version names exact files, line numbers, and shared components. Claude has nothing to guess. It walks a verified path instead.

Phase 3: Automated Generation

Now use the framework. Start on the easy cases and let the difficulty climb as Claude proves it stays inside your constraints.

The first generated variation almost never comes back perfect. Diff it line-by-line against your manual examples and you'll find one or two spots where the framework wasn't specific enough. Tighten those spots, generate again, and repeat. After three or four passes the framework outputs code that clears review without hand edits.

Framework Refinement Strategies

Constraint-Based Quality Control

Tight framework rules narrow Claude's creative range without killing useful variation. Spell the constraints out inside CLAUDE.md:

CONSTRAINTS:
 
- All components must include PropTypes / TypeScript interfaces
- Use established naming conventions (camelCase for props)
- Include accessibility attributes (aria-label, role, tabIndex)
- Follow existing file structure in /components/
- Every new component gets a co-located test file

Variance Testing

Stress-test the framework by generating 5 to 10 variations and lining them up side by side. If they drift too much, go back and add sharper examples and stricter constraints to the CLAUDE.md template.

A concrete run with an API endpoint framework showed the problem. Across the first 3 generated endpoints, error handling held steady but response shapes diverged. One came back as { data: ... }. Another wrapped the payload as { result: ... }. The third returned the raw object with no wrapper at all. One new line in the framework fixed everything: "All endpoints return { data: T, error: null } or { data: null, error: ErrorShape }." Variance vanished from the next 8 generations.

Iterative Improvement

Every framework pass sharpens two things at once: how closely Claude holds your pattern, and how clearly you understand what makes AI-generated code reliable.

Permutation Framework in Action

A concrete run-through. Say you built UserCard, ProductCard, and OrderCard by hand. You drop this into CLAUDE.md:

# Card Component Framework
 
Reference: /components/cards/UserCard.tsx (canonical example)
 
To create a new [Entity]Card:
 
1. Props: { data: [Entity], onClick?: () => void, variant?: 'compact' | 'full' }
2. Structure: Avatar/Icon + Title + Subtitle + Action buttons
3. Styling: Use existing Tailwind classes from UserCard
4. Tests: Copy UserCard.test.tsx, replace User with [Entity]

Ask Claude to "create a SubscriptionCard" and the output snaps to the same shape. Same prop structure, same styling approach, same test coverage. You could not tell it from one of the hand-built cards, because it came off the same blueprint.

Common Efficiency Patterns

API Endpoints: Frameworks for routes with matched error handling, validation, and response shapes. Lock down your Zod schema pattern, your error response format, and your middleware chain once apiece. A new endpoint collapses from an hour down to 15 minutes.

UI Components: Frameworks for design-system components handling different data types. The card example above carries straight across to modals, forms, list items, and detail views. If a component already exists in 3+ flavors, it qualifies as framework material.

Database Operations: Frameworks for CRUD with shared transaction handling across models. Define the query builder, the pagination approach, and the soft-delete behavior once. New models drop in on the same rails.

When NOT to Build a Framework

Frameworks are not free. Overbuilding one costs you, the same way overbuilding code does.

One or two examples is too few. Three hand-built versions is the floor. At two, the framework locks onto those exact cases and does not generalize.

Skip frameworks for one-off features. A single custom admin dashboard with no cousins only adds overhead and repays nothing. Keep the framework budget for patterns that repeat.

Wait until patterns stabilize. In a project's first month, component shapes shift week by week. A rigid template locked in on week one means rework on week two. Settle the shape through 8 to 10 hand builds first.

Avoid over-constraining. If the rules are so tight Claude can't handle real variation, the framework costs more than it gives back. Good constraints lock structure and leave breathing room for entity-specific details.

Success Metrics for Frameworks

Watch these indicators to confirm the framework is earning its keep:

• Consistency Score: Do generated variations line up with your hand-built examples on imports, prop shapes, and file layout? A healthy framework scores high on structural match.
• Implementation Speed: A tuned framework noticeably shortens the path from request to working feature. No real speedup means more detail is needed, or the patterns aren't locked in yet.
• Review Time: How long does a validation pass take? That number should drop as the framework matures. Early output wants careful review. Mature output only needs a quick read for correctness.
• Bug Frequency: Compare bugs per generated variation against bugs per hand-built feature. A good framework lowers the count because it bakes in patterns you already field-tested.

From Linear to Exponential Scaling

Classic development scales linearly. One developer produces one feature at a time. Permutation frameworks rewrite that math. A single framework produces many variations, and your velocity climbs.

The payoff is biggest in codebases where repeated patterns serve different users but share the same technical mold. Returns compound from there. Once you have frameworks for components, API endpoints, and database operations in place, a new feature that spans all three layers ships in a fraction of the old time, because each layer already has its blueprint waiting.

Next Actions:

1. Today: Scan your repo for 3 close-sibling components. Cards, forms, and modals are the cleanest places to start.
2. This week: Turn those siblings into your first framework by writing down exactly what holds constant between them.
3. Deep dive: Study the CLAUDE.md techniques that make framework documentation effective.
4. Related: Reach for planning modes when a framework request gets complex.
5. Optimize: Use model selection strategies to tune cost against quality.
6. Automate: Set up feedback loops so improvements compound over time.
7. Experiment: Run systematic variance tests to confirm the framework's output holds up.