Why this framework exists.
Most web frameworks assume a human will hand-write every route, query, validator, migration, and form. AI agents already generate that code, but no framework treats their output as the canonical source. GoFastr inverts that. The agent's output is canonical source, same as the human's. The framework is what they both write to.
By Donald Murillo · Updated 2026-05-26
Why this exists
In 2026, you can describe an app and have it generated. The output is usually a tangle: hand-rolled handlers, magic ORMs, custom-DSL config files, and an opaque server runtime that fights both you and the agent. The next thing you do is throw most of it away.
The pattern is fixable. If the framework names what an entity is, a typed declaration that becomes SQL, REST, MCP tools, OpenAPI, and a typed Go model, then the agent's output is the declaration. Everything else is read-only generated code you can grep, debug, and step through.
The right abstraction makes the simple case trivial and the complex case possible. The wrong abstraction makes both unreadable.
The two layers
Two packages, no more. core/ is stdlib-only Go primitives, router, query, schema, mcp, openapi, and more, each independently usable, with no dependencies outside the standard library. framework/ is the opinionated entity layer composed on top. When the framework is in your way, you drop down to core and write plain Go.
No reflection magic. Generated code is regular Go you can read. The framework's job is to make the typed declaration so expressive that the generated code is shorter than the framework call that produced it.
Convictions
- Declare once, generate the rest. Database, REST, MCP, OpenAPI, typed Go: all from one source.
- No reflection magic. If the framework looks like it's doing something opaque, open the generated file.
- Drop down to core. If the framework is in your way, the layer below is stdlib-only Go with nothing else to fight.
- Batteries included, not embedded. Auth, cache, email, queue, search, storage: narrow interfaces, swappable drivers.
- AI agents are authors too. MCP tools, Kiln, agent notes. Every entity ships MCP tools from day one.
- Strong opinions, small scope. Some things we explicitly will not do.
Where agents fit
Agents drive the framework the same way humans do. The MCP tools are the REST endpoints in a different shape; the typed Kiln tools are the framework's mutate API exposed for code-generating agents. Destructive operations require an approved plan. The agent cannot drop your tables without you clicking Approve.
The framework also leaves clear breadcrumbs for the agent: doc files embedded in the binary and structured MCP introspection at /mcp. An agent that connects to a running GoFastr app can read its own state and reason about it.
What's next
| When | What | Status |
|---|---|---|
| Shipped | Two-layer core/ + framework/ split | ✓ shipped |
| Shipped | Auto-CRUD + MCP + OpenAPI | ✓ shipped |
| Shipped | Kiln agent build mode (experimental) | ✓ shipped |
| Q3 2026 | Lock framework/entity ABI | next |
| Q4 2026 | Land core-ui 1.0 | later |
| 2027 | First version we'd suggest shipping to customers | later |
A note on this site
This site is built with GoFastr itself. Every interactive element is a registered component; the CSS is generated by the typed style.StyleSheet DSL against the theme; every page is server-rendered with the same runtime any consumer of the framework gets.
If something on this site doesn't work, the bug is in the framework, and the fix lands here first, then everywhere else.
Notes & references
- The framework's principles trace from net/http: pattern routing, middleware chains, explicit handler signatures.
- MCP: Anthropic's Model Context Protocol; how agents call the app's tools.
- The two-layer pattern echoes Rich Hickey's distinction between simple and easy.