I'm building Guren, a fullstack TypeScript framework for the AI-agent era

Daiki Urata — Wed, 19 Aug 2026 12:22:30 +0000

Guren is a fullstack TypeScript framework for Bun. I started it because I wanted Laravel's shape in TypeScript, and I kept going for a different reason: once I was handing most of the code to agents, what I wanted from a framework was a way to check what came back.

gurenjs / guren

Guren is a Bun-native TypeScript MVC framework that unites Laravel-like ergonomics with Hono, Inertia.js, React, and Drizzle ORM, aiming to deliver a fast, elegant full-stack workflow that keeps frontend and backend work in sync.

Guren

The fullstack TypeScript framework for the AI-agent era.

Laravel-style conventions, end-to-end type safety, and built-in agent introspection and verification — routing, controllers, ORM, authentication, and Inertia.js + React in one cohesive experience that humans and AI coding agents navigate from the same map.

v2 — Stable. Breaking changes only in major releases, per the release policy.

Quick Start

# 1. Scaffold a new app with authentication (dependencies install automatically)
bunx create-guren-app my-app --auth
cd my-app

# 2. Run migrations and seed the demo user (SQLite by default — no server needed)
bun run db:migrate
bun run db:seed

# 3. Start the dev server
bun run dev

Open http://localhost:3333 and sign in at /login with demo@example.com / secret.

Add features as you go

bunx guren add auth            # Authentication
bunx guren add resource posts --fields "title:string,body:text"  # CRUD resource
bunx guren add queue           # Background jobs

…

View on GitHub

I like the way Laravel and Rails let you build. A feature is a route, a controller, a model and a view, and authentication, queues, mail and validation are already wired together before you start.

TypeScript has the parts. Hono for HTTP, Drizzle for the ORM, Zod for validation, Inertia and React for rendering, all of them good. What's missing is an agreed way to connect them, so every project ends up wiring it slightly differently, and I've written that wiring more times than I want to count.

The mistakes moved

I hand most of that to coding agents now. Models got good enough that obviously broken output mostly stopped showing up, and what replaced it is harder to deal with: code that reads fine and is subtly wrong, arriving faster than I read carefully.

It gets worse outside the training data. When I published v2.0.0, the new API shapes were younger than any model's training set, and the agents didn't slow down for that at all. They filled the gaps by guessing, and the guesses looked like working code.

Fullstack TypeScript frameworks are not a new idea and several of the existing
ones are good. What I couldn't find was one that treated agent generation and
mechanical verification as a design input instead of something added on later, so
I started building one.

What's in it

Routing, controllers, ORM, authentication, and an Inertia.js + React frontend, as one experience. Nothing underneath is new: HTTP is Hono, the ORM is Drizzle, validation is Zod, rendering is Inertia + React + Vite. Guren doesn't ship its own ORM or its own validator, it gives those defaults a set of conventions.

A controller looks about how you'd expect:

import { Controller } from '@guren/core'
import { pages } from '@/.guren/pages.gen'

export class PostController extends Controller {
  async show() {
    const { id } = this.validateParams(PostIdParamSchema)
    const post = await Post.findOrFail(id)   // throws a 404 on its own
    return this.inertia(pages.posts.Show, { post })
  }

  async store() {
    const data = await this.validateBody(CreatePostSchema)   // 422 on failure
    const user = await this.auth.userOrFail()                // 401 if anonymous
    await Post.create({ ...data, authorId: user.id })
    return this.redirect('/posts')
  }
}

Batteries are included in the Laravel sense: authentication with OAuth providers, queues and jobs, mail, events and listeners, cache, notifications, broadcasting, scheduling, storage, i18n, policies, console commands.

Types that cross the boundary

You bind a Zod schema to a route:

posts.post('/', { name: 'posts.store', body: PostPayloadSchema }, [PostController, 'store'])

and the form on the other side derives its type from that schema instead of restating it:

type PostFormData = RouteBody<ApiRoutes, 'posts.store'>

const form = useForm<PostFormData>({ title: '', body: '' })

Add a field to the schema on the server and the form's type follows. Rename the route and route('posts.store') stops compiling. Page props work the same way, checked against the page component's own Props interface, so a misspelled prop is a typecheck failure rather than a blank space on the page.

Letting the project explain itself

Early on I ran an evaluation to see what a feature actually costs an agent on each framework. I expected Guren to come out cheap, because a framework that has already decided things for you should mean less code for the agent to write. The first bare measurement put it at a $5.54 median, 2.7 times Hono's.

The stream analysis explained it. Agents were spending 17 to 46 percent of all their tool actions reverse engineering @guren/* APIs out of node_modules dist bundles, reading minified output to find out what a method is called. The
implementation work itself was fine. What cost money was discovery, which makes sense in retrospect, since the model knows Hono and Next.js from training data and has never seen Guren. So I fixed the documentation and measured again, which brought it to $3.35.

That's the problem guren context exists to solve:

# Post

## Model — app/Models/Post.ts (table: `posts`)
- Columns: id, title, excerpt, body, authorId
- belongsTo: `author` → PostAuthorSummary

## Referenced by
- User — hasMany `posts`

## Routes (8)
| Method | Path | Name | Action | Body |
|--------|------|------|--------|------|
| GET | /posts | posts.index | PostController.index | |
| GET | /posts/:id | posts.show | PostController.show | |
| POST | /posts | posts.store | PostController.store | { title: string; excerpt: string; body: string } |

## Pages (4)
- posts/Show — Props: `{ post: PostResourceData }`
- posts/Edit — Props: `{ post: PostFormValues | null postId: number ... }`

## Resource — app/Http/Resources/PostResource.ts

One command, and --json gives the machine-readable version. After the agent writes something, there are commands that check it: guren check verifies that routes, controllers and pages still agree and that route files are actually wired into a registrar, guren audit flags mutating routes with no validation or auth along with raw SQL and secrets, and guren spec:generate regenerates the ER diagram, domain model and screen inventory from code so CI fails when they drift.
None of it depends on trusting the agent, since the checks run against the repository either way.

What the numbers say

I publish the evaluation rather than describing it: the same feature task, on several frameworks, scored automatically by typecheck, the full test suite, and a hidden HTTP smoke the agent never sees.

On the frameworks the model already knows well, every trial shipped, and Guren still sits at a $3.35 median against Hono's $2.03.

The result I care about is from the day I published v2.0.0, when the breaking API changes were younger than any model's training data. With the guidance every new project scaffolds, agents passed 3 of 3 at a $4.90 median. With that guidance stripped out, 1 of 3 at $6.94. The failures guessed at API shapes v2 had changed, the paginated response structure and the testing assertions, and then wrote tests around the wrong guesses.

Three trials per arm isn't a statistical claim.

Every round is published, including one where a harness change I was confident about turned out to have quietly lost an earlier win. There's also a correction I had to make this month: an outside review found that the guidance an agent reads wasn't being counted in any of the metrics, sitting right under the section arguing Guren is cheap to read. It's 1,784 lines and 22,582 tokens, and it has its own row now.

The benchmark report has the detail, and the raw rounds are here.

Running it

Development assumes Bun's toolchain, though deployment doesn't: your own Bun server, or the first-party plugins for AWS Lambda, Vercel and Cloudflare Workers.
guren.dev is a Guren app, blog and admin screen included, running on Workers and D1. Building it turned up a handful of framework bugs, which is roughly why I built it there.

bunx create-guren-app my-app --auth
cd my-app
bun run db:migrate && bun run db:seed
bun run dev

SQLite is the default, so there's no database server to set up. Open http://localhost:3333/login, sign in with demo@example.com / secret, and you have an authenticated app running.

When not to use it

If your product is rendering-centric RSC-style React, Next.js is a better fit and I'd reach for it too. Plain Hono is lighter for anything that isn't really an MVC app, a webhook receiver being the obvious case, and if Bun is off the table on your developers' machines then none of this helps you. The docs have a longer version of this.

The community is small. Mostly me, so far.

If you like how Laravel or Rails feel and you're tired of rebuilding the same wiring in TypeScript, it shouldn't cost much to try.

Repo: https://github.com/gurenjs/guren
Docs: https://guren.dev/docs
Feedback: GitHub Discussions

DEV Community: Daiki Urata