Stop Paying AI to Forget What You Already Know

I'm currently building many apps/things in parallel: a form backend, a WhatsApp review alert tool, my WordPress plugins and a few others. Every single one needs Stripe. Every single one needs transactional emails. Most of them use Cloudflare Workers, D1, and R2.

For a while, I let AI write those integrations from scratch every time.

That was expensive. And dumb.

What Was Actually Happening

When you ask Claude Code (or any coding AI) to "integrate Stripe checkout," it doesn't teleport to a finished implementation. It explores. It writes, evaluates, adjusts. It handles errors, then reconsiders the error handling. It figures out where to put the webhook handler, what metadata to attach, how to structure the response.

All of that costs tokens. And time.

Now multiply that by every project. Every time I started something new, the AI was rebuilding the same mental model for integrations I had already solved.

The code usually came out fine. But I was paying in tokens and in review time for decisions that were already made.

The Fix: ai-boilerplates

I created a private repo called ai-boilerplates. The idea is simple: every integration pattern I've solved and validated goes in there, ready to be used as a reference.

ai-boilerplates/
  stripe/
    checkout.ts
    webhook.ts
    customer.ts
  resend/
    transactional.ts
  cloudflare/
    d1-client.ts
    r2-upload.ts
  auth/
    jwt.ts
    session.ts

But the important part isn't just the code. It's the context block at the top of each file:

/**
 * BOILERPLATE: Stripe Checkout Session
 *
 * Use: single product or dynamic price_id checkout
 * Don't use: subscriptions (see stripe/subscription.ts)
 *
 * Decisions already made:
 * - success_url always redirects to /dashboard with session_id
 * - metadata always includes userId to reconcile in webhook
 * - errors return 500 with generic message, never expose Stripe details
 */

That block is the real value. The AI doesn't just copy code. It understands intent, constraints, and prior decisions. It skips the exploration phase entirely.

Wiring It Into Claude Code

I added a dedicated rule file at ~/.claude/rules/ai-boilerplates.md:

## ai-boilerplates

Repo at ~/ai-boilerplates/ contains standard boilerplate implementations.

Before implementing any new integration, check if a boilerplate exists.
If it does, use it as the base, don't rewrite from scratch.

When using a boilerplate:
- Adapt to the project context, don't copy blindly
- Preserve the documented decisions
- If you need to deviate from a decision, comment why in the code

When writing code that could become a boilerplate, suggest adding it to the repo.

Keeping it in rules/ rather than CLAUDE.md is intentional. CLAUDE.md is for general project context: stack, conventions, who you are. Rules are modular and focused, each with a single responsibility.

Now every Claude Code session across every project starts with that context loaded. The AI knows to check before it builds.

What Changed

The difference is noticeable in a few ways:

Fewer tokens on solved problems. The AI isn't re-exploring Stripe webhook verification or Resend error handling. It reads the boilerplate, adapts it, moves on.

More consistent code across projects. The same decisions (metadata structure, error response shape, logging pattern) show up the same way everywhere. That matters when you're context-switching between four codebases.

Less review time. I'm not second-guessing whether the AI made the right call on something I've already thought through. The call was made once, documented, and that's it.

The Cost Angle Is Real

AI inference isn't free, and it's only going to get more complex as agents and subagents become the norm. Running parallel agents on a large feature already costs real money. Anything that reduces redundant work compounds across every session, every project, every team member who touches the same stack.

A boilerplate repo is one of the cheapest optimizations you can make. It costs you an hour to set up and pays back on every single integration after that.

What Goes In a Good Boilerplate

Not every piece of code deserves to be a boilerplate. A good candidate is something you:

1. Integrate in more than one project
2. Have already debugged at least once
3. Have made explicit architectural decisions about

If all three are true, document it. If you're just writing throwaway code, don't bother.

Context Is the Real Asset

Most developers think about AI productivity in terms of prompts: how to ask better questions, how to get better output. That's valid, but it misses the bigger lever.

The real asset is structured context. Boilerplates are one layer. ADRs are another. Rules that encode how your team works, shared memory of why decisions were made. When that context exists and is loaded into every session, the AI isn't starting from scratch. It's building on top of what you've already figured out.

That compounds. Every solved problem makes the next one cheaper. Every documented decision saves tokens, review time, and the cognitive overhead of explaining your conventions again.

A ai-boilerplates repo is a small, concrete place to start. But the habit it builds is what matters.