You describe the project and pick your stack. Thirteen stages then run in order — each with its own specialist AI agents, each producing a real artefact, each scored by an evaluator and handed to you for review before the next one starts. It ends with unit tests passing, integration tests green against a live stack, UI flows driven in a browser, and versioned Docker images on your machine.
A setup wizard collects the project description, the language and frameworks to use, and any documents you want the agents to read. You can attach an existing specification, a legacy codebase, or start from a paragraph of plain English.
Requirements come first: numbered functional and non-functional requirements, each with acceptance criteria. Then a high-level design — how the system splits into services, how they talk, what the security and containerisation policy is. Then a low-level design, written one service at a time: function contracts, data model, API contracts, error catalogue, configuration contract, and the startup dependency graph that later stages use to boot the system in the right order.
Each of these stages is written by one agent and reviewed by a second before you ever see it.
The codebase is generated module by module rather than in one giant response. Shared libraries are built first and their real code is fed forward, so a service implements against the signatures that actually exist. A reviewer agent then checks each module against its own design section and fixes what does not match.
Alongside the agents, deterministic checks run over the generated tree — build manifests, container write permissions, configuration contracts, reserved database identifiers, UI test selectors. These are code, not opinions, and a failure sends the module back before it can reach a later stage.
Each service is compiled and started on its own and must answer a smoke test. Then the whole stack is started together in dependency order, each service health-checked before its dependants start, and the cross-service end-to-end tests are run against the live system. When a contract between services is broken, a bounded fix loop repairs it and re-boots to confirm.
A security auditor reviews each service with static analysis, and a second agent verifies the findings against the code before any automated fix is attempted. Unit tests are executed for real against a coverage gate — if coverage is short, the gap is fed back and more tests are written. Documentation is generated per service and its runbook is checked against how the application actually starts.
The final build is deployed natively and browser tests drive the real interface. The stack is left running so you can click through it yourself before approving. Finally each service is built into a versioned Docker image, the stack is started as containers with health checks, and the images are kept on your machine ready for Kubernetes.
Agents write the artefacts. This is what stops a confident wrong answer from reaching your repo.
Twelve approval gates across the pipeline, plus a selection gate before the stages that work service by service. At each one you see the artefact, its quality score and a ranked list of issues found. Approve it, or revise it with notes — your notes and the issue list go back to the agents together with the current artefact, so it is corrected in place rather than rolled again from scratch. You can also pause mid-run, select which services a stage should rework, and restart a previous run from any stage. In unattended mode the gates auto-approve, for CI or overnight runs.
A guardrail service inspects agent output before it reaches disk. A credential, API key, password hash or personal data in a source file is blocked — and then cured deterministically: the value is moved into the stack's config file and the code is rewritten to read it from the environment. The same policy is stated in the design prompts, checked by the reviewer, and enforced mechanically at write time, because a rule that lives only in a prompt is a suggestion.
Your specifications, standards and existing code are ingested into a local ChromaDB vector store that agents search while they work. Just as important is what each agent does not see: every stage is fed a deliberately scoped slice — a coder gets its own module's design, the contracts of the services it calls, and the real code of the shared libraries it imports. Smaller, sharper context produces better code than dumping the whole project into every prompt.
Tools reach the agents through a Model Context Protocol gateway: code sandboxes, static analysis, dependency registries, source repositories, a database and a real browser. It means an agent can check that a library version exists, run a compile, scan for vulnerabilities and click through a UI, instead of predicting what those would have said. Tool access is scoped per stage, so each agent gets only what its job needs.
Dozens of mechanical checks run over the generated tree at the coding gate and afterwards: a Dockerfile copying a file that does not exist, an environment variable the settings class never declares, a container that writes where its user has no permission, a reserved word used as a database table, a UI test hunting for a selector the components never render, dependency pins that cannot resolve. Each returns a yes or no, names the file and the line, and blocks the gate. No model opinion involved.
Static analysis plus an agent review per service. A second agent then verifies each finding against the code, and anything it cannot substantiate is downgraded rather than acted on. Only high-severity findings enter the automated fix loop, which re-scans after fixing and stops when it stops improving. Findings it chooses not to fix — architectural gaps rather than defects — are surfaced to you at the gate instead of being quietly patched.
| Level | What runs |
|---|---|
| Unit | Tests generated per service and executed against a line and branch coverage gate. Below the gate, the uncovered paths go back for more tests. A suite that fails to load is reported as a defect, not as low coverage. |
| Integration | The whole stack boots in the order the design specifies, each service health-checked before its dependants start. Cross-service tests then run over real HTTP, and contract failures go through a bounded fix-and-reboot loop. |
| UI | Playwright drives the deployed interface through the flows derived from your requirements. It runs once against the native deployment and again against the containers, because a proxy or a missing build-time variable breaks the browser and nothing else. |
| Control | What it does |
|---|---|
| Approve | Accept the stage and move on. |
| Revise with notes | Send the stage back. Your notes and the scored issues are given to the agents together with the current artefact, so it is corrected rather than rewritten from scratch. |
| Pick services | Before a stage runs, choose which services it should work on. The rest keep their previous result. |
| Pause and resume | Stop the run at the next safe point, look at the artefacts, then continue. |
| Restart from a stage | Re-run an earlier stage on a previous run's inputs, keeping everything already approved. |
| Unattended mode | Run the whole pipeline with gates auto-approved, for CI or overnight runs. |
The 13-stage run above is for building something new. Three shorter pipelines handle work on code that already exists, and all of them hand off to the same coding, testing, security and containerisation stages.
| Pipeline | What it does |
|---|---|
| Feature enhancement | Analyses the impact on the current code, then designs the feature and states which existing modules it extends — or specifies a new service and wires it into the startup dependency graph. Only the modules in scope are regenerated; everything else keeps its approved state. |
| Bug fix | Triages the report, then runs a root-cause analysis that names the affected modules from the project's real module list. Those modules are fixed and re-verified through the normal tests, security audit and container build. |
| Refactoring | Improves internal quality without changing behaviour. The existing test suite is the contract: it must pass unmodified afterwards, a reviewer agent audits specifically for behaviour changes, and a risk reviewer vetoes refactoring code that has no test coverage. |
| Modernisation | Reads a legacy codebase and produces the requirements and target architecture to rebuild it, then hands that to the full pipeline. |
Each of these can target a previous run or an uploaded codebase, and each keeps the same approval gates and guardrails as a new build.
You choose the stack at the start and every agent works within it: Python, Java, JavaScript and TypeScript, Go, Rust, C#/.NET, PHP, Ruby, Kotlin, Swift, C and C++, with the common frameworks for each, or your own. Test frameworks, build files and container images are generated to match.
Model costs are separate. GirderWorks runs on your own model API key, so you pay the model provider directly for what a run consumes. That keeps your code and prompts inside your own account, and means the licence price does not change with how much you use it.