The Expandable Core, explained

The fastest way to ruin a codebase with AI is to treat it as one undifferentiated mass. Some files churn weekly — feature pages, copy, ad-hoc forms — and it doesn't matter much if Claude generates them in three different styles. Other files don't churn at all, but everything else depends on them. The data model. The auth layer. The deploy pipeline.

We call those the Expandable Core. The bet is simple: AI-generated feature code can be sloppy, because it ships and gets replaced. Core code can't, because everything written next has to live on top of it.

What goes in the registry

On kickoff we sit with you and write the Expandable Core Registry — a markdown file that lives in your repo. Each entry names the file, the table, or the contract, plus a one-line "why this is core." Five categories cover most repos:

• Data model. The shape of your database. Migrations, schemas, anything that defines what a row of your business looks like.
• Auth & access layer. Who can do what. Policies, middleware, session logic.
• Core API contracts. The interfaces your services use to talk to each other. Once published, breaking them is expensive.
• Integration points. Payments, AI models, third-party APIs. The blast radius of a bug here is "we lose money" or "we lose users."
• Deploy paths. CI/CD, environment configuration, the scripts that actually push code to production.

Anything in the registry gets the arch-review tag automatically when a PR touches it. The Code Review Agent flags it. A senior engineer reads every line.

Anything not in the registry gets reviewed for security and obvious bugs, but we don't sweat style or duplication. If it works and ships, it's done.

Why this works with Claude

Claude is great at feature code. Give it a clear prompt, the right context, and a working example, and it ships in minutes what would take an engineer hours. The bottleneck isn't Claude; it's the architecture decisions Claude can't make for you — the ones that need someone who's seen the repo evolve over a year.

The registry is how we keep those decisions in human hands. Founders code at the keyboard. Claude generates. The registry is the line we don't cross without a senior engineer in the loop.

What it looks like in practice

Week 1 of every engagement, we write the registry together. By Friday it's checked in. From that point forward:

1. You ship features fast in Claude — no friction, no architecture meetings for routine work.
2. PRs that touch core auto-route to a senior reviewer with a 24-hour SLA.
3. ADRs (architecture decision records) drop automatically into docs/adr/ whenever the registry changes — so six months from now, you can read why.

The registry is short on purpose. Most repos end up with 8–15 entries. If you find yourself writing 50, you're using it wrong: the point is what we protect, not everything we have.

---

If you want to see what your registry would look like, send us repo access. We do a free audit and ship you a draft within five business days. No commitment.