Model Wars: Codex vs. Claude

FT article prompted debate: is OpenAI taking share from Anthropic?
Consumer brand (ChatGPT) vs. enterprise brand (Claude) dynamic likely explains the shift
Codex adoption among top “agent coders” visible since December/January
- Theo, Dylan, Peter Steinberger all switched early
- Key argument: Codex reads longer by default, eliminating need for explicit research prompts
Token usage as the real proof of model allegiance: post your spend or it doesn’t count
Codex dominates for engineering tasks; Claude/Opus still preferred for UI work and content writing
- Codex output sounds “more AI” for prose; Claude sounds more human

Writing Workflow with AI

Approach: feed transcript, generate section headers + 2-3 sentence snippets, polish manually
Iterate in small increments within one session to build tone and pattern recognition
Anti-patterns doc: flush learned style corrections to a reference doc after several iterations
Key principle: never let the model write three pages at once; overwhelming output gets ignored

Research phase: back-and-forth with model to build interaction mocks (HTML mockups, not pixel-perfect)
Overnight build: queue 15+ prompts, let Sonnet and Claude argue it out, review in the morning
Slop PR as spec: prototype PR used to validate feature direction cheaply, not for production
- Once validated, ask model: “implement this from scratch, how would you break it into phases?”
Ship in 1-3k line PRs; models are good at decomposing 20k-line prototypes into digestible chunks
Kyle picks up final PRs for polish and architecture cleanup

Incoming user feedback is treated as untrustworthy by default
Pipeline stages:
1. Check if issue is already fixed on latest version; notify user if so
2. Deduplicate against existing repros (expected to be imperfect; 50% dedup still saves significant time)
3. Generate a clean, agent-produced repro; if repro fails, escalate to human
4. Create a formal issue only post-repro
5. Run every issue against every PR automatically; cheap CPU-time verification
Difficulty classification: targeting ~60% accuracy; misclassified issues detectable by line count
Evals now backed by a real issue database; first PR with benchmark metrics just shipped
Goal: 95% automatic, not 100%; humans stay in the loop for external data sources and hard cases

Compute / Sandbox: where agent sessions run
- Boundary uses MacBooks and Mac Minis (pre-installed toolchain, zero boot time)
- Alternatives: Daytona, EC2, Kubernetes, cloud sandboxes (E2B, Freestyle, isolates)
- Build vs. buy spectrum: own infra for control; buy for simplicity
Dev Environment: language runtimes, identity provisioning, internal service access
- Identity attached to environment implicitly grants API keys and service scopes
- Pets vs. cattle: Boundary’s MacBook setup is currently “pets”; cattle (on-demand provisioning) is the goal
- Key friction with vendor clouds: poking holes for internal shared services, kernel compatibility issues
- Thesis: own this layer unless building simple Next.js apps
Harness (inner + outer):
- Inner: Claude Code, Codex, Amp, Devon, Factory, or custom on open-codex
- Outer: while loops, skill injection, MCPs, code rabbit integration, agentic merge queue
- Boundary’s outer harness: fix code rabbit → human approves → agent babysits merge queue
- No standard interface between harnesses (ACP too narrow, AgUI lacks hooks); each is bespoke
Control Plane / Orchestration:
- Dispatches work, surfaces session traces, schedules cron/webhooks, manages spend
- Handles PR review, permissions, audit, and compounding engineering (team-wide memory)
- Boundary built their own; listens to Linear, Slack, GitHub via cloud web server dispatcher

Monorepo strongly preferred; multi-repo is painful
Workaround: simulate a monorepo with a coordination repo
- All repos checked out one level up; agent sessions started from one canonical location
- No symlinks, submodules, or subtrees required; model traverses workspace naturally
Avoid git submodules: double-commit problem on every update
Git subtrees worth exploring (better than submodules, less explored)
Cattle approach for on-demand sandboxes is tricky: bulk-cloning 200 repos is slow and disk-heavy
- Pets approach (always checked out) works better at current scale

Full vertical cloud agents (Devon, Cognition) offer convenience but create friction:
- Dev environment customization is limited
- Shared internal services hard to expose to vendor compute
Devon/Cognition “outpost” model interesting: bring your own compute, vendor brings harness
Human Layer’s position: own orchestration layer, harness is swappable (Claude Code, Codex, custom)
Key principle: composition over inheritance
- Shouldn’t have to buy everything below the layer you want
- Open interfaces enable mix-and-match across the stack
“Don’t wrap interfaces with other interfaces; wrap APIs with APIs” (Sprout rule)
Lamp-stack equivalent for agent factories likely emerging; not Next.js/Supabase but harness + dev env + infra

Core idea: let agents write code to extend the app itself (“code mode”)
- Users define custom workflows by writing code that runs on the platform’s stack
- Buy reliability from the vendor; write the logic yourself
Vibe zones vs. no-vibe zones: functional core is locked, interface layer is open for agent-written extensions
VS Code extension model cited as the gold standard: extensions ship without VS Code updating
MCP as a precedent: created ecosystem explosion by defining a clean interface layer
ACP and AgUI exist but neither supports hooks well enough for full harness lifecycle management
Browser wars analogy: owning the harness may be as valuable as owning the browser or mobile OS
Open source control plane unlikely until enough real-world patterns emerge (can’t build React before the web matures)

Record and publish dedicated episode on extendable software / dynamic code generation
Research git subtrees as multi-repo alternative to submodules