Inside a Build Room · the process
Idea in.
Working software out.
No black box. It starts with people — a workshop frames the real problem — then two AI agents, one that implements and one that validates, build, test, fix and document it autonomously inside guardrails, in the open.
Powered by CodeEasy ↗ — the AutoCode pipeline, created by founder Justin James.
1 · It starts with people
A people-led workshop, before a line is written.
A facilitated engagement frames the real problem with the people who live it — roughly 6–11 days across four phases: Discovery → Architecture → Prototyping → Handoff. Three conversations frame it: with business sponsors (what problem, what success), end users (the real workflow, the frustrations) and technical stakeholders (integrations, security, who maintains it).
Every requirement is logged and prioritised by MoSCoW, across five types:
2 · Crossing the boundary
Vibe-coding speed. Traditional-coding quality.
There are four ways people build software. We add a fifth — visible architecture, not a black box.
- 01
Traditional
“Write every line yourself. Understand every byte.”
- 02
Copiloting
“AI suggests, I decide.”
- 03
Vibe coding
“Describe it, generate it, ship it.”
- 04
Rapid prototyping
“Build to learn, not to keep.”
- 05
Multi-agent autonomous
Define the goal; agents collaborate to build it — inside guardrails, everything visible. Our fifth mode.
3 · Why it takes days, not ten seconds
The honest version — where the time actually goes.
The ads promise you’ll think of an app and AI builds it in seconds. It’s a compelling story and a systematically flawed one — “describe it and it’s built” doesn’t remove the hard work, it hides where it lives. Days isn’t the system being slow; it’s the system being honest.
It’s the loop, not the keystrokes
Every task runs implement → validate → fix → re-validate, often 2–3 times. Generation is cheap; the round-trips are the cost.
A dependency graph, not parallel
No API before the schema, no UI test before the API. Most of a build is sequential — more agents can’t collapse the timeline.
Guardrails throttle on purpose
~20 files and ~1000 lines max per task forces big features into small, reviewable units. Reviewability costs wall-clock by design.
Verification is slow, real work
Wiring, smoke, end-to-end, startup and live UI checks. You can’t generate your way past testing.
Correction is structural
LLMs emit plausible code, not verified code. Subtle wrongness is the normal mode — exactly why drift is flagged after three failures.
4 · Two agents, one feedback cycle
One builds. One checks. On a loop.
Codex claims work and writes code. On completion, the system auto-queues a review for Claude. Pass → next task. Needs changes → a fix flows straight back to Codex.
Codex — the implementer
- Writes new features & modules
- Updates and refactors existing code
- Fixes defects and Claude’s findings
- Runs build · typecheck · lint
Claude — the validator
- Reviews every code change
- Passes it → advances the spec
- Or returns findings → a fix task
- Diagnoses failed tasks
5 · Guardrails keep the agents inside the lines
Autonomous, never unsupervised.
Max files / task
A task touches a capped number of files before it needs approval.
Max lines changed
The diff size of any one task is capped — changes stay reviewable.
Drift flag
A task is flagged after 3 failed attempts — no runaway fix loops.
Blocked paths
Agents can never write to secrets or keys (.env, *.key, credentials).
Approval required
Deleting files, editing package.json or lock files pauses for a human.
Stage gates
Eight gates guard the path to deploy — some auto-pass, some pause for a human.
6 · Verification runs automatically
Six layers of testing — plus the real UI.
Each layer queues as work flows through the pipeline; a failure spawns a fix task straight back to Codex.
And Chrome UI auto-testing: a real browser is driven over the DevTools Protocol, feeding console errors, JS exceptions, failed requests and screenshots back into the fix loop — so the agents verify the running app, not just the source.
7 · Knowledge is captured as it’s built
The docs grow with the code.
Requirements, architecture decisions (ADRs), plans and session summaries are recorded as the project is built — through 88 MCP tools the agents call via the Model Context Protocol. The intent and the history are never an afterthought.
8 · When the code can’t leave the building
The same engine, run entirely on your side of the line.
Some work is too sensitive to send to anyone’s cloud — under NDA, under regulation, or simply too valuable. CloudCode is the private-by-default coding agent behind the pipeline: point it at a model running inside your own perimeter — on-device, in your private cloud, or fully air-gapped — and your code, prompts and context never leave. The Build Room engine, with the API switched off.
CloudCode is built by founder Justin James ↗ — see it on his personal site ↗.
This is the engine in every Build Room
Proof you can hold — in weeks, not quarters.
Crystal clear, and real. Want to know more about CodeEasy — the full pipeline, gate by gate?