code-factory.Adversarial verification.
A sandboxed multi-agent software engineering framework, installed under an isolated runtime against my own codebase. The strategic value sits in a UI quality subsystem that scores visual design against a six-pillar adversarial rubric with file:line evidence. Used once for a codebase audit. The framework is GSD; the integration and discipline are mine.
This page covers an integration, not a from-scratch build. The underlying GSD framework was authored by someone else. What I built is the sandboxing, the integration against my codebase, and the operational discipline around using a 60+ skill framework without polluting the parent project. The credit is for engineering judgment, not invention.
Multi-agent coordination patterns. Producer/checker separation, bounded revision loops, model-tier routing, mandatory human gates, and adversarial verification that refuses to grade itself softly.
What code-factory Is.
GSD is an open-source multi-agent autonomous software engineering framework. Built into it: 33 specialized subagent definitions, 66 slash commands, 90 workflow definitions, 60 shared reference docs, 12 lifecycle hooks. It is designed to spawn subagents for parallel work, route tasks to the right model tier, and apply quality gates that refuse to ship soft-graded output.
I installed GSD under a sandboxed runtime against the FORGE codebase. The sandboxing was deliberate. GSD ships 60+ skills. Letting them load into the parent project .claude/ directory would pollute the FORGE environment in ways that would be hard to debug later. Instead, GSD lives under tools/code-factory/.gsd-runtime/. Skills only load when a session explicitly sets CLAUDE_CONFIG_DIR to point at that folder. The parent project never sees them.
I have used code-factory once: a full codebase audit of FORGE on 2026-05-07. The audit produced concrete findings against file:line references, classified as BLOCKER or WARNING, with a revision plan. The UI subsystem (the part most directly transferable as a product) has been built and tested within GSD but has not yet been run against Upswing prospect sites. Honest framing: this is not a heavily-used internal tool. It is a sandboxed framework with a single completed audit and a documented productization path.
The Pieces Worth Pointing At.
A 60+ skill framework is a lot to look at. The pieces below are the ones that demonstrate why this integration is portfolio-worthy.
The producer/checker pattern
A ui-researcher writes the contract; a ui-checker blocks the contract before any UI code gets written.
GSD UI subsystem uses a deliberate separation between contract authoring and contract enforcement. The ui-researcher subagent writes a design contract: tokens, layout system, component inventory, accessibility requirements. The ui-checker subagent then audits the contract before it is locked in. It blocks contracts that would ship known design debt: generic CTA labels, missing empty and error states, more than four font sizes, off-grid spacing values, accent color overuse.
Only after the checker passes the contract does any UI code get written. This eliminates an entire class of failure where AI agents produce surface-acceptable UI that fails on inspection. The checker exists to refuse a contract, not to rubber-stamp it.
The 6-pillar adversarial UI audit
Visual design scored across six pillars, 1 to 4 each, total out of 24, every score justified with file:line evidence.
The audit grades on six pillars: Copywriting, Visuals, Color, Typography, Spacing, Experience Design. Each pillar gets a score from 1 to 4, for a total possible score of 24. Every score must be justified with at least one specific finding referencing file:line. Findings are classified as BLOCKER (must fix before ship) or WARNING (should address).
The adversarial framing matters. Most AI grading systems average upward. They average a 2 and a 4 to a 3 and call the UI "acceptable." This rubric refuses to do that. A single pillar at 1 with three findings of BLOCKER means the whole audit fails, regardless of the other pillars. The system is designed to surface specific evidence, not produce a feel-good rollup.
This is the part of code-factory with the clearest product path. As a standalone tool, it becomes a website quality grader: feed it a URL, get back a scored report with evidence-cited fixes. Agencies could white-label it as a QA gate. Freelancers and small SaaS teams could use it as a self-audit. Marketplace and directory sites could use it on their listings.
The revision loop with stall detection
Producer and checker pass structured YAML issue lists back and forth. Capped at 3 iterations. Hard stall detector. Human escalation gate.
After the initial contract is locked, the build runs and the audit runs. If findings exist, the producer agent gets a structured YAML issue list. It produces a revised build. The checker re-runs. This loop is capped at three iterations.
A stall detector watches for the case where revisions are not converging. If a finding persists across iterations with no progress, the loop halts and escalates to a human. This is the same pattern FORGE uses for site QA: bounded iteration, mandatory escalation, no silent failures.
The sandbox trick
Skills only load when the session explicitly opts in. The parent project never sees them.
GSD ships 60+ skills. Installing it conventionally would mean those skills load into .claude/ and become globally available across the parent project. That is the wrong default for an audit tool that should only run when explicitly requested.
The sandboxing pattern is small and worth pointing at: GSD is installed under tools/code-factory/.gsd-runtime/ instead of .claude/. Skills only load when a session explicitly sets CLAUDE_CONFIG_DIR to point at that folder. Outside a code-factory session, the parent project (FORGE) is untouched. The skills are present on disk and absent from runtime. This is the kind of operational discipline that distinguishes "I ran the install script" from "I integrated the tool."
Registry safety audit
If third-party component registries are in play, the system scans installed blocks for exfiltration patterns.
GSD UI subsystem supports installing components from registries like shadcn. Before a registry component is used, the safety audit scans its source for patterns that should never appear in a static marketing site: fetch calls, process.env reads, eval, remote dynamic imports. If any pattern is found, the install is blocked.
This is defense-in-depth for a non-engineering use case. A trades business site has no business making fetch calls to remote servers or reading environment variables. The audit prevents a supply-chain failure where a registry component carries unwanted code into a customer site.
The Pieces.
The Judgment Calls.
The framework is external. The decisions about how to install, sandbox, and operationalize it are mine. These are the ones worth pointing at.
Refuse to grade yourself softly.
The 6-pillar rubric is built to fail. A single 1-rated pillar with BLOCKER findings means the whole audit fails. There is no averaging away of specific evidence. This is the discipline that distinguishes a real QA gate from a rubber stamp. Most multi-agent code generation systems grade their own work too kindly. The fix is to make adversarial verification structural, not optional.
Sandbox by default.
A 60+ skill framework should not pollute the parent project. The default install location went under a custom runtime directory. Skills opt in via an explicit environment variable. The parent project .claude/ is untouched. Restoring the parent default behavior is one shell command. This is the kind of detail that matters when integrating tooling that ships with a heavy skill catalog.
Bounded loops with escalation.
The revision loop caps at three iterations. Stall detection runs on top of the cap. Escalation to a human is mandatory, not optional. This is the same pattern FORGE uses for site QA, applied here to UI contract enforcement. Bounded loops prevent infinite churn. Escalation prevents silent failures. The combination is what makes an agentic system trustworthy.
Model-tier routing is pinned, not discretionary.
Opus handles deep reasoning. Sonnet handles structured work. Haiku handles cheap analytics. Each subagent definition pins its model. There is no "pick the best one available" logic. This makes runs reproducible and costs predictable, which matters more than you would think for any AI workflow that should ship on a schedule.
File:line evidence, always.
The audit never says "your CTA copy is generic." It says "your CTA copy on line 42 of hero.tsx is generic, here are the three reasons, and here is the recommended replacement." Every finding has location, evidence, and proposed fix. This is what makes the audit actionable instead of frustrating, and it is the single most directly transferable habit for any AI quality system.
Three Documented Product Paths.
Three productization framings are documented in the source notes. Each is a different size of bet.
The smallest, and the most directly transferable: the 6-pillar audit as a standalone product. A website quality grader. Takes a URL, runs the adversarial audit, returns a scored report with evidence-cited fixes. Possible markets: agencies (white-label QA gate or pre-pitch tool), freelancers and small SaaS teams (self-audit), marketplaces and directory sites (listing-quality enforcement).
The middle bet: autonomous build-and-verify as a service. The full GSD lifecycle (research, build, audit, revise, escalate) sold as an AI dev team that grades its own work and escalates honestly. This is closer to a managed offering than a tool. The pitch is the discipline, not the throughput.
The largest, and the least proven: codebase audit and drift detection as a one-off technical due-diligence product. The 4-mapper parallel audit is suited to acquirers, new CTOs onboarding to a legacy codebase, or product leaders inheriting a system without documentation. This one would require the most additional packaging work to ship. The smallest framing has the cleanest product market fit. The largest has the largest potential ticket size. Each is honest about what it would take to get there.
There's More.
code-factory is one of four AI systems on my resume page. The other three (FORGE, Founders Circle, Idea Inbox) are from-scratch builds with full deep-dives of their own.