Turn Claude Code Into Your Own Software Factory: The Four-Pillar Orchestration Layer

Every frontier lab is building for the same thing: agents that take a task and run for hours without you. Most teams haven't changed how they work to match. They still prompt their coding agents the way they did a year ago, in short loops, answering questions as they come.

The leverage in this shift isn't coming from the models getting smarter. It's coming from the orchestration layer around them: the context, tools, workflows, and verification that let an agent answer its own questions. At Snapbar, we've used Claude Code and Codex in production since they launched, and with this setup we shipped a production analytics platform (Pub/Sub, Cloud Run, and BigQuery) end to end in about a week.

This is the written version of my latest video, with the templates I use and a 30-day plan to build the layer yourself. Each section links to its part of the video if you'd rather watch.

The Orchestration Layer Playbook

The free 16-page companion to the video: the framework, checklists, and the 30-day rollout. No signup required.

Download the PDFTemplates on GitHub

The bottleneck moved

Anthropic and OpenAI are converging on long-horizon autonomy: give the model everything it needs up front, then let it run until the work is done, without stopping because it lacks clarity, a tool, or a sense of what the right answer is. Watch from 1:29

On the OpenAI Podcast, Greg Brockman described the "AGI-pilled" vision for Codex. Their first CLI felt too iterative, so they rebuilt Codex around tasks that run in the cloud for hours, eventually days, and come back done.

The two tools started at opposite ends. Claude Code grew up as a scrappy pair programmer: it runs a million bash searches and greps its way around messy, real-world codebases. Codex was the academic: systematic and precise, brilliant when you hand it a full plan, weaker at figuring things out mid-flight. The old rule was Codex when you knew the spec and Claude Code when you didn't. Now the two are converging, and the new rule is simpler: set either one up properly, then let it run.

The mental model I use is onboarding. Treat the model like an incredibly capable college graduate on their first day, brand new to your team, your company, your project, and you. You wouldn't expect a new hire to ship a correct PR without onboarding, so spell out the resources, your expectations for code quality, and the tools they can use, and answer the questions they'd ask before they ask them.

When people say the newest models ask too many questions or go off the rails, I believe them. Usually, though, they're running a new model on an old workflow. If an agent is asking too many questions, it wasn't given enough answers up front.

Try this on every model release. Skip the one-line test prompts and give the new model the most ambitious end-to-end project you can think of. Mine is usually a raw meeting transcript plus a few mockups, turned into detailed PRDs against our company wiki. That's exactly how the analytics project below started. Single prompts can't show you what a model can do over hours.

The four pillars

If the model isn't the bottleneck, what is? Everything you set up around it so it can answer its own questions. I used to describe this as three pillars: context, tools, and verification. The fourth, workflows, is the newest and the one almost nobody builds: the process the model follows, not just the facts it knows. Watch from 5:10

Together, they hold up one loop (plan, use tools, observe, verify, iterate) that runs for hours instead of minutes. They're also what makes parallel agents possible: if every agent needs you to answer its questions, you can't run eight at once. The target I hold myself to is cutting the questions on a long-running task from about 100 to 5.

Pillar 1: Context

Feed the agent everything a new hire would ask for, captured once and reused by every session. Watch from 5:30

This is the inventory I work through:

• Company and product: what you're building, for whom, and why it wins
• Goals and scope: what's in and out of the current push
• Design language: the components, tokens, and tone you prefer
• Performance requirements: budgets, SLOs, and expected scale
• Adjacent codebases: the sibling repos and services it should know exist
• Third-party APIs: the contracts you integrate with
• Docs, Slack, and history: wherever decisions and tribal knowledge live

Consume the exhaust

Don't write context from scratch. Your best context already exists as a byproduct of work: meeting transcripts, task boards, Slack threads, git history, and your team's wiki. Pipe that exhaust in. The analytics platform in the case study below started from a raw meeting transcript and a few mockups.

Start with a CLAUDE.md

Here's the skeleton I start from. Write it for a brilliant stranger, and keep it under about 200 lines:

# {Product}: agent onboarding

## What this is
{2–3 sentences: the product, the customer, and the job
this repo does.}

## Scope right now
IN: {current initiative, e.g. analytics v2}
OUT: {explicitly not now; this stops scope creep}

## Architecture in one breath
{Repo layout, key services, data flow.
Adjacent repos: ../api, ../gallery, ../infra}

## Design language
{Tokens and components to reuse. "Extend, don't invent."
Link the style guide.}

## Quality bar
- Before calling anything done: npm run verify:quick
- Lint must pass; no dead code
- No new dependencies without a note in the PR

## Where truth lives
- Specs and PRDs: /docs/specs
- Decisions: /docs/adr · Wiki: {link}
- Infra state: /infra (Terraform is the source of truth)

## When unsure
Prefer reading the codebase over asking.
Ask only when two valid paths conflict.

The test: could a talented engineer with no history at your company open this file and make a correct PR today? If so, an agent can too.

If you use both Claude Code and Codex, keep one source of truth. Codex reads AGENTS.md, and a CLAUDE.md can import it with a single line, so both tools start from the same context:

@AGENTS.md

Planning with full context up front, the first 10% of the work, can feel like a chore. It's also what lets you skip hundreds of questions mid-run. That's the whole trade.

Pillar 2: Tools

Tools let the agent gather its own context and act on it. Without them, you're back to babysitting. Watch from 14:29

Most of these are one command away. Here's how to give both agents a browser:

# Claude Code (add --scope project to share via .mcp.json)
claude mcp add playwright -- npx -y @playwright/mcp@latest

# Codex
codex mcp add playwright -- npx -y @playwright/mcp@latest

And once an agent has gh, it can answer questions like these on its own:

# The PR and its discussion
gh pr view 1000 --comments

# Exactly what changed
gh pr diff 1000

# How we solved this last time
gh search prs "rate limiter" --repo acme/app --merged

# Why CI failed
gh run view 123456789 --log-failed

A worked example: sentry-fixes

One custom command, sentry-fixes, runs a whole loop, because the agent has the Sentry CLI, gh, and CI access to do every step itself:

1. Find new Sentry issues and triage them
2. Fix the ones worth fixing
3. Get a second-opinion review
4. Watch CI until the fix is merged and passing

Every question an agent answers with a tool is a question that never interrupts you. That's what makes eight agents in parallel survivable. Watch from 14:53

Infrastructure as context: gcloud and Terraform

My two favorite tools to expose are gcloud and Terraform. Watch from 15:17

I use gcloud in a mostly read-only context, for logs, infrastructure config, machine specs, failed deploys, and performance data. It's the fastest way to give an agent real production context, right when I'm rolling something out or triaging a live issue:

# What broke in the last hour?
gcloud logging read \
  'resource.type="cloud_run_revision" AND severity>=ERROR' \
  --freshness=1h --limit=50

# How is this service configured right now?
gcloud run services describe analytics-api --region=us-central1

Terraform does the same for your infrastructure as a whole: the current state, what changed, why, and when, in a form the agent can read. My habit is a drift check. The agent compares what's actually running against the config and surfaces anything that should be written back to Terraform:

# Drift on resources Terraform already manages
# (exit code 0 = in sync, 2 = drift, 1 = error)
terraform plan -refresh-only -detailed-exitcode

# Services running that Terraform may not know about
gcloud run services list --format="value(metadata.name)"
terraform state list | grep google_cloud_run

Free rein to read, a human for changes

This is the warning that matters most. Let agents read freely (logs, config, state), but make no changes to core infrastructure without human review. Watch from 27:07

In Claude Code, that's a few lines in .claude/settings.json. Deny rules always win over allow rules:

{
  "permissions": {
    "allow": [
      "Bash(gh pr view *)",
      "Bash(gh pr checks *)",
      "Bash(gh run view *)",
      "Bash(gh search *)",
      "Bash(gcloud logging read *)",
      "Bash(gcloud run services describe *)",
      "Bash(gcloud run services list *)",
      "Bash(terraform plan *)",
      "Bash(terraform state list *)",
      "Bash(supabase inspect *)"
    ],
    "deny": [
      "Bash(terraform apply *)",
      "Bash(terraform destroy *)",
      "Bash(gcloud run deploy *)",
      "Bash(gcloud iam *)",
      "Bash(rm -rf *)"
    ]
  }
}

An allow list is a convenience, not a security boundary, and a deny list won't catch every variation of a command. The real guardrail is IAM. Run agents as a service account that can only read, so the boundary holds even if a command slips through, and never hand a headless agent your own console credentials:

PROJECT=your-project-id
SA="agent-readonly@$PROJECT.iam.gserviceaccount.com"

gcloud iam service-accounts create agent-readonly \
  --project="$PROJECT" \
  --display-name="Coding agents (read-only)"

for ROLE in roles/viewer roles/logging.viewer; do
  gcloud projects add-iam-policy-binding "$PROJECT" \
    --member="serviceAccount:$SA" --role="$ROLE"
done

# A gcloud profile for agents that impersonates the account.
# You need the Service Account Token Creator role on it.
gcloud config configurations create agent --no-activate
gcloud config set account you@company.com --configuration=agent
gcloud config set project "$PROJECT" --configuration=agent
gcloud config set auth/impersonate_service_account "$SA" \
  --configuration=agent

CLOUDSDK_ACTIVE_CONFIG_NAME=agent claude

Set this up now, before the next jump in model capability forces a rushed rework.

Pillar 3: Workflows

Context is what the model knows; workflows are how it works. A standard operating procedure packages the considerations, judgment calls, and taste your team applies, so the model goes through the same steps you would. That's the difference between a PR you trust and a PR you audit line by line. Watch from 7:28

Start with gstack

gstack packages Y Combinator's accumulated best practices, from Garry Tan and team's office hours to UX coaching and security audits, into skills you can invoke. Some are long, but they force the model through a stack of perspectives before it writes a line of code:

The best part is that these skills interview you. They surface a batch of questions; you answer, let it run, then come back and answer more. The model does 80% of the thinking against industry best practice, and you add your expertise at the end. About half the time I take the recommended answer. I'm picky about the rest.

Then build your own: review-and-push

The highest-leverage move is wrapping primitives like these in skills that encode your own process. My review-and-push skill takes a PR from "ready for review" to "green CI, ready for a human to merge" with one command, like /review-and-push 1000:

0. Preflight ───────── branch, working tree, PR, and auth checks
1. PR setup ────────── create one with /ship if none exists
2. /review ─────────── gstack pre-landing review
3. Codex challenge ─── adversarial: edge cases, races, security
4. Comment fetch ───── human reviewers, CodeRabbit, other bots
5. Triage manifest ─── classify every finding in an audit file
6. Fix and commit ──── one commit per logical group
7. Push and watch CI ─ bounded fix attempts, 30-minute cap
8. Final report ────── what changed, what was skipped, CI state

Why a separate Codex pass when /review already includes one? A differently framed adversarial prompt catches different things on bigger diffs. Using the diversity of training data and post-training across models is my favorite workflow of all: different models, different blind spots. Watch from 9:56

Triage rules, the part worth stealing

Most of the value is in how findings get triaged. Each source starts at a different confidence level:

• Human reviewers start high. Downgrade only after rereading the code and confirming the comment misreads it.
• gstack's /review starts medium-high, and goes high when the Codex challenge independently agrees.
• The Codex challenge starts medium, and goes high with a concrete reproduction.
• CodeRabbit and other bots start low. Read the code and form your own opinion; never upgrade on a bot's say-so.

Then every finding gets one of three decisions:

Every decision, including every skip, goes into a triage manifest before any code changes. Each finding gets an ID, its source and location, a confidence, a decision, and a one-line rationale. Disagreeing with a reviewer is fine; an unexplained omission isn't. The manifest is what makes hands-off work safe, because delegation without a paper trail is just hoping:

### F2 · CodeRabbit · src/api/limits.ts:42
- Category: correctness
- Claim: the rate limit resets on every deploy
- Confidence: low (bot), not confirmed by the code
- Decision: skip with reply
- Rationale: limiter state lives in Redis and survives deploys

A few rules never bend: never amend or force-push, so every fix stays bisectable; never bypass hooks; never push to main; and never reply to a comment without reading the code around it.

Watch CI by run ID

One detail that took me a while to get right: gh pr checks --watch can report a false green right after a push, before the real workflow runs have registered. Watch the runs for the exact commit instead:

HEAD_SHA=$(git rev-parse HEAD)
RUN_IDS=$(gh run list --commit "$HEAD_SHA" \
  --json databaseId --jq '.[].databaseId')
for RUN_ID in $RUN_IDS; do
  gh run watch "$RUN_ID" --exit-status --interval 30
done

Cap the retries, too. Code-level failures get two fix attempts, flaky tests get one rerun with no code changes, and environment problems or failures that also happen on the base branch stop the run and get reported. A 30-minute limit bounds everything.

Package it as a skill

In Claude Code, a skill is a folder with a SKILL.md file that you invoke by name. Here's a minimal skeleton for your own version, with the triage rules above saved as triage.md in the same folder. The full review-and-push principles explain every phase in depth:

---
name: review-and-push
description: |
  Take a PR from review to green CI. Runs a review and an
  adversarial Codex challenge, triages every comment into a
  manifest, fixes in separate commits, pushes, and watches CI.
disable-model-invocation: true
---

Review and push PR $ARGUMENTS. With no number, use the
current branch's PR.

1. Preflight: confirm gh is authenticated and the PR exists.
   Never work on the default branch; stop on a fork's PR.
2. Run /review, then /codex as an adversarial challenge.
3. Fetch every review comment with gh. Drop resolved
   threads, bot boilerplate, and duplicates.
4. Before changing any code, write a triage manifest to
   .reviews/ using the rules in triage.md.
5. Apply fixes as one commit per logical group. Never
   amend, force-push, or skip hooks.
6. Push, then watch CI by run ID: at most two fix attempts
   and 30 minutes.
7. Finish with a short report: commits added, findings
   acted on and skipped, CI state, and one next step.

Keep long runs honest with Beads

Long-running agents need task discipline. A markdown plan gets skimmed as the context window fills, and agents start skipping chunks near the end. Beads, Steve Yegge's open-source issue tracker for agents, keeps them working issue by issue with a real dependency graph, like Linear or Jira built for agents. Claude Code's built-in Tasks feature was modeled on it. Watch from 23:37

bd init                     # set up .beads/ in your repo
bd create "Pub/Sub ingestion for live events" -t task -p 1
bd create "BigQuery schema for sessions" -t task -p 1
bd dep add bd-a1b bd-c2d    # a1b waits on c2d (IDs vary)
bd ready                    # open work with no blockers
bd update bd-c2d --claim    # an agent claims it
bd close bd-c2d             # done, so a1b is ready

When I come back to a long-running session, I open bv, the Beads viewer, to see the task hierarchy at a glance. It's an easy way to check that the agents did what they say they did, instead of hallucinating half the checkmarks. If I sound a little bitter, it's because I've been burned.

Pillar 4: Verification

Context gets the work started. Verification shows the model what finished looks like and what still has to change to get there. That's what lets the loop run without you. Watch from 12:56

Give it eyes

Put the UI mock in the spec, then have the model screenshot its own work with Playwright and compare it with the mock: catching overlap, critiquing its own design, and iterating until they match, with your style guide as the referee. A prompt like this does most of the work:

Open http://localhost:3000/analytics with Playwright at
1440px and 375px wide. Screenshot both and compare them
with docs/specs/analytics-mock.png, using
docs/style-guide.md as the reference. List every
difference in layout, spacing, type, and color. Fix them,
then repeat until the screenshots match the mock.

Make everything deterministic that can be

Anything that runs in a CLI and audits code belongs in the loop. The agent runs these itself and reacts to the output:

• Linters and formatters, like ESLint, so nobody argues about style
• Unit tests. Models are excellent at writing them, so there's no reason not to work close to test-driven, especially on the back end.
• Static analysis and type checks: cheap, instant, and unambiguous
• Dead-code audits, like Knip for TypeScript, which finds unused files, exports, and dependencies
• CI gates: the checks on every push, which agents can watch and react to

I like wrapping the fast checks in one script and naming it in the quality bar in CLAUDE.md, so every session runs it before calling anything done:

{
  "scripts": {
    "verify:quick": "tsc --noEmit && eslint . && knip",
    "verify": "npm run verify:quick && vitest run"
  }
}

The lesson from dead code: if you don't call it out with a tool, I guarantee the model won't find and remove all of it on its own. What isn't checked deterministically doesn't reliably happen, so anything that can be deterministic should be.

Fewer questions, more agents

That 100-to-5 number is the whole game. When I'm switching between eight or ten agents, my short-term memory goes out the window. The only fix is agents that come back already QA'd: set them going, then read the report. Watch from 16:40

The alternative is dangerous. Answer enough permission prompts and you start clicking yes without reading, right up until you approve an rm -rf you can't take back. Guardrails are what make speed safe.

Case study: an analytics platform in a week

Here's what this looks like end to end. At Snapbar, we built a production analytics platform on Pub/Sub, Cloud Run, and BigQuery to handle the spiky traffic of live events at NFL and FIFA scale, with a dashboard, PDF exports, and sharing on top. It took about a week from the first brief to production, and every pillar was in place before the work started. Watch from 20:57

1. Plan (context and workflows). The kickoff was nothing fancy: UI mocks and rough sketches, several meeting transcripts, and notes from our CEO, combined into one PRD-style brief, plus an HTML page from Claude Design to pin down the look and the features. Claude Code and gstack turned it into PRDs, checked against our second-brain wiki, with gstack interviewing me along the way.
2. Implement (tools and task tracking). I handed the plan to Codex overnight. It ran on its own for six hours and finished most of the core work, with Beads keeping it on track.
3. Review (workflows and verification). I brought the PRs back into the original Claude Code session for gstack's design and engineering reviews, and used Codex as an adversarial reviewer in a fresh session to work through the remaining architecture and feature issues.
4. Deploy (tools and verification). The agents helped run the deployment with gcloud and Terraform, including the environment variables, with a human reviewing every change to core infrastructure.

Work that used to take weeks now takes days.

Claude Design as a context machine

Claude Design has become one of my best sources of context for UI work. You can build a whole design system there (iconography, white space, typography), explore directions, and export real design files that anchor the agents' front-end work. I used the same process for this website's new direction: a fun, creative, entrepreneurial workspace instead of another cyberpunk AI theme.

Scaling up: agents managing agents

Once the layer is solid, the next unlock is going up a level of abstraction. Ask Claude Code to create a team of other Claude Code agents and manage them, say five or twenty PRs for one project. You talk to the manager about day-to-day questions, and it delegates the implementation, PR by PR. Watch from 25:45

It works because the sub-agents have enough context to go end to end, and the manager has enough context to manage them. Both come from the same investment in the spec and the orchestration layer. Skimp there, and the whole tree collapses back into you answering questions.

The newest models can do some of this on their own, spinning up specialists for different areas of the code, each invoking its own sub-skills. My review-and-push workflow runs its adversarial pass alongside the core review this way. How deeply agents can nest depends on your tools and runtime. Watch from 18:16

There's an emergent benefit, too. Once the layer is rich enough, agents start proposing ideas, because they know your company, your product, and your quality bar, and they have the tools to research. Point one at your issue tracker and it can pick up a bug, write a test, fix the regression in your existing style, run it through QA, and open a PR. The guardrails don't limit the model. They give it just enough structure to tell good ideas from bad ones, and to package work that actually gets merged.

Three patterns that didn't make the video

These came from my planning notes and were cut for time. Each one removes a whole category of interruption:

1. Classified auto-accept. Bouncing between permission prompts across six to ten agents is brutal, and blanket "accept everything" is how repos get deleted. The fix is a second model acting as a permissions classifier, approving routine requests and escalating the ones that need you. In Claude Code, this is auto mode.
2. Heavy review for high-stakes changes. Claude Code's /code-review ultra runs a team of reviewer agents over a change in the cloud. It's more diligent than any review process I've used, human or automated, so I save it for big architectural changes and keep review-and-push as the everyday workhorse.
3. Routines for self-healing software. Routines run Claude Code on a schedule, on GitHub events, or when something calls their API. Mine: a Sentry alert fires, an agent investigates, and a PR appears, with no human in the loop until review. It's the sentry-fixes workflow, running itself.

Stack these on the four pillars and you go from one agent running well to ten running in parallel. That's the software factory.

Why a week ahead is worth more than a week

Picture a graph with time on the x-axis and your startup's compounding output through AI on the y-axis. Right now, being a week or a month ahead is an exponentially growing advantage, in distribution and especially in your codegen infrastructure. A few more automations than the next team compounds fast. The good news: you only need to be a little further along the curve. Watch from 28:12

The single best thing I invest in, and the one thing I don't worry about becoming obsolete, is documenting our company's context and building the systems that pull it into one orchestration layer. However good the models get, they'll never know your workflows, tools, and quality bar unless you spell them out. So build expecting the models to get fantastic and the harnesses to get much better, and invest in the things that get amplified by that, not disrupted.

The six takeaways:

1. Orchestration layer first, model second. The layer is your ceiling; raise it before chasing releases.
2. Test models with end-to-end tasks. Single prompts can't reveal long-horizon capability.
3. Run agents in parallel, safely. Classified auto-accept and scoped permissions, never a blanket yes.
4. Add a second opinion. Cross-model review between Claude Code and Codex, and heavy review when the stakes are high.
5. Document workflows and skills, not just code. Package your judgment so agents, and teammates, follow the same process.
6. Treat infrastructure as scoped, versioned context. Terraform as the source of truth, read-only cloud access, and IAM set up now.

Your 30-day rollout

Don't try to build all four pillars in a weekend. Build one per week, and end each week with proof that it works:

Week 1: Context

Draft your CLAUDE.md from the skeleton above. Link your wiki, add your latest planning transcript, and point at adjacent repos. You'll know it's working when a fresh session makes a correct, convention-following change with zero clarifying questions.

Week 2: Tools

Install gh, the Sentry CLI, and Playwright MCP. Create the read-only service account, get your infrastructure into Terraform, and add the allow and deny lists. You'll know it's working when you ask "why did staging break?" and the agent answers from the logs, without you opening a dashboard.

Week 3: Workflows

Add gstack and run /office-hours. Adapt review-and-push to your repo, starting with the triage manifest and the hard rules. Use Beads or Claude Code's Tasks for anything that runs for hours. You'll know it's working when one real PR goes through review, an adversarial challenge, and green CI with a single command.

Week 4: Verification and scale

Get linters, tests, type checks, and a dead-code audit into CI, and set up the mock-versus-screenshot loop. Then run two agents on separate PRs, growing toward six to ten only while the question count stays near zero. End with an ambitious overnight run. You'll know it's working when you come back in the morning to reviewed, CI-green work, and read a report instead of a backlog of questions.

The order matters. Tools without context gather noise. Workflows assume the agent can act. And parallelism multiplies whatever process you have, good or bad, so don't start at week four. Track one number all month: questions answered per completed task. Watch it fall from 100 toward 5.

Resources

• The Orchestration Layer Playbook: the free 16-page PDF, no signup
• Templates on GitHub: the review triage rules and the review-and-push principles
• Workflows: gstack, Beads and bv, and CodeRabbit
• Tools: the GitHub CLI, Playwright MCP, the Sentry CLI, the gcloud CLI, Terraform, the Supabase CLI, ESLint, and Knip
• Claude Code docs: permissions, skills, code review, and routines
• Worth a listen: Greg Brockman on the vision for Codex on the OpenAI Podcast

I'm sharing more of these workflows as we build, for Claude Code, Codex, and second brains. Subscribe on YouTube or join the newsletter so you don't miss the next one.