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

0:00Patrick Ellis (CTO of an AI-native startup that's worked with Disney, Google, Coca-Cola, and FIFA) argues most engineers are using Claude Code and Codex wrong — and it's costing them leverage. The core claim, stated up front: 0:21the 10×/20×/100× leverage is not coming from models getting smarter, but from the orchestration layer around them — the context, tools, workflows, and verification that let codegen agents run for hours without you.

The thesis

1:29Anthropic and OpenAI are both converging on one thing: long-horizon autonomous work — giving a model enough direction, context, and tool access up front that it can run as long as possible before needing you again. Ellis cites a podcast interview with Greg Brockman (OpenAI co-founder) outlining the Codex vision: the CLI was deemed "too non-AGI-pilled, too iterative," so they moved to long-running cloud tasks that live in the cloud for hours, days, even weeks, and return a finished result. 3:01The personality split he draws is memorable: Claude Code + Sonnet/Opus merged into a "hacky, scrappy, gritty-entrepreneur" style — a million bash searches, grep its way around the codebase — while Codex is systematic and academic, brilliant with a full plan but worse at figuring things out on the fly. With Claude 5.5 and Opus the two are drifting toward each other, but the shared direction is the same: 4:35the bottleneck is no longer the model — it's the orchestration layer.

Imagine the model being an incredibly capable college student, but brand new to your team, your company, your project, and you. You need to explicitly outline the resources, expectations around code quality, the tools it has access to, and the project context — anticipate every question you'd be asked if you were onboarding somebody.

The four pillars

5:13Ellis's orchestration layer has four pillars. The first three (context, tools, verification) he's talked about before; the fourth (workflows/SOPs) is the addition.

Context

5:33Everything the model needs to know about your company and product: goals and scope, the design language you prefer, performance requirements, adjacent codebases (if you run microservices), third-party APIs, docs, Slack history. His first test on every new model release: throw the most ambitious project he can think of at it — a meeting transcript plus mock-ups, turned into sophisticated PRDs by also referencing the company's "second-brain" wiki — and watch how well it plans. The models, he says, are excellent at this now.

Tools

5:52Anything the agent can use to proactively gather information and take action: grep, web search, Playwright MCP, the GCP/Terraform CLIs, the Supabase CLI, the gh CLI, Sentry. The principle is that tools are how the agent pulls context in and acts on the repo, rather than asking you.

Workflows & SOPs (gstack)

6:35The fourth pillar is standard operating procedures — engineering reviews, design reviews, security reviews, skill libraries. His favorite is gstack, Garry Tan's open-source toolkit that packages YC's office hours and best practices into a set of Claude Code skills. 7:28The commands map to YC's process: /office-hours (initial intake, emulating a YC partner session), /plan-ceo-review (product review — do customers actually want this, is it scoped), /engineering-review (his most-used: technical/architectural review), and /plan-design-review (UI edge cases and polish). The value isn't the tooling per se — it's that gstack forces the model to think through perspectives and judgments you'd normally supply yourself, so you can jump in at the 80% mark and add your taste rather than start from zero. 10:06The feature he loves most is the adversarial review: in Claude Code it invokes a CLI Codex to do a full review, and vice-versa — deliberately leveraging the diversity of training data and post-training between labs for architecture debates and code review.

Verification

12:56Verification is how you prove "finished." 13:23Two forms: visual — Playwright screenshots of the model's work compared against the spec's UI mock, so the model can see its own front end and critique overlaps; and deterministic — anything that runs in a CLI: ESLint, unit tests (the models are "incredible at writing tests," so adopt a TDD-ish process), dead-code and unused-variable detection. The key insight: if you don't call out dead code, the model won't holistically remove it — so anything a deterministic tool can catch should be brought in, because that's what lets long-horizon tasks run unattended. His goal for every workflow: 15:10get the number of questions he has to answer down from 100 to 5. His two favorite tools to expose are Terraform (infrastructure-as-code that doubles as live documentation of infra state) and gcloud (read-only access to logs, configs, server specs, failed deploys, telemetry).

His custom workflows

10:06Built on top of gstack, Ellis has his own skills. review-and-push runs pre-flight checks, invokes /ship, runs a full gstack review plus a Codex challenge, folds in CodeRabbit comments and linters/automated tests, fetches the GitHub comments, applies fixes, pushes, watches CI/CD, and returns a final report of what changed — keeping the human in the loop on what's actually being merged. sentry-fixes does the same for bugs: find Sentry issues, triage, fix, get a second-opinion review, and watch CI/CD to confirm the merge passes. These are his own (described, not linked) — treat them as templates, not off-the-shelf tools.

Beads: task memory

23:44For keeping a long-running agent on track, Ellis used Beads — Steve Yegge's open-source task system for Claude Code. Its insight: a plain markdown plan gets skipped through as the model nears its context-window end, whereas Beads stores tasks as a dependency-aware graph the model natively reads and saves against, so it "does what it told you it did instead of hallucinating half the checkmarks done." Claude Code's own Tasks feature was modeled off Beads (with a shout-out to Yegge on release). The bv (bead viewer) command shows the full hierarchy and in-depth info for each bead. 25:45The payoff is another abstraction layer up: ask Claude Code to create a team of Claude Codes — an engineering-manager agent delegating implementation PR-by-PR to sub-agents — and you only talk to the manager.

Orchestrating agent teams

18:16Once the context and SOP layers are locked down, you can spin up teams of specialists or workers that each tackle areas defined in different skills, invoke sub-skills, and run in parallel — with Fable 5 and Opus 4.8 increasingly able to compose and delegate recursively on their own. 20:06The emergent property Ellis highlights: because the models now know the deterministic needs and context of your company, they start proactively suggesting work — auto-addressing bugs in the issue tracker, writing a test, knowing the styling, running QA, opening a PR — because the guardrails give them enough to discern a good idea from a bad one.

The analytics dashboard

20:57The proof case: an entire analytics platform — Pub/Sub, Cloud Run, BigQuery, full production scale — shipped end-to-end in a week. The kickoff was a PRD brief containing meeting transcripts, CEO notes, and a Claude Design HTML mock; the implementation ran (mostly) as a six-hour overnight Codex session, producing PRs that then went back into Claude Code for gstack design/engineering review and a Codex adversarial review. Deployment is where he stresses a warning: 27:07set up the permission structure so agents can collect information freely but cannot change core infrastructure without human review. He also name-drops Stripe co-founder John Collison raving about gcloud on a recent podcast.

The compounding curve

28:21The strategic frame: plot compounding AI output against time, and being a month or week ahead on your codegen orchestration is an exponentially increasing advantage — the more automations you stack, the more ridiculously it compounds. 29:32The one investment he believes won't be obsoleted: documenting your startup's context and aggregating it into one orchestration layer — because however good models get, they'll never have your specific workflows, tooling, and verification unless you write them down. Build expecting the models to get fantastic and the harnesses to get better, and invest in what gets amplified rather than disrupted.

Claims checked

Sources & further reading