"Stop building Foxconn factories for your agents" — @garrytan

Why this is in the vault

Latest installment in Garry Tan's Fat-Skills / Thin-Harness series — the same lineage that RDCO's /skillify and /improve skills are built on ([[2026-04-11-garry-tan-thin-harness-fat-skills]]). It is the single most direct statement yet of the operating model RDCO is trying to run, and it both validates and challenges the current setup. Shared by the founder (iMessage, 2026-06-01 13:32 ET) without comment.

The core argument

Tan built "Garry's List" — ~540k lines of Rails (≈262k app + ≈276k tests). The app was the product; the byproduct — GStack, his agent-coding setup — was the part that mattered. He now argues all that code wrapped around an LLM is a "Foxconn factory": every test, guardrail, validator, and retry loop is "a bet that the worker will fail," a cage bolted onto a worker who can already do the job.

The economics flipped. Old world: model calls expensive, code cheap → write lots of code to ration/harness the model. New world: the model is cheap (and falling) and writes usable code → stop writing code to babysit it; instruct in plain-language markdown and let it write the minimal code needed ("just-in-time software"). The artifact changes shape: a 540k-line Rails app → an agent of markdown + a little code, same capability, more flexible because behavior lives in editable instructions, not frozen logic.

• "Markdown is the program now" — not prompting (ephemeral), but building: versioned, tested, reusable. Markdown = intent/skill/judgment layer; a thin code layer (TypeScript) = the few deterministic things that must never hallucinate (I/O).
• The "skill pack" (his proposed new systems primitive, alongside the harness): the skillify it loop has the agent emit the markdown skill + the minimal code + a unit test for the code + an LLM eval for the skill + an integration test + a resolver (so the agent auto-invokes the skill when relevant) + an eval for the resolver. "A skill pack has tests" — that's what separates it from vibe coding; coverage is what lets a skill change without breaking.
• Tokenmaxing — the price of admission almost nobody pays: be willing to spend on tokens (cites Peter Steinberger / OpenClaw at ~$1M/yr). Rationing model calls is the obsolete instinct; willingness to burn tokens buys "a 1994 head start on the internet."
• "Esalen, not Foxconn" — build environments where the agent is free, not caged. A free system ships rough and trusts you to finish it ("a Ferrari you have to bring a wrench for"); a control system is over-polished. The scarce resource becomes clarity, taste, judgment — "the engineer who writes the least code is often the one building the most."

Mapping against Ray Data Co

Three concrete landings (the load-bearing section):

1. /skillify upgrade (actionable). Tan's skill-pack spec is more rigorous than RDCO's current /skillify: it bundles an LLM eval for the skill, a resolver (auto-invocation routing), and a resolver eval — which RDCO's /skillify does not appear to emit today (it writes SKILL.md + scaffolds tests/ + runs rdco-doctor). Worth verifying against the current /skillify SKILL.md and tightening if the gap is real. Candidate /improve item.
2. Tokenmax validates the existing stance. RDCO already runs an always-on cron suite and has [[feedback_api_cost_budget_controlled]] (don't pause for per-call cost; only stop on quota). Tan's argument says lean harder into this — it's a moat precisely because >99.99% of orgs still ration. Squares with the L5-agent-capability focus.
3. The honest tension — verification. Tan explicitly mocks "a 1,778-line file" that fans every model claim out to five sources and grades them, with a triage gate, retries, and fallbacks, as a Foxconn butter-dish. That is adjacent to RDCO's verification layer (the deterministic audit-newsletter-outputs.py, the /verify-* independent-worker gates per [[feedback_verification_independent_worker_pattern]], adversarial multi-source sub-agents). Do NOT read this as "rip out verification." The RDCO context Tan doesn't have: the parent-loop fabricated 12× in one morning (2026-05-31) — the gates exist because the worker proved unreliable. And Tan is himself pro-lean-verification ("a skill pack has tests"; "90% coverage is magic") — he is anti-cruft, not anti-test. RDCO's verification is already lean (markdown skills + one deterministic audit script + sub-agents, not 276k lines of defensive code), and the not-yet-built pre-send verification gate is load-bearing, not a cage. The right takeaway: audit which RDCO checks genuinely earn their keep vs. which are reflexive caging — a scalpel, not a bonfire.

Related

• [[2026-04-11-garry-tan-thin-harness-fat-skills]] — the foundational piece in this series; source framework for /improve + /skillify
• [[feedback_verification_independent_worker_pattern]] — RDCO's verification-as-independent-worker design (the layer Tan's "butter-dish" critique stress-tests)
• [[feedback_api_cost_budget_controlled]] — RDCO's existing tokenmax-adjacent stance
• [[feedback_calibrate_overconfidence]] — the 2026-05-31 fabrication incidents that justify the verification gates Tan would call cages