Part II: Learning Harness Engineering Anew in Codex

Chapter 6: Verifiable Vibe Coding — Splitting Work, Verification, and Review across Agents

Written: 2026-04-28 Last updated: 2026-06-11

6.1 The Bug That Proves the Thesis

Before writing a single line of multi-agent setup, consider Codex GitHub issue #11354 [10]. A user set subagents = false in their config and called /review. Result: Codex's /review command re-enabled subagents, overriding the explicit config setting. The user's stated preference did not govern the model's behavior. The config file was not authoritative.

This is the strongest possible argument for why verifiable vibe coding matters: you cannot always trust what you configured, let alone what a single agent produced and then reviewed itself. When the tool can silently override your explicit settings, independent verification isn't optional — it's the only reliable check.

That's the principle. Here's what it looks like in practice. Mejba Ahmed ran an experiment: Codex as a subagent inside Claude Code [3]. The result? "The work separated." Claude Code handled design; Codex handled implementation; Claude Code reviewed the output. No single agent was grading its own work. Blind spots shrank.

This is the chapter's core idea: verifiable vibe coding means splitting work, verification, and review across different agents so no agent grades its own output.

"Vibe coding" — LLM-driven natural-language development [7] — is inherently unverifiable when a single agent does everything. Multi-agent separation makes it verifiable. The config-override bug shows why even the harness itself needs an external check.

6.2 Two Mechanisms

Claude Code: Agent Teams

Anthropic's Agent Teams [2] provides:

  • Shared task list: all agents see the same tasks; each claims and executes leaf tasks
  • File locking: agents acquire locks before editing files — prevents conflicts
  • SendMessage: direct peer-to-peer agent messaging
  • Event hooks: TeammateIdle, TaskCreated, TaskCompleted trigger agent reactions

Tested conclusion: "3-5 teammates / 5-6 tasks per teammate" is optimal [2]. "Three focused teammates often outperform five scattered ones."

Codex: TOML Subagents

In Codex, define specialist agents as TOML files in .codex/agents/; an orchestrator agent calls them [13]. Simpler than Claude Code's runtime collaboration, but sufficient for work separation.

As of June 2026, Codex subagent workflows are enabled by default in current releases, but that should not be read as "always spawn agents." Codex documentation frames them as useful when you explicitly ask for parallel investigation, independent review, log analysis, or multiple approaches. The main thread still owns the plan, the integration decision, and the final diff [13].

The more practical Codex verification loop uses built-in slash commands. Use /permissions to move between Read Only and Auto, /plan for pre-edit design, /diff after editing, and /review to have a dedicated reviewer inspect the selected diff [13]. This is the Codex-native translation of Claude Code's Plan Mode / Auto Mode habit.

6.3 Four Verifiable Vibe Coding Patterns

Figure 6.1: Four patterns for verifiable vibe coding — implement-verify split, adversarial review, dependency graph, incremental construction. illustration by author Gemini assisted

Each pattern: (a) when to use it, (b) Claude Code setup, (c) Codex setup, (d) failure mode.

Pattern A: Implement–Verify Split

One agent implements, another writes tests, a third reviews.

When: Implementing new features.

Claude Code setup:


# TaskCreate dependency graph
Task 1: implement-auth-endpoint
Task 2: write-auth-tests [blocked_by: implement-auth-endpoint]
Task 3: review-auth [blocked_by: write-auth-tests]

Codex setup:


# .codex/agents/implementer.toml
name = "implementer"
developer_instructions = "Implement the feature. Write code only. Do not write tests."

# .codex/agents/tester.toml
name = "tester"
developer_instructions = "Write Jest tests for the implemented feature. Use mocks. 80% coverage."

# .codex/agents/reviewer.toml
name = "reviewer"
developer_instructions = "Review code and tests. Check for security issues and edge cases."

Failure mode: If the implementer and tester share the same assumptions, tests become meaningless. Instruct the tester to "write tests from the spec only, without reading the implementation file."

Pattern B: Adversarial Review (Dual-Engine)

Two different models/agents independently review the same code.

When: Critical changes, security-sensitive code.

Claude Code + Codex combination: As in Mejba's experiment [3], Claude Code does design and review while Codex does implementation. Two models' blind spots don't overlap.

Failure mode: If both agents are from similar training distributions, they make the same mistakes. True independence requires different models.

Pattern C: Dependency Graph Execution

Decompose a complex feature into a DAG and execute branches in parallel.

When: Multiple independent modules to develop simultaneously.

Here's a "payment system implementation" DAG:


[payment model] → [payment service] → [payment controller]
                                    ↗
[payment validation] ───────────────
    ↑
[Stripe API client]

In Claude Code, declare this with TaskCreate + addBlockedBy [2]. Agents autonomously claim leaf tasks (those with no pending dependencies) and execute them.

In Codex, an orchestrator agent manages the sequence and assigns tasks to subagents.

Figure 6.2: Payment-system DAG example — Stripe API client and payment model are independent leaves; payment validation feeds into payment service which feeds the payment controller. Agents claim leaf tasks autonomously. illustration by author Gemini assisted

Failure mode: Over-decomposing creates orchestration overhead that exceeds parallelism gains. Principle: only parallelize tasks with no dependencies on each other.

Pattern D: Incremental Construction

Build in small verified steps rather than one large implementation.

When: Complex systems, high-risk changes.

The most important lesson from a Korean developer's multi-agent retrospective [4]: "Iterative beats upfront." Having an agent plan the full architecture first, then implement, is less safe than: minimal skeleton → feature 1 → feature 2, verifying at each step.

6.4 Four Anti-Patterns (What to Avoid)

Figure 6.3: Four multi-agent anti-patterns — collaboration as relay, over-upfront structure, orchestrator as controller, more agents equals faster. illustration by author Gemini assisted

From the Korean developer multi-agent retrospective [4]:

  1. "Collaboration = relay": Agent A completes and hands off to Agent B. This isn't collaboration — agents need to see shared state and work simultaneously.
  1. "More upfront structure is better": Over-decomposing tasks and declaring complex dependencies creates orchestration overhead that dominates the work itself.
  1. "Orchestrator = controller": When the orchestrator tries to control everything, it becomes a bottleneck. The orchestrator declares dependencies; teammates execute autonomously.
  1. "More agents = faster results": Anthropic's experiments found 3-5 optimal [2]. More agents means coordination overhead eats the gains.

6.5 The Minimal Codex Verification Loop

When Codex first touches a repository with a strong Claude Code harness, enforce this loop before any multi-agent sophistication:


1. /permissions → Read Only
2. /plan → analyze repo/harness and propose a change plan only
3. Human approval
4. /permissions → Auto or workspace-write
5. Produce one small diff
6. /diff → human reads it
7. /review → dedicated reviewer reads it
8. Run tests or build
9. Update HANDOFF.md

The point is to prevent the same agent from both writing and approving its own work. /review reads the selected diff and reports prioritized findings without touching the working tree [13]. For sensitive repositories, use long-running features such as /goal only after this loop is routine.

Goal mode is now available across the App, IDE, and CLI, but it does not remove the need for this loop. A good goal has a scope boundary, a risk boundary, and a done condition: a test command, a checklist, a benchmark, or a handoff update. Auto-review and hooks can help catch mistakes, but they do not replace tests, git diff, and human review for high-risk changes [13].

6.6 What MorphLLM's Benchmark Reveals

MorphLLM showed Claude Code and Codex outputs to blind reviewers who didn't know the source [5]: reviewers preferred Claude Code's output 67:25. But on Terminal-Bench, Codex won.

This is exactly why "verifiable" vibe coding matters: benchmark scores diverge from actual preference. An agent's self-evaluation differs from independent verification. Multi-agent separation is the mechanism for closing that gap.

References

  1. Anthropic, "Agent Teams," 2026. [Anthropic, 2026]
  2. Anthropic, "Subagents," 2026. [Anthropic, 2026]
  3. Mejba Ahmed, "I ran Codex inside Claude Code," 2026. [Ahmed, 2026]
  4. B327Roy, "Multi-agent retrospective (Korean)," 2026. [brunch), 2026]
  5. MorphLLM, "Codex vs Claude Code Benchmark," 2026. [MorphLLM, 2026]
  6. OpenAI, "Codex subagents," 2026. [OpenAI, 2026]
  7. Korean Developer, "바이브 코딩 플레이리스트," 2026. [Korean Dev Blog, 2026]
  8. Intuition, "Codex as superapp — multi-agent guide," 2026. [IntuitionLabs, 2026]
  9. Jagtap, "Codex AGENTS.md auto-optimization," 2026. [Jagtap, 2026]
  10. GitHub, "Codex subagents issue #11354 — /review re-enables subagents despite config," 2026. [contributors, 2026]
  11. OpenAI, "Codex CLI slash commands," 2026. [OpenAI, 2026]
  12. OpenAI, "Codex Goal mode," 2026. [OpenAI, 2026]
  13. OpenAI, "Codex auto-review," 2026. [OpenAI, 2026]