"Engineers... STOP Picking GPT-5.6 Sol OR Claude Fable 5… FUSE THEM" — IndyDevDan

Why this is in the vault

Dan formalizes the multi-model "fusion harness" pattern — combine models instead of picking one — which maps directly to RDCO's COO agent architecture decisions about model routing and the /opinion → /fusion → /auto-validate workflow is a ready-to-adapt template for Ben's own harness engineering.

Episode summary

Dan argues that selecting a single best model is the wrong frame in the agent era; the winning move is combining compute across models using a tight orchestration harness. He demonstrates a custom "fusion harness" built on the PI coding agent with three slash commands — /opinion (parallel multi-model response), /fusion (fused synthesis), and /auto-validate (validation-gate-first build loop) — across two tiers: workhorse (Sonnet 5 + GPT 5.6 Terra) and state-of-the-art (Fable 5 + GPT 5.6 Soul). The core insight is that consensus and divergence between models are both signal — consensus builds confidence, divergence surfaces alternatives a single model would discard.

Key arguments / segments

[00:00:00] Framing: "picking is the mistake" — the AI industry wants you to choose a winner; the right posture is AND not OR; model fusion is a renamed but ancient pattern (architect-editor → prompt chaining → agent chaining → model fusion)
[00:01:02] PI coding agent intro — three commands built into the fusion harness: /opinion, /fusion, /auto-validate; demo starts simple with workhorse models (Sonnet 5 + GPT 5.6 Terra)
[00:02:00] /opinion demo on scikit-learn models — two agents run in parallel, cost/speed differences visible side-by-side; "relativity is the best benchmark"
[00:03:00] /fusion demo — a third fusion agent (using the architect model) reads both opinion outputs and synthesizes consensus, divergence, and discards into a single document
[00:05:00] /auto-validate demo — validator agent writes a verification gate before builder runs; builder's output is checked against the gate; failure loops back with structured feedback
[00:07:01] Two constraints of agentic engineering: planning and reviewing; /auto-validate directly attacks the review constraint by pre-generating a machine-checkable gate
[00:10:00] Harder problem: SQLite 1M row bulk insert — upgraded to state-of-the-art models (Fable 5 + Soul at xhigh); Fable 5 faster and cheaper; Soul uses 3x tokens but finds additional speed-up strategies (250–10,000x range claimed)
[00:16:01] Distinction between sub-agent delegation and tight-team fusion: delegation hands off a task; fusion keeps two agents in coordinated parallel with shared context and fused output
[00:20:01] Core thesis stated: "your agent harness is the body that transforms compute into intelligence that works for you — whoever owns your agent harness owns your results"
[00:21:00] Extension ideas for the harness: /debate (n-round structured argument between agents), /parallel (concurrent execution without opinion framing), /coordinate (agents discuss architecture then build together)

Notable claims

[00:02:00] GPT 5.6 Terra completed the scikit-learn opinion in 4.5 seconds / 9K tokens in / 300 out / 3 cents; Sonnet 5 took double the time, 4K more tokens in, 4K more out, ~1 cent more
[00:13:01] In state-of-the-art fusion mode, Fable 5 cost ~10x less than Soul while finishing much faster; Soul used 3x more tokens in xhigh mode
[00:14:01] "Fable is simarter — needs fewer tokens to ship the same work; knowing when not to work is as important as knowing when to work"
[00:18:01] Fusion result for SQLite bulk insert: best speed winner achieved a ~1,000x improvement over naive autocommit; memory winner was WAL-tuned generation
[00:19:00] "Error rate concerns about stacking agents are only valid when you haven't templated your engineering into your system" — well-engineered harness + prompt/context engineering negates the compounding error problem
[00:09:00] Teaser for next week: "Is Anthropic and OpenAI stealing our data while we pay for it?" — sovereign AI / local compute framing incoming

Guests

No guests — solo Dan episode.

Mapping against Ray Data Co

High relevance. Ben already operates at the intersection of Claude Code, multi-agent orchestration, and harness engineering — this video lands in the middle of RDCO's core build surface.

Specific connection points:

COO agent model routing — Ben uses Claude as the primary model but has not formalized a multi-model fusion layer. The /opinion → /fusion pattern is immediately applicable: RDCO could route planning tasks to two models (e.g., Sonnet as workhorse + Fable as architect) and fuse results before committing to a direction in the COO agent skill loop.
Auto-validate as a gate pattern — RDCO's existing verification-as-independent-worker SOP (02-sops/2026-05-19-verification-as-independent-worker-pattern.md) is structurally adjacent to Dan's /auto-validate: a gate is written before the build, not after. The fusion harness operationalizes this at the sub-agent level, which Ben could apply inside individual skill steps.
Harness ownership principle — Dan's thesis ("whoever owns your harness owns your results") directly extends RDCO's rationale for building custom skills rather than relying on Claude Code defaults. The PI agent's customizability is an analog for RDCO's skill system.
The /debate command idea — multi-round adversarial debate between two model-agents before committing to a direction maps well to high-stakes decisions in the COO agent loop (e.g., thesis review, deploy decisions).
phData client work — explaining model fusion to a data/AI client as a pattern for production agentic pipelines (rather than single-model chains) is a concrete consulting differentiator Dan's framing makes easy to present.

[[2026-07-20-indy-dev-dan-engineers-stop-picking-models-fuse-them-transcript]]
[[02-sops/2026-05-19-verification-as-independent-worker-pattern]]
[[02-sops/2026-05-18-implementation-notes-pattern-for-sub-agent-dispatches]]

indy dev dan engineers stop picking models fuse them