AutoBE: a compiler-checked backend generator that only emits TypeScript, Prisma and NestJS
AI Vibe Coding Agent of TS backend server, enhanced by compiler skills, generating 100% working code
At a glance
- What is it?
- AutoBE turns a chat conversation into a working NestJS backend by splitting the job across five agents and feeding each one's output through a compiler. The constraint that makes it interesting is also the constraint that limits it: everything it produces is TypeScript, Prisma and NestJS.
- Who is it for?
- Adopt AutoBE if your target stack is already TypeScript, Prisma and NestJS, and if you want the generated e2e tests and Prisma schema as much as the controllers. Do not adopt it if you need Python, Go, Java, a non-relational store, or a hosted service you can point a product manager at; the README only documents a locally cloned playground.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 83 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap AutoBE is aimed at: prototypes that do not survive contact with a compiler
Most code generation tools stop when the code looks plausible. AutoBE's README makes a narrower and more falsifiable claim: the generated backend application is "designed to be 100% buildable by AI-friendly compilers." That phrasing is doing real work. The project is not selling code that reads well, it is selling code that passes a type checker, a Prisma schema validator and an OpenAPI generator without human repair. The intended user is described in the README as someone building a first backend application quickly and then handing it to a general-purpose assistant such as Claude Code for maintenance. So the audience is two groups at once: developers who can read TypeScript and want a starting skeleton for a CRUD-shaped domain, and non-programmers following the README's own example, where the user says "Since I'm not familiar with programming, please write a requirements analysis report as you see fit." Those two audiences need different things from the same tool, and the README leans toward the second while the output format clearly serves the first.
Five agents, one facade, and a compiler after every stage
The architecture diagram in the README shows a Facade Controller dispatching to five functional agents in sequence: Analyze, Database, Interface, Test, Realize. Each stage consumes the previous stage's artifact rather than the raw chat transcript. Analyze produces a requirements report, Database produces an ERD and Prisma schema, Interface produces API controllers and DTO structures, Test produces e2e test functions, Realize produces the provider implementations. The second half of the diagram is what separates this from a prompt chain: the Database agent's output is validated by a Database Compiler, the Interface agent generates through an OpenAPI Compiler, the Test agent's output is analyzed by a Test Compiler, and the Realize stage compiles through what the README calls a Hybrid Compiler. The README links each of these to a TypeScript interface file in packages/interface/src, so the compilers are typed contracts in the repository, not prose guidelines. The docs site names the overall shape a Waterfall Model and a separate page is titled Compiler Strategy. The practical consequence is that a stage cannot hand malformed structure to the next stage and let the error surface at build time. The cost is that a wrong decision early (a bad entity boundary in the ERD, say) propagates through four downstream agents before anyone sees a running server, and the README does not describe a rollback path for a single stage.
Getting the playground running and what the chat actually asks for
The README's Getting Started block is four commands: git clone https://github.com/wrtnlabs/autobe --depth=1, then cd autobe, pnpm install, pnpm run playground. The playground then serves at http://localhost:5173. There is no documented hosted version and no npm install path for the agent itself, even though the README carries an NPM Version badge for @autobe/agent. That badge points at a package, but the getting-started instructions are clone-and-run, and the README does not explain how @autobe/agent is meant to be embedded in your own service. If you want AutoBE as a library rather than as a local app, the linked docs under Agent Library (Facade Controller, Configuration, Event Handling, Prompt Histories) and WebSocket Protocol are where you would have to look; the README itself does not walk through that path. The chat flow is staged rather than one-shot. The README's example script sends five separate messages in order: a requirements request, then "Design the database schema.", then "Create the API interface specification.", then "Make the e2e test functions.", then "Implement API functions." Each message advances one agent. The README also mentions that the playground supports multiple sessions and multiple LLM providers, including local models such as qwen3.5-397b-a17b, and that a replay view at http://localhost:5173/replay/index.html shows chat sessions from the maintainers' own testing.
The stack lock is the design, not an oversight
AutoBE generates TypeScript, Prisma and NestJS. The docs site has a Backend Stack section with exactly those three entries. This is the most consequential thing to understand before adopting it, because it is not a configuration option. The Database Compiler validates against a Prisma-shaped AST, the OpenAPI Compiler emits against AutoBeOpenApi types, and the Realize stage compiles NestJS providers. If your team runs Django, Spring Boot, or a Go service, AutoBE has no path for you, and no amount of prompt phrasing will change the compilers. The upside is that a narrow target lets the generators be strict. The README's generated examples include an ERP system with a linked ERD, Prisma schema, API controllers, DTO structures, e2e tests under test/features/api, and implementations under src/providers, all in the same stack. A general-purpose coding assistant has no equivalent guarantee because it has no fixed compile target to fail against. The trade-off is real: you get correctness relative to a compiler, and you accept the stack the compiler was written for.
Where the compiler guarantee stops
Buildable is not the same as correct. The README's claim is about compilation and about e2e tests providing stability, and those are two different bars. A generated NestJS provider can type-check, satisfy its DTO, and still implement the wrong business rule, because nothing in the five-stage pipeline encodes your domain semantics beyond what you typed into the chat. The compilers check structure. They do not check whether an order total should include tax. A second limitation is stated indirectly by the README's own positioning: it tells you to build the first backend with AutoBE and then "maintain and extend it with AI code assistants like Claude Code." That is an admission that AutoBE is a generator, not a maintenance tool. There is no documented workflow for feeding an existing AutoBE-generated codebase back in and evolving it, so the second feature request in a project likely lands in a different tool. Third, the README documents only a local playground. There is no described multi-tenant deployment, no auth story for the playground itself, and no guidance on what happens when two people generate against the same repository. For a team evaluating this as shared infrastructure, that is an open question the README does not answer.
Licence and the cost of keeping up
AutoBE is AGPL-3.0. For a local generation tool that you run on your own machine and whose output you then modify, the practical question is whether the generated application is a derivative work of the generator. That is a legal question and this article cannot answer it; if you plan to run AutoBE as a network service that other people interact with, or to embed @autobe/agent in a product, get your own advice before you build on it. On maintenance, the release cadence visible in the repository is fast: v0.31.1 on 2026-04-10, v0.31.0 the day before, v0.30.5 on 2026-03-31. Three releases in eleven days at a 0.31 minor version. The README's roadmap lists Alpha, Beta and Gamma as done and Delta as active, so the project describes itself as pre-1.0. Fast patch releases during a Delta phase usually mean the interfaces in packages/interface are still moving, and those interfaces are exactly what the compilers are built on. If you vendor the agent library rather than running the playground, budget for reading release notes between upgrades.
How this differs from a general coding assistant
The obvious comparison is a general-purpose coding agent such as Claude Code, which the README itself names as the follow-on tool. The difference is in where the correctness pressure is applied. A general assistant writes files and then, if you ask, runs your build; the loop is optional and driven by the model's judgement about whether to check its work. AutoBE inverts that. The pipeline is fixed at five stages, each stage has a named compiler in the diagram, and the compiler is part of the generation path rather than a verification step afterward. The second difference is output shape. A general assistant asked for a backend will produce whatever structure it decides on that day, which is fine for one file and painful for a twelve-entity schema. AutoBE commits to an ERD, a Prisma schema, an OpenAPI specification, e2e tests and providers, in that order, every time. What you give up is flexibility: a general assistant can write you a Python service, a migration script, or a Terraform module in the same session, and AutoBE cannot write any of those. The two are complements in the workflow the README describes, not substitutes.
Editorial conclusion
Adopt AutoBE if your target stack is already TypeScript, Prisma and NestJS, and if you want the generated e2e tests and Prisma schema as much as the controllers. Do not adopt it if you need Python, Go, Java, a non-relational store, or a hosted service you can point a product manager at; the README only documents a locally cloned playground. Before committing, run pnpm run playground, point it at the LLM provider you intend to use in production, generate one domain you already understand well, and read the generated test/features/api directory and prisma/schema files before you read the controllers.
Community notes