Why Use a Boilerplate When AI Can Write Code? A Head Start, Not a Constraint

It’s a fair question: if a coding agent can generate almost anything on demand, why start from a boilerplate at all? The honest answer flips the old worry on its head. A template used to feel like a constraint — a box you’d eventually have to break out of. With an agent in the loop it’s the opposite: a good boilerplate is a head start the AI builds on, not a cage it has to escape. It doesn’t compete with the agent; it’s what makes the agent fast.

What AI is genuinely great at

Modern agents are excellent at working within an existing, well-structured codebase: add an endpoint that mirrors the three next to it, write a migration, wire a new billing tier, refactor across files. Given a pattern to follow, they’re fast, consistent, and rarely wrong. That’s the sweet spot.

Generating the foundation — the part with no pattern to copy yet — is where the same agent struggles. Not because it can’t produce the code, but because the foundation is all cross-cutting decisions: how auth tokens flow to the API, how webhooks update entitlements, how stacks deploy in order, which database quirks to design around. Each choice constrains the next, and a model making them fresh, in one long session, drifts.

A boilerplate isn’t a constraint — it’s a head start

The old objection to templates was that they boxed you in: someone else’s structure you’d eventually have to fight or break out of. With an agent in the loop, that worry inverts. A template isn’t a cage the AI has to escape — it’s a map of the codebase the AI builds on: consistent structure, naming, and conventions it can extend or tear out at will.

Want to add a feature? The agent copies the pattern of the three next to it. Want to drop one? “Delete this stack and its folder” is a far cleaner instruction than “untangle the thing you generated three sessions ago.” The template is just the starting state the agent edits — and because the agent can rewrite any of it, you get the head start without inheriting a constraint. That’s the whole case in a line: a boilerplate doesn’t compete with the AI; it’s what makes the AI fast.

Why that head start beats generating a foundation from scratch comes down to three practical things — tokens, context, and the parts you don’t want a model improvising.

The token math

Scaffolding a real serverless SaaS from zero with an agent isn’t one prompt — it’s a long chain of generate → run → hit an integration error → paste the error back → regenerate. Every loop spends tokens, and the expensive part isn’t the code it writes, it’s the rediscovery: re-deriving the same Cognito-cookie pattern, the same Stripe webhook idempotency, the same DSQL retry loop that thousands of projects have already settled.

• From scratch: tokens go to inventing and debugging boilerplate you could have downloaded — auth plumbing, deploy config, the glue between services.
• From a template: the same tokens go to your product — the feature that makes the app yours, built on a substrate that already deploys.

It’s the difference between paying an agent to re-solve solved problems and paying it to solve yours. A template front-loads the solved part for free.

The context-window problem

There’s a subtler cost than tokens. An agent’s context window is finite, and it’s the most valuable real estate you have. When the agent builds the foundation itself, that window fills with scaffolding — half-written auth, deploy errors, config it’s still reasoning about. By the time you get to your actual feature, the context is cluttered and the model’s attention is split.

Start from a working template and the foundation lives on disk, not in the conversation. The agent reads only the part it needs, and the whole context budget goes to the problem you actually care about. A clean substrate is a multiplier on every prompt that follows.

Determinism where it matters

Some parts of a SaaS are unforgiving: token handling, webhook signature verification, IAM scoping, anything touching money or identity. You want these to be known-good and battle-tested, not freshly generated and probably-fine. A maintained boilerplate is code that’s been deployed, reviewed, and corrected. Letting an agent improvise the security-critical glue every time is exactly where “probably fine” becomes a 2 a.m. incident.

Use the agent for what changes between projects. Use a template for what shouldn’t.

The actual best workflow

It’s not template or AI. It’s template then AI:

1. Start from a foundation that already deploys end to end.
2. Point the agent at it with an operating manual it can read — structure, conventions, gotchas.
3. Spend every token from there on your product, on a substrate that can’t regress the basics.

That’s the entire bet behind cdkbase: a fork-ready AWS serverless stack that’s shaped, documented, and conventionalized so the AI starts at the interesting part instead of reinventing the boring, dangerous 90%.

Built for the Claude Code agent, not just compatible with it

“AI-friendly” usually means nothing more than clean code. cdkbase goes further: it’s built specifically for Claude Code, the agent, with the things an agent actually needs to operate a codebase shipped in the repo:

• A Claude Code skill — an operating manual the agent reads before it touches anything: the stack topology, the deploy commands, the auth patterns, and the gotchas (DSQL retries, certificate ordering) that would otherwise cost a session to rediscover. The agent starts already knowing the codebase.
• Bundled AWS MCP servers — the config for AWS Labs’ Model Context Protocol servers ships in the repo: AWS documentation and knowledge, IaC, CloudFormation and CDK, Lambda, the AWS API (to connect to and act on your account), cost analysis, and Aurora DSQL. Claude consults authoritative AWS sources and operates your infrastructure directly instead of guessing from memory.
• A deployable MCP endpoint of its own — beyond the build-time tooling, the template ships its own MCP server as a first-class stack (in two patterns: straight to the database, or through the API), so the app you deploy can expose its data and actions to agents over MCP out of the box.
• Conventions the agent can rely on — predictable structure and naming across every stack and app, so “add a feature like the others” or “remove this one cleanly” are one-line instructions with one obvious interpretation.

The result is that from the first session, Claude Code can deploy stacks, query your database, and extend the app — because the template was designed for exactly that agent to drive it, not merely to be readable by one.

A template you own, not a framework you depend on

There’s an important distinction baked into all of this: cdkbase is a starting point you own, not a framework you build on top of. A framework inserts itself between you and the platform — its own abstractions, its own lifecycle, its own magic — and you write code the way it wants. When it doesn’t do what you need, you fight it or wait for a release.

cdkbase deliberately goes the other way: minimal dependencies, minimal abstractions, AWS primitives used directly. Auth is the clearest example — it talks to Cognito through the AWS SDK for JavaScript (v3) Cognito client, plain documented API calls, rather than wrapping it in a heavier layer like Amplify. The auth package has a single runtime dependency and does exactly what it appears to do, with nothing hidden.

That thinness pays off twice:

• You own it. There’s no framework version to chase and no abstraction to outgrow. The code is yours to read, change, or delete — when requirements diverge from the template, you edit the template, you don’t fight a dependency.
• The agent can see all of it. An AI agent reasons far better about a direct SDK call than about framework magic it has to infer. Fewer layers means Claude — and you — can follow any behavior straight down to the AWS API it ultimately calls, which is exactly what makes the agent reliable at extending it.

It’s the opposite of a black box: a thin, legible foundation you and your agent fully control. (It’s a deliberate design choice worth its own discussion — template vs. framework.)

“But won’t a whole stack cost a fortune to run?”

The instinct is that a full template — database, API, auth, billing, three frontends — means a pile of always-on infrastructure racking up a bill while you’re still building. With a serverless stack it’s the opposite: the expensive pieces scale to zero, so a fully deployed environment sitting idle costs about $0.50 a month — basically just the Route 53 hosted zone. You’re not paying to keep the boilerplate warm; the full stack costs you tokens to build on, not dollars to hold. (The full line-by-line breakdown is its own post: what it costs to run a serverless SaaS.)

When you genuinely don’t need one

Templates aren’t universal. If you’re building a throwaway prototype, learning the stack on purpose, or your app is small enough that there’s barely any foundation to share, generating from scratch is fine — even ideal. The math flips when the foundation is large, security-sensitive, and identical to everyone else’s: that’s precisely when re-deriving it with an agent is the costly path.