A team of specialist AI agents carries one brief through requirements, architecture, code, unit tests, integration tests, browser UI tests, security audit, deployment and versioned Docker images. Every stage is scored for quality and reviewed by you before the next one starts.
Your machine. Your API key. Nothing is ever sent to us.
GirderWorks is installed software, built for Windows. There is no GirderWorks cloud, no upload and no shared tenant — so you can put real projects through it with peace of mind.
Briefs, source code, designs, test results and every generated artefact are written to your own disk. None of it is ever sent to us.
The vector store, tool gateway, guardrail service and observability all run as containers on your machine. The databases the pipeline creates are local and yours.
The agents' prompts, which include your project's content, go from your machine straight to the model provider you choose — under your own API key, your own agreement and their data terms. We are not in the path and never see them.
Model requests, to your own provider. Package and version lookups, to public registries such as Maven Central and npm. And one call to us: a periodic licence check carrying a machine identifier and your licence key — no project data, ever.
Your work is never visible to us. Guaranteed by design.
Not a repository you still have to make work. Four things are proven before the last gate.
Generated per service and actually run, against a line and branch coverage gate. Miss the gate and the gap goes back for more tests — the number on the report is measured, not claimed.
The whole app boots in dependency order, each service health-checked before its dependants start, and the cross-service suite runs over real HTTP. Broken contracts are fixed and re-booted until they pass.
Playwright drives your actual interface through the flows in the requirements — register, sign in, create, edit, delete — against the deployed app, then again against the containers.
A pinned image per service, built from generated Dockerfiles, started together with
docker compose and health-gated. The images stay in your registry, ready for
Kubernetes.
The pipeline supports microservice architectures and modular development workflows. It does not produce one large program: it decomposes the system into independently deployable services and carries that structure through every stage.
The Architect splits the system into services that own their own data and talk only over API contracts, with shared code in one library. Right-sized, too: a small app that should be one service stays one service.
Each service gets its own design section, its own code generation pass, its own tests, its own security audit and its own container. A problem in one service is fixed in that service, without regenerating the rest.
The design carries a startup graph. Data stores first, then backends, then the
gateway, then the frontend — each health-checked before its dependants start, natively and
again as containers with docker compose.
GirderWorks itself runs the same way: five independent containerised services on your machine — the pipeline and dashboards, a vector store, the guardrail service, observability and the tool gateway — each installed, started and upgraded on its own.
Agents alone do not ship software. This is the machinery around them.
Twelve gates across the pipeline. At each one an evaluator scores the artefact and lists its issues, then you review it: approve, or send it back with notes and the agents rework it in place. Pause mid-run, pick which services to redo, restart from any stage. Nothing advances on a model's say-so.
Every agent output passes a guardrail service before it lands on disk. Credentials, keys, hashes and personal data are blocked in source code and relocated into config automatically. The policy is enforced in code, not asked for in a prompt.
Your specs, standards and existing code are indexed into a local ChromaDB vector store, so agents design against your reality instead of generic training data. Each stage gets a deliberately scoped slice of context — the design it must implement, nothing more.
Agents use real tools through the Model Context Protocol: code sandboxes, static analysis, dependency registries, repositories and a real browser. They verify claims by running things, not by predicting the output.
Dozens of mechanical checks run over the generated tree — build manifests, configuration contracts, container permissions, database identifiers, UI selectors, dependency resolution. Code, not opinion. They fail loudly and they cannot be talked around.
A security stage audits every service with static analysis, a second agent verifies the findings against the code, and only high-severity issues enter a bounded fix-and-rescan loop. Security is a stage of the pipeline, not a checklist at the end.
Each stage is run by its own agents, produces a real artefact, is scored for quality, and waits for your review before the next begins.
Not one general assistant. Each stage has agents built for that work, with a second agent checking the first, and an evaluator scoring the result before you see it.
Turns your brief into numbered requirements with acceptance criteria. A Fidelity Auditor checks nothing was invented or dropped.
The Architect decomposes the system; the Design Engineer writes each service's contracts. An Architecture Reviewer and a Lead Design Reviewer check their work.
The Coder builds one service at a time against its design. The Reviewer compiles it, checks it against the design, and fixes what does not match.
Compiles and boots each service, runs a smoke test, and repairs what fails to start.
The Auditor scans every service with static analysis. The Verifier re-checks each finding against the code so only real issues reach the fix loop.
Tests are written, then actually executed against a coverage gate, then reported — three agents, because writing a test and proving it passes are different jobs.
Documents each service and writes the runbook, which is then checked against how the application really starts.
Independent of the agents that did the work. Scores every artefact on completeness, correctness, consistency and clarity, and lists the gaps — that list is what you review at the gate.
The final reviewer at all twelve gates. The agents propose; you approve, revise or redirect. Your decisions are logged with the run.
Traceable requirements with acceptance criteria, a high-level design, and a per-service low-level design with API contracts, data models and a startup dependency graph.
Every service generated module by module against that design, unit tests written to a coverage gate, and a cross-service end-to-end suite that runs against the live stack.
Findings per service with severity, what was fixed, what you chose to accept — and a full log of every gate decision along the way.
Runbook, Dockerfile per service, compose file, and versioned images already built and health-checked on your machine.
GirderWorks runs the workflow: design before code, review after code, tests that execute, security before release, containers at the end. The parts teams skip when they are busy.
Every project gets the same standard, because the pipeline applies it — not because everyone remembered the checklist.
Boot logs, test results, coverage numbers, scan findings, health checks. You approve each stage on evidence you can read.
Turn a client brief into a working first release in days, at the same standard on every project.
Runs inside your environment. Approval gates, guardrails, a security stage and a full document trail per run.
Get a complete, tested, deployable stack without hiring for every layer. Review the design, approve, keep moving.
Separate pipelines for feature work, bug fixes, refactoring and legacy modernisation — same gates, same guardrails.
Point it at an existing codebase or a previous run. The diagnosis differs; the gates, guardrails, tests and containers do not.
The full 13-stage run: requirements through versioned images. For a new product or a new service in an existing estate.
An impact analysis of the current code, then a feature design that states exactly which modules it extends — or the new service it adds, wired into the existing dependency graph. It then hands off to the same coding, testing, security and container stages, touching only the modules in scope.
Triage the report, then a root-cause analysis that names the affected modules from the real module list rather than guessing. Only those modules are regenerated, and the fix goes through the same tests, security audit and container build as any other change.
Refactoring improves internal quality with the existing test suite as the contract — tests must pass unchanged, and a reviewer agent audits for any behaviour change. Modernisation reads a legacy codebase and produces the requirements and architecture to rebuild it.
You bring your own model API key. Source code, designs and documents are stored on your machine and are never sent to us; model requests go from it straight to your provider. What leaves, in full.
Windows 10 or 11 · Docker Desktop · 8 GB RAM · ~6 GB disk
Fourteen days, every stage unlocked. Install it, describe something you would actually build, and watch the pipeline take it to running containers.