AutoBE: a compiler-checked backend generator for TypeScript, NestJS and Prisma

What AutoBE generates, and for whom

AutoBE is a coding agent that produces a whole backend application from a chat conversation. The README describes the output as complete specifications, database and API documentation, test coverage and implementation logic. Concretely, the generated application is a TypeScript server built on NestJS with Prisma as the ORM, which is why the project's own topic list reads nestjs, prisma and backend.

The intended audience is narrower than "anyone who wants a backend". The README says the clean implementation logic serves as a learning foundation for juniors while improving senior developer productivity, and the workflow it recommends is to build a first backend quickly, then keep extending it with a general-purpose code assistant. So AutoBE is positioned as the scaffolding step, not the long-term maintainer of the codebase. If your stack is Python, Go or Java, nothing here applies: the generated artifacts are Prisma schemas, NestJS controllers and TypeScript test code. The repository also ships a set of worked examples (a to-do list, a Reddit-style community, an e-commerce app and an ERP system) under the autobe-examples organisation, which is the fastest way to judge output quality before running anything yourself.

The waterfall: five agents and three compilers

The README's architecture diagram shows a Facade Controller that dispatches to five functional agents in sequence: Analyze, Database, Interface, Test and Realize. Each stage has a defined deliverable. Analyze produces the requirements report. Database produces the ERD and the Prisma schema. Interface produces the API specification, which the diagram labels as feeding an OpenAPI Compiler. Test produces the e2e test functions, analysed by a Test Compiler. Realize produces the main program, compiled by what the diagram calls a Hybrid Compiler.

The interesting part is what sits between the agents. The diagram shows the Database agent's output being validated by a Database Compiler, and the Interface agent generating through an OpenAPI Compiler rather than emitting prose. That is the project's central claim: the model does not write code and hope. It writes a structured artifact, a compiler checks the artifact, and the failure is fed back. The README frames this as code that is "100% buildable by AI-friendly compilers", and the linked compiler types (AutoBeDatabase.ts, AutoBeOpenApi.ts, AutoBeTest.ts in packages/interface) are the schemas the agents target.

This is a real constraint, not a slogan, and it also bounds the system. A compiler can prove that a Prisma schema is valid and that an API definition is well formed. It cannot prove that the schema models your business correctly. A shopping backend with a plausible-looking but wrong order model will pass every compiler in the pipeline.

Installing AutoBE and running a first session

The README gives one installation path: clone the repository and run the playground. There is no documented global CLI, no Docker image and no hosted endpoint in the README. The commands below are copied from the Getting Started section.

git clone https://github.com/wrtnlabs/autobe --depth=1
cd autobe
pnpm install
pnpm run playground

The root package.json defines playground as `rimraf playground-result && node playground/index.js`, so the script clears a previous result directory before starting. The README states the playground is then available at http://localhost:5173, where you chat with the agents, manage multiple sessions and select an LLM provider, including local models such as qwen3.5-397b-a17b.

The README's example conversation drives the waterfall one stage at a time rather than in a single prompt. For a discussion board it suggests, in order: an initial request for a requirements analysis report, then "Design the database schema.", then "Create the API interface specification.", then "Make the e2e test functions.", then "Implement API functions." Expect to approve or correct each stage before the next begins. The repository also ships a replay viewer at http://localhost:5173/replay/index.html, which the README says shows chat sessions from the development team's own testing and benchmarks. That is the closest thing to an evaluation harness here, and it is worth opening before you spend tokens on your own domain.

Where the compiler loop stops helping

The failure mode is not broken code. It is valid code for the wrong requirement. Every guard in the pipeline checks form: the Prisma schema parses, the OpenAPI document is well formed, the generated tests compile. None of them checks intent. If your requirements description is vague, the Analyze stage will fill the gap with a reasonable-sounding decision, and that decision then propagates through the schema, the API surface and the tests without anything flagging it. You find out at review time, by which point you are reading a full application rather than a paragraph.

There is a second cost that the README does not discuss: the output is a new codebase. Adopting AutoBE means adopting NestJS, Prisma and the project's own conventions for controllers, DTO structures and providers, which the examples show under src/controllers, src/api/structures and src/providers. If your team already has a backend with its own layering, AutoBE will not merge into it. It generates a sibling application. That makes it the wrong tool for incremental work on an existing service, and the right tool for greenfield prototypes and for teams that have already standardised on this stack.

AutoBE compared with a general coding assistant

The obvious comparison is a general-purpose agent such as Claude Code, and the README makes it explicitly: build with AutoBE first, then maintain and extend with an AI code assistant. The difference in approach is structural. A general assistant edits files in a repository you already have, with no opinion about the order of operations and no compiler gate between steps. AutoBE owns the whole generation, enforces a fixed sequence (requirements, then database, then API, then tests, then implementation) and validates the intermediate artifacts before moving on.

That ordering is the product. It is also the constraint. A general assistant can be pointed at an existing Express service, a migration script or a single broken test. AutoBE cannot; it starts from a description and produces a new application. The practical split is that AutoBE is better at the first commit and worse at the hundredth. The README's own recommended workflow concedes this, which is a more honest framing than most generator projects offer.

Maintenance, releases and the AGPL-3.0 question

The repository is not archived, and the last push was on 2026-06-24. The most recent release listed is v0.31.1 on 2026-04-10, with v0.31.0 the day before and v0.30.5 on 2026-03-31. The README's roadmap marks the Alpha, Beta and Gamma releases as done and the Delta release as active, so the project describes itself as pre-1.0. The root package.json carries version 0.31.1, matching the release tag.

Upgrade cost is mostly the usual monorepo problem. The workspace pins [email protected] via packageManager, and the root has sync:readme and sync:dependencies scripts plus bumpp for versioning, which tells you the maintainers treat dependency alignment as a release chore. If you fork the generator, expect to keep up with those. If you only consume the generated output, the generator's version matters far less than the NestJS and Prisma versions in the code it emits.

The licence is AGPL-3.0, declared in both the LICENSE file and the root package.json. The README does not discuss what that means for generated applications, and this is the single largest open question for commercial users. AGPL-3.0 is a strong copyleft licence with a network-use clause, and whether the generator's licence reaches the code it produces is a question for your own legal review, not something the project documentation answers. If you plan to keep the generated backend proprietary, resolve that before you build on it.

Editorial conclusion

Adopt AutoBE if you want a NestJS and Prisma starting point whose schema, API surface and e2e tests were validated by compilers before you touch them, and if AGPL-3.0 fits how you plan to distribute your work. Do not adopt it if you need a Python, Go or Java backend, or if you expect a hosted service: the README's only install path is a local clone and pnpm run playground. Before committing, generate one small domain end to end, check that the Prisma schema and the API controllers match what you asked for, and confirm the generated e2e tests actually run in your environment.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. wrtnlabs/autobe on GitHub