Most of the work of building software is not typing code. It is agreeing on what to build, writing it down so it does not drift, slicing it into tasks, doing the work, and reviewing it before it ships. Nexus by AllCode is one product that runs that whole loop, with agents doing the work and people making the decisions.
The idea
Nexus takes a project from an idea to merged code, and keeps a living specification true the whole way:
- You describe what you want, and an agent helps you turn it into a specification you can read and approve.
- That specification is broken into issues, ordered, and placed on a board.
- A factory picks up each issue and builds the software from it, opening pull requests.
- A reviewer checks those pull requests against the issue they came from, and merges them.
- A model gateway sits underneath it all, choosing models, enforcing budgets, and metering spend.
The specification is not a document that rots in a wiki. Nexus is specified in its own specification format, so the product can be specified, checked, and built by its own parts. When the code and the spec disagree, that disagreement is written down as an open question rather than quietly ignored.
How it is built
Nexus is one product made of several independent services, kept in a single monorepo. Each service runs in its own container, has its own database, and is versioned and deployed on its own. Services share code only through shared libraries, and talk to each other only through REST, MCP, Redis Streams events, and the customer’s issue tracker. Backends are Go; the front end is React and TypeScript.
The services:
| Service | What it does |
|---|---|
| Coordinator | Signs everyone in and issues the tokens every other service checks. Owns tenants, users, projects, credentials, and configuration. |
| Coordinator UI | The web app: a shell plus every service’s screens. |
| Agents | Runs every service’s agents, and the conversations people have with them (Chat). |
| Gather | Turns ideas into specifications written with an agent and kept in the repository. |
| Planner | A board on each project’s issue tracker (GitHub, GitLab, or Jira). |
| Factory | Builds software from issues and opens pull requests. |
| Reviewer | Reviews the factory’s pull requests and merges them. |
| Proxy | The model gateway: budgets, spend, guardrails, and its admin apps. |
| Admin / Admin UI | AllCode’s own admin site for running every installation. |
The principles that hold it together
A system this autonomous only works if a few rules are never bent:
- Specs first. You change the spec, then the code, in the same change. A specification is complete when someone could build the service from it without asking a question.
- One owner per concept. Every shared concept (tenants, projects, secrets, budgets, issues) has exactly one service that owns it. Everyone else stores only an ID that points to it.
- Requirements stay in their project. Nexus’s own specs describe Nexus. A product that Nexus builds keeps its own requirements in its own repository. The two never mix.
- Tested. Every service holds 90% line coverage, gated in CI, and every screen has a journey test.
- Deploy only when asked. A push to the main branch tests and builds but deploys nothing. A deploy happens only when a person asks for it, in words, for that change.
- Never invent a number. If a threshold or name is not known, the spec records an open question instead of a guess.
Where it stands
Coordinator, the Coordinator UI, Agents, Gather, Planner, and the proxy are running. Reviewer runs in the local stack with a review queue, though merging is still being built and some of its issue-tracker integration is in progress. The factory exists as specifications today. AllCode’s admin site is built and deployed.
You can run the whole thing locally with a single docker compose up -d, sign in at http://localhost:3000, and watch the loop come together.
Why it matters
The promise is simple to state and hard to earn: let people spend their time deciding what to build and whether it is right, and let agents handle the rest, specification, planning, building, and review, without the specification and the code ever drifting apart. Nexus is our attempt to make that loop real, and to build it out of parts honest enough to build themselves.
Recent Comments