How we build
Speed here is a consequence of the gates, not a way around them.
The reasonable objection to a small team shipping four products is that something must have been skipped. This page is the answer: what the machine does, what it is not allowed to do, and what a change has to survive before it reaches production.
Everything below runs on our own work. It is not a product we sell and it is not a demo.
The platform
A private marketplace of orchestrators, subagents, skills and hooks.
The build engine is a versioned internal plugin marketplace, installed into every repository we work in. Six plugins cover development, operations, documentation, sales and the tooling that builds more tooling. The development plugin alone carries 24 subagents and 52 skills.
Counts reflect the installed marketplace and move as the platform grows.
Three layers, on purpose
Task orchestrators
One entry point per kind of work: implement a change, diagnose a bug, run a review, upgrade dependencies. The orchestrator sizes the job first and dispatches only what the size warrants.
Capability skills
Mid-level routines the orchestrators reuse: decide which verifiers a change needs, pick the testing tier, split a translation across locales. Written once, called from everywhere.
Leaf agents
Narrow workers with narrow tools. An engineer that writes one surface. A verifier that only reports pass or fail. An auditor that reads and never edits. A leaf that can only read cannot break anything.
Automated and human-gated
The line between what runs unattended and what stops for a person.
The split is not a matter of taste. Anything that can be re-run and verified mechanically is automated. Anything whose failure is expensive, irreversible or a judgement call stops and waits.
How one change moves through the platform
Research
- codebase-researchermaps the surfaces before anything is writtendone
Write, in parallel and sandboxed
- backend-engineerservice and endpointdone
- frontend-engineerpage and componentdone
- prisma-migratorschema and paired migrationdone
Verify
- backend-verifierclean boot, no missing providersPASS
- frontend-verifiertype-check, lint, buildPASS
- e2e-testerthe affected flows, driven in a real browserPASS
Merge
- mergewaiting for a humanheld
Agent names are the ones in the platform this site was built with.
Runs unattended
- Locating the code: parallel readers map the relevant surfaces before anything is written.
- Writing the change, one specialist per surface, in parallel where the surfaces do not collide.
- Type-checking, linting and building; booting the backend and watching for boot errors.
- Running the test suite and driving the running app through the flows a change touched.
- Auditing accessibility, responsive behaviour and page performance against measured budgets.
Stops for a human
- Every merge. No agent pushes to a shared branch on its own.
- Schema changes and data migrations, which are reviewed before they are generated, not after.
- Anything that touches production: deploys, production data, force pushes.
- Scope. When a task turns out to be larger or riskier than triaged, the pipeline stops and asks.
- The final call on any review finding, including whether a flagged risk is accepted.
The quality bar
What a change has to survive.
Verification has a hard floor
A code change is never reported as done without the build and lint checks for the surfaces it touched. Backend changes have to boot cleanly. The floor is written into the orchestration doctrine, so no individual run can decide to skip it.
Checks are scoped from evidence, not from habit
Which verifiers run is derived from the actual changed-file list, and the heavier tier is triggered by build-sensitive paths rather than by guesswork. That is what keeps thoroughness affordable enough to be non-negotiable.
Findings have to survive a skeptic
Every review finding is handed to a fresh agent whose only instruction is to prove it wrong. Findings that cannot be refuted survive; the rest are dropped before anyone reads them. It is the difference between a review and a noisy scan.
Failures are classified before they are fixed
A failing check is first sorted into code-owned or environment. Environment failures never enter a repair loop; they are surfaced with the remediation and the run stops. Repair attempts are capped, and a repeated root cause escalates rather than repeating.
Tests are written to be kept
Regression tests are authored as committed specs in the project's own runner, not as throwaway checks inside a session. What proved a fix stays in the repository to keep proving it.
Nothing is silently narrowed
When coverage is bounded, by sampling, a cap, or a skipped dimension, that is reported. A partial pass never reads as a full one.
Why timelines compress
The standards did not move. The cost of meeting them did.
Every one of these checks existed in a conventional team too. What changed is that running them stopped being a scheduling problem. Reviews across five dimensions run at once instead of waiting for a reviewer's calendar. A test pass over a dozen pages costs a dispatch rather than an afternoon. Work that used to be batched because it was expensive now runs on every change because it is not.
That is the whole trick, and it is why the speed does not come out of the quality budget. When verification is cheap, the rational amount of it goes up, not down.
See the same pipeline on a real buildTwo methods, two questions
This page is our delivery pipeline. The company-wide model is published separately.
What you have just read is how we build our own products: the platform, the split between what runs unattended and what waits for a person, and the bar a change has to clear. Making a whole organisation work this way, role by role, is a different problem with a different answer. augmented.club publishes that one in full, and it is the document to read if the question is what this would look like across your company rather than how we build ours.
Read the published methodThe same method, taught.
Engineering organisations that want to run this way learn it through augmented.club, where the method is taught.
See the programs