chef: an AI app builder that targets Convex rather than a generic backend

The pitch is that the agent knows one backend well

The positioning line is that chef is the only AI app builder that knows backend. That is a marketing claim and also the actual technical difference. Instead of generating a frontend plus a guessed API layer plus a schema for a database it has never seen, chef generates everything against [Convex](https://convex.dev), the open-source reactive database the README describes as designed to make life easier for web app developers.

The README attributes the quality of the output to that choice rather than to a cleverer model: the magic in chef is the fact that it is using Convex's APIs, which are an ideal fit for codegen. That is a plausible reading, since a code generator that only ever has to satisfy one backend's contracts produces much more consistent projects than one balancing several.

Development is led by the Convex team, and the project is Apache-2.0 licensed in the repository metadata with 4610 stars and 925 forks. It is not archived and the last push was on 2026-07-16, so it is actively developed.

The lineage matters if you have used the original: chef is a fork of the `stable` branch of bolt.diy from StackBlitz Labs. Understanding that it started as a general-purpose browser IDE and was retargeted at Convex explains both the breadth of the UI and the specificity of the output.

It generates database, auth, uploads and real-time UI together

The capability list in the README is short because Convex supplies most of it. Chef builds full-stack web apps with a built-in database, zero config auth, file uploads, real-time UIs and background workflows. None of those are separate prompts you have to remember to ask for, which is the practical difference from a generic builder.

The repository layout shows how the pieces are organised, and it separates the client, the agent loop and the generated code:

app/ contains all of the client side code and some serverless APIs.
chef-agent/ handles the agentic loop by injecting system prompts, defining tools, and calling out to model providers.
convex/ contains the database that stores chats and user metadata.

That last one is the detail worth pausing on. The Convex directory in chef itself holds the database for chef's own chats and user metadata, which is distinct from the Convex functions chef writes into your generated project. Generated projects start from the `template/` directory, and `test-kitchen/` is a harness for exercising the agent loop, which tells you there is a testing story behind the prompt work rather than prompts alone.

`chefshot/` is a CLI for interacting with the Chef webapp, and the `proxy/`, `iframe-worker/` and `eslint-rules/` directories at the root suggest a fair amount of infrastructure around the core loop.

The system prompt is published as a release artifact

The most unusual thing in this repository is that the prompts are a first-class output. The README invites you to view or download the system prompt, and the releases include a `prompts-v0.0.1` tag from 2025-09-11 named Chef System Prompts 0.0.1, containing `chef-system-prompts.txt`, described as the complete system prompts as sent to the AI model, generated automatically from the latest prompt changes in the chef-agent.

That decision has real value. Prompt-driven app builders are usually opaque, and when output is bad you have no lever to pull. Publishing the compiled prompts means the behaviour of the tool is inspectable, comparable between versions, and reviewable in a pull request. A `buildSystemPrompts.ts` script at the repository root is the mechanism that keeps the published artifact in sync with the source.

The package version and the prompt version are tracked separately, with package.json at 0.0.7. That separation makes sense given the release title mentions reducing eval frequency, because the expensive part of this project is validating that a prompt change improved output rather than broke it.

The README also links a prompting guide for working with AI app builders, which is the documentation to read if you intend to drive chef by hand rather than through its own interface.

Running locally takes five setup steps and one caveat

The hosted webapp at chef.convex.dev is the easy path and includes a generous free tier. The local setup is documented properly, starting with a clone:

git clone https://github.com/get-convex/chef.git
cd chef

Then the environment, where `npx convex dev --once` walks you through creating a Convex project in your team:

nvm install
nvm use
npm install -g pnpm
pnpm i

Node 18.18.0 or newer is the declared engine requirement, and `nvm` is Mac and Linux only, so Windows users need another way to select a Node version.

The remaining three steps are configuration. You create an OAuth application in the Convex dashboard, and the team you use becomes the only team you can sign in to on a local chef, with a redirect URI you can point at `http://127.0.0.1:5173` so the form submits. Deployment environment variables include `BIG_BRAIN_HOST`, `CONVEX_OAUTH_CLIENT_ID`, `CONVEX_OAUTH_CLIENT_SECRET` and `WORKOS_CLIENT_ID`, and model keys are supplied separately in `.env.local` for Anthropic, Google, OpenAI or xAI, or entered through the Chef settings page instead.

The caveat is worth reading twice: local runs still provision against the hosted Convex control plane, so this is not an offline setup, and Chef tokens used this way do not count toward usage in your Convex account. Also note the URL form: chef works at `http://127.0.0.1:{port}/` and not properly at `http://localhost:{port}/`.

The authentication layer is the thing you must replace

The README carries an important warning that is easy to skim past. Chef is provided as-is, using an authentication configuration specific to Convex's internal control plane that manages user accounts. If you plan to develop a fork for production use or redistribution, your fork must replace the existing authentication system with your own.

The recommended replacement is the OAuth Authorization Code Grant flow for authorizing access to Convex teams or projects, documented under Convex's platform APIs. In other words the path from demo to product involves swapping in real user management, and the project tells you that plainly rather than hoping you notice.

This is the sharpest illustration of what the tool is and is not. chef is excellent at generating the parts of an application where a backend framework's opinion helps an agent guess correctly, and it makes no attempt to own your identity provider.

The build tooling reflects an ordinary modern TypeScript application: Remix with the Vite plugin, Vitest for tests, ESLint configured separately for `app/` and `convex/`, Prettier, and knip for dead-code detection. There is a `Justfile` for task running, a `depscheck.mjs` that gates the dev script, and separate lint scripts for the client and the Convex functions, which is the shape you would expect from a codebase that mixes two very different kinds of TypeScript.

Where to start with this project

The documentation referenced from the README lives on docs.convex.dev under the Chef path, and the prompting guide sits on Convex's own blog. Neither is in the repository, which means the repo tells you what Chef generates and how to run it, while the docs tell you how to drive it well.

For judging the project, three signals are worth weighing. The fork relationship to bolt.diy means the UI and IDE mechanics are inherited and well tested, while everything about the backend is Convex-specific work. The published system prompt means the core mechanism is auditable. And the README's own framing that the output quality comes from Convex being a good codegen target is a testable claim, since you can read the prompt and see how tightly it is bound to that backend.

The practical limitation for anyone outside the Convex ecosystem is unavoidable. If your production data has to live somewhere other than Convex, this builder's main advantage does not apply, and you would be using an IDE that is unusually opinionated about a platform you cannot use.

Editorial conclusion

chef stands apart from the general AI app builders because it is not trying to be neutral. Every generated feature lands on Convex's reactive backend, so the database, real-time subscriptions and background workflows come out wired together rather than as three separate services an assistant has to guess at. The system prompt is published as a release artifact, which is unusual and makes the approach inspectable rather than a black box. Two caveats are stated plainly in the README: the bundled authentication is tied to Convex's internal control plane and must be replaced before you redistribute a fork, and local runs still provision against the hosted control plane. Start on the hosted webapp with its free tier, read the prompting guide, and only self-host once you are replacing that auth layer.

Frequently asked questions

Official sources

1. get-convex/chef on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases