AI Agent Boilerplate

An ordinary starter is easy to judge at first: install it, run it, and see how much setup disappeared. An AI agent boilerplate needs another test once coding agents begin making real changes.

Can the agent discover how this repository works without inventing an architecture? Can it change one feature without opening unrelated parts of the application? Can it run the relevant checks while the edit is still in context?

That is where Hype Stack fits. It is a full-stack codebase with project rules, installed skills, vertical feature folders, and compiled lint and typecheck tools. The sections below examine each part before looking at a specific template built on top of them.

Three tests for a good AI template

The useful definition is smaller than most feature lists. A template built for coding agents needs three things:

The three reinforce each other. Rules define the path. Vertical features keep that path short. Fast checks tell the agent when it stepped off.

Rules should describe this codebase, not software in general

Telling an agent to "write clean code" costs tokens and changes nothing. It already saw that sentence in its training data. A useful rule records a decision it could not infer safely.

Hype Stack ships those decisions in .cursor/rules. Backend errors bubble to one middleware. Page routes return a breadcrumb from their loaders. Frontend requests go through the typed SDK rather than raw fetch. The repository also intends feature modules to call functions in db/queries and db/mutations instead of importing the database client.

The strongest rules do not stop at prose:

Skills handle a different job. A rule says what must remain true. A skill is a procedure for doing a particular kind of work, such as reviewing a pSEO page or creating an installable pack. Procedures can change upstream, so Hype Stack pins installed skills by repository and content hash in skills-lock.json. An update arrives as a diff you review, not as a new set of instructions silently entering the next agent session.

Premade rules and skills are not magic context. Some will be wrong for your product. Their value is that the template starts with one coherent opinion, every exception is visible, and the mechanical parts can be checked.

The checks are not complete. The database restriction currently rejects imports from @backend/db/postgres, but a module can still reach the same client through @backend/context. Several organization invitation modules do exactly that. The rule records the intended boundary, but the lint pattern needs widening before it enforces that boundary.

A vertical codebase fits the task into context

The phrase "vertical codebase" comes from TkDodo's article of the same name. The core idea is direct: organize by what the application does, not only by what kind of file something is.

That distinction matters more when an agent is reading the repository. Imagine asking it to change how organization invitations are resent. In a layer-first codebase, the relevant route, service, email, schema, test, and shared types may sit in distant trees. The agent searches broadly, loads near matches, and has to infer which abstraction is current.

In Hype Stack, the operation has a neighborhood:

This does not mean every file sits in one folder. Prisma schemas stay split by feature so the agent can see relations and cascade behavior without a live production database. Shared database helpers and routes still have their own locations. Vertical architecture is not "put everything together." It is "make the path through one feature obvious."

That path is also easier for a human to review. A new operation arriving as one folder has a visible edge. The same change scattered across generic service files looks like six unrelated edits until the reviewer reconstructs the task.

The Vite/Oxc toolchain changes the feedback loop

An agent works in a loop: read, edit, check, repair. The duration of the check affects how often the last two steps happen.

Hype Stack uses Vite 8 with Rolldown and Oxc underneath, oxlint and oxfmt for linting and formatting, and the Go-native TypeScript compiler (tsgo) for typechecking. We ran both toolchains across the same repository:

The difference changes working behavior. A check that finishes while the edit is still fresh is practical to run after small changes. A longer check is more likely to run after a batch, which means the agent receives feedback several edits after the mistake that caused it.

Fast tools alone do not make an AI template good. A fast lint run that only catches syntax is still weak. Here oxlint runs the ordinary lint rules and custom checks such as rules/no-json-error-response; tsgo runs afterward as a separate typecheck. Re-run both on your own machine and project before using these numbers for a tooling decision.

What Aether adds on top of a free chat kit

Aether is the concrete example: an AI product shell with React and Hono, auth, organizations, Stripe billing, an admin app, and a chat interface.

Its chat surface uses Vercel AI Elements, an Apache-2.0 licensed component library. You can install it for free. If all you need is a prompt input, model selector, reasoning panel, and tool-call cards, use that library and stop there.

The template is for the larger job:

That last row is the boundary that matters. Aether's chat runs on scripted data and carries a visible mockup banner. There is no hidden endpoint waiting for an API key. The template cannot know whether your product reviews contracts, runs support workflows, searches medical literature, or operates a browser. That behavior is your product.

The verdict

Judge an AI agent boilerplate with a test more demanding than pnpm dev.

Give a coding agent one realistic change. Watch how much of the repository it has to read. Check whether project rules name decisions that matter, whether those decisions fail mechanically, and whether the complete check is fast enough to run before the agent loses the thread.

Aether gives that test a credible starting point:

• Premade, opinionated rules and versioned skills tell the agent how this repository works.
• Vertical feature folders keep related operations and tests near each other.
• oxlint, oxfmt, tsgo, and custom lint checks provide the verification tools.

It is not finished. The database import restriction has a hole, and the actual check duration needs measuring after installation. It also does not give you the agent your customers will use. It gives you the application around that agent and a repository with explicit guidance for coding agents. Whether that is the right division depends on how much of the customer-facing agent you already know how to build.