"My Super Simple Software Factory (For Agentic Engineers)" — IndyDevDan

Why this is in the vault

IndyDevDan is a tier-1 tracked channel because his content maps directly onto RDCO's own agent-harness architecture (skills, sub-agents, orchestration patterns). This video is a live walkthrough of his "software factory" pattern — code-plus-agents workflows with deterministic gate checks — which is a concrete architectural comparison point for how RDCO's Claude Code harness is currently built (skills + sub-agents + Notion board, with judgment mostly delegated to the model rather than to deterministic code checks).

Episode summary

Dan demos his open-source "Super Simple Software Factory" (SSSF) — a skill that lets an agent operate a Python/YAML-based AI Developer Workflow (ADW) system chaining agent calls with deterministic code checks (lint, type-check, test, JSON-schema validation) at each phase boundary. He walks through three workflows of increasing complexity (a single scout agent, a two-agent plan/build for a UI feature, and a full five-phase plan/build/test/review/document SDLC) against a demo writing app called Inkwell, using a live observability dashboard to show swim-lane traces, prompts, model configs, and per-phase cost. Thesis: "agents plus code beats agents alone" — code is treated as a first-class, deterministic actor alongside the engineer and the agent, and the system is designed to be observable, customizable, and reusable across codebases via a /install skill command.

Key arguments / segments

• [00:00:00] Software factories exist for one reason: leverage on your prompt. Leverage scales with the quality of investment in the factory.
• [00:01:01] Three design principles: observable, customizable, reusable. Full swim-lane observability across models (Kimi K3, Gemini 3.6 Flash, GPT-5.6 variants).
• [00:02:00] Three actors of value creation: engineer, code, agent. "Agents plus code beats agents alone."
• [00:03:00] Live demo begins — Herd terminal multiplexer, Pi coding agent on Opus 5, agentic access (agent orchestrates the system rather than Dan running commands by hand).
• [00:05:00] "Model stack" concept — workhorse/lightweight/state-of-the-art tiers; not fixating on one model, picking per cost/speed/performance tradeoff (Gemini 3.6 Flash at $1.50 in as the cost-effective workhorse).
• [00:07:01] Intermediate demo: plan→build workflow (Kimi K3 plans, Gemini 3.6 Flash builds) adds a light-mode toggle, with two deterministic code checks verifying the build afterward — failures route back to the build agent automatically.
• [00:11:00] Deterministic gate checks are literal code run at phase boundaries (not agent judgment); context handoff between phases goes through a shared session directory, agents must emit validated JSON or re-emit.
• [00:14:00] Full SDLC demo: plan → build → test → review → document, each phase a separately configured agent call with its own model/prompt/tools ("the core four: context, model, prompt, tools").
• [00:17:00] Code walkthrough: the full SDLC is ~180 lines of Python using with blocks to bound each phase; deliberately "staying in distribution" — plain Python, YAML, and a skill, no custom DSL.
• [00:20:00] Reusability: SSSF ships as a skill with a /install command an agent runs to copy the entire factory into a new codebase, plus a "cookbook" of lazy-loaded recipes (new ADW, new agent roster, new config) for extending it.
• [00:23:00] Explicit scale caveat: for a small feature like this, a single agent could have done the work — the factory pays off "at the thousandth run," not the first.
• [00:28:00] Framing line: "Vibe coding is not knowing how your system works and not looking. Agentic engineering is knowing how your system works so well you don't have to look."

Notable claims

• "Agents plus code beats agents alone" — engineers who push everything into skills/sub-agents without deterministic code checks will pay in cost, speed, and hallucinations over many runs (no hard data cited — his own observed pattern from working with engineers in the field).
• Determinism is wired into every agent step: structured JSON I/O validated by code, not trusted to the model, at every phase boundary.
• The system is explicitly "atomic" — templates ship as a starting point, and the stated expectation is the founder customizes tests/plan-quality checks rather than adopting them as-is.
• Kimi K3 described as the first open-weights model to reach the frontier-model tier, but slower due to heavier "thinking."
• Not sponsored — Dan states explicitly "I'm not sponsored, I don't take on any sponsorships," including regarding a Fireworks inference-provider mention.

Guests

Solo-creator video — no guests. IndyDevDan (channel owner) is both host and demonstrator.

Mapping against Ray Data Co

RDCO's Claude Code harness is already the shape of a "software factory" in miniature — skills, sub-agents, a Notion task board, brigade stations (spec-author/test-author/code-author/critic), and fresh-eyes critic gates (verify-vault-write, verify-strategic-output, verify-dispatch, station-critic). The strongest structural parallel: brigade stations already do phase-separated agent calls with a critic gate, which is directionally the same pattern as SSSF's plan→build→test→review→document phases with deterministic checks between them.

The concrete gap this video highlights: SSSF's gate checks between phases are literal code (lint/type-check/test-pass/JSON-schema-validate), not agent judgment, and failures route back to the acting agent automatically without a human or a second LLM call in the loop. RDCO's current gates (station-critic, verify-* family) are themselves LLM sub-agents reviewing LLM output — closer to "agents plus more agents" than "agents plus code." For skills with genuinely deterministic success criteria (e.g., audit-newsletter-outputs.py's I3/I4/I8/I9/I10/I11 invariant checks, the vault-write canonical-schema pre-write checklist, or squarely-deploy's build/TestFlight status checks), a literal code-based gate that runs after station-code-author and only escalates to a critic sub-agent on failure would be cheaper and faster than always spawning a fresh-eyes critic agent. This is worth a scoped look at brigade/skill infra rather than a wholesale rebuild — RDCO's audit scripts (audit-newsletter-outputs.py) already ARE this pattern in one place; the video is a nudge to extend "deterministic code gate before LLM critic gate" more broadly across skills that have checkable invariants.

Secondary, weaker parallel: the "model stack" concept (workhorse/lightweight/state-of-the-art tiers, picking per-task rather than fixating on one model) is already implicit in RDCO's delegation practice (Session = Opus at medium, Fable delegations at high/xhigh, nightly research crons via EFFORT_MAP) — this video doesn't add anything new there, just validates the existing approach.

Related

• [[2026-07-18-agent-brigade-v2-simplification-design]]
• [[2026-07-18-assessment-brigade-v2-phase-gate-design]]
• [[2026-05-18-implementation-notes-pattern-for-sub-agent-dispatches]]