QuantumByte: an app builder that audits its own output
Open-source app builder engine — intent to working app
At a glance
- What is it?
- QuantumByte generates an app from a written intent, then runs a read-only harness that checks the result against explicit business requirements after every agent turn. The engine is Apache-2.0, self-hosted, and still labelled a public alpha.
- Who is it for?
- Adopt QuantumByte if you already run Docker, Node 20+ and Python 3.11+, and you want the verification loop rather than another code generator. Skip it if you need a hosted product, a one-command deploy, or a model provider other than Anthropic, because the README states the current worker uses the Claude Agent SDK and provider adapters are still on the roadmap.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 18, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem QuantumByte is aimed at: apps that look finished before they are
The README names the failure mode directly. An app can render, pass its happy path and impress in a demo while requirements are missing, misunderstood or silently broken. The project calls this false convergence, and it is a fair description of what happens when a model is asked to produce a whole application in one pass. The interface is the part you can see, so it becomes the part you judge.
QuantumByte is built for people who already accept that a model can generate a working app and who are now worried about what the generation left out. The README frames the audience as founding contributors and researchers as much as product teams, and the roadmap backs that up: ConvergenceBench reference tasks, world-grounded evidence and readiness gates are all unchecked. If you want a polished hosted builder, this is not it. If you want to read the verification code and argue with it, the repository is laid out for that.
How the builder and the read-only harness stay separate
The architecture is three applications over one PostgreSQL database. apps/web is the Next.js and Prisma workspace with chat, live preview and the requirements UI. apps/orchestrator is Python and handles project assignment, worker coordination and recovery. apps/worker runs the agent, the build loop, workspace management and the requirements harness through the Claude Agent SDK.
The separation that matters is inside the worker. The builder agent can edit the generated project. The harness cannot. According to the README, it evaluates one business requirement at a time without inheriting the builder's conversation, and it cannot modify the repository it is auditing. Requirements come from the product overview and users can lock them so they stay authoritative. Each audit returns a structured SUCCESS or FAIL verdict with evidence, and INCONCLUSIVE is recorded separately from genuine failure. When relevant files change, re-verification is diff-scoped rather than a full re-run.
Coordination does not use a message broker. The docker-compose comments state that the message table in Postgres is the queue, following RFC 0001 and RFC 0003. Redis exists only as a lock store for the harness per-project run lock, and the worker degrades open if Redis is down. That is a small but telling design choice: the lock protects against duplicate concurrent audits, it is not a correctness dependency.
Installing QuantumByte locally and running your first verified build
The quickstart assumes Docker and Docker Compose, Node.js 20 or newer with npm, Python 3.11 or newer, and an Anthropic API key. Clone the repository and run the four Make targets in order. make install installs dependencies for all three apps, make db-up starts the containers and waits for health, make migrate applies the Prisma migrations, and make dev brings the stack up.
git clone https://github.com/QuantumByteOSS/quantumbyte.git
cd quantumbyte
make install
make db-up
make migrate
make devOpen http://localhost:3000. The README points at docs/running.md for environment variables, service topology and troubleshooting, and make help lists every development target.
There is a second path worth knowing about. make setup is documented in the Makefile as a one-shot, idempotent local setup that chains env, install, db-up, migrate and generate. The env target copies each app's .env.example to .env only if the file is missing, so it never overwrites an existing configuration. You still have to fill in secrets yourself: the Makefile comment states the worker needs ANTHROPIC_API_KEY and GIT_PAT.
make setupDocker Compose brings up more than Postgres. Postgres listens on 5432 with user, password and database all set to quantumbyte. Redis listens on 6379 and the compose file tells you to point the worker's REDIS_URL at redis://localhost:6379/0. minio serves the S3 API on 9000 and a web console on 9001, and a one-shot minio-init container creates the bucket and makes it public-read so that image tags in generated apps resolve. If you already run Postgres or Redis locally, check those ports before you start.
What the harness does not prove, and when to pick something else
The README is unusually candid about scope. The current harness implements one part of the Convergence Programming agenda: continuous verification against explicit business requirements. It does not claim world-grounded verification, complete production readiness, or the proposed ConvergenceBench evaluation framework. Those are roadmap items, not features.
That leaves real gaps. Requirements are derived from the product overview, so a requirement the overview never mentions will not be audited. A verdict is evidence-backed, but the evidence is whatever the harness can observe from the repository and the running preview, which is why INCONCLUSIVE is tracked separately rather than folded into failure. The build loop and recovery machinery are documented; rollback of a bad generated change is not, and the README does not describe one.
A second constraint is the model provider. The README states the current worker uses the Claude Agent SDK and that provider-neutral agent boundaries and additional model providers are on the roadmap. If your organisation standardises on a different provider, you are either waiting for an adapter or writing one.
The obvious alternative is a general coding agent driven from your terminal, such as Claude Code or a similar CLI, with your own test suite as the check. The difference is where the verification lives. A CLI agent verifies through whatever tests you wrote, and the same conversation that produced the code decides when to stop. QuantumByte puts the check in a separate process with no write access to the audited repository and no memory of the builder's conversation, and it records a per-requirement verdict rather than a pass or fail for the whole run. That is more machinery to run. Whether it catches more depends on how well your product overview states the requirements in the first place.
Licence, maintenance and the cost of keeping it current
QuantumByte is Apache-2.0, which permits commercial use, modification and redistribution provided you keep the licence and notices, and it includes an express patent grant. The repository ships SECURITY.md and CONTRIBUTING.md, so there is a stated path for reporting vulnerabilities and sending changes. None of this is legal advice; if you embed the engine in a product, have counsel read the licence and the notices your distribution carries.
The last push to main was on 2026-09-13, four days before this writing, and the repository is not archived. The README labels the release a public alpha, and the roadmap still lists one-command self-hosting as unchecked, which means the local setup path is the supported one today.
Upgrade cost is concentrated in the database and the model boundary. Postgres is the source of truth for projects, messages, workers, requirements and verdicts, so schema changes arrive as Prisma migrations you apply with make migrate. Redis is disposable: the compose comments say the worker degrades open if the lock store is unavailable. The worker's dependence on the Claude Agent SDK is the part most likely to move, since provider adapters are an explicit roadmap item and would change how the worker is configured.
Editorial conclusion
Adopt QuantumByte if you already run Docker, Node 20+ and Python 3.11+, and you want the verification loop rather than another code generator. Skip it if you need a hosted product, a one-command deploy, or a model provider other than Anthropic, because the README states the current worker uses the Claude Agent SDK and provider adapters are still on the roadmap. Before you commit a project to it, read docs/running.md, confirm the ANTHROPIC_API_KEY and GIT_PAT variables the Makefile expects, and run the harness on one requirement you can check by hand.
Frequently asked questions
What is QuantumByte?
It is an open-source app builder that generates a working application from a written intent and then verifies it against explicit business requirements. The README describes it as the open-source Convergence App Builder, with a separate read-only harness checking the app after every agent turn.
What does the QuantumByte harness actually check?
It evaluates one business requirement at a time and returns a structured SUCCESS or FAIL verdict with evidence, recording INCONCLUSIVE separately from genuine failure. Requirements are derived from the product overview and users can lock them so they remain authoritative.
How do I install QuantumByte locally?
The quickstart requires Docker and Docker Compose, Node.js 20 or newer, Python 3.11 or newer and an Anthropic API key. You clone the repository, then run make install, make db-up, make migrate and make dev, and open http://localhost:3000.
Which model provider does the QuantumByte worker use?
The README states the current worker uses the Claude Agent SDK. Provider-neutral agent boundaries and additional model providers are listed as roadmap items rather than shipped features.
Community notes