“Fat Skills, Fat Code, Thin Harness” — Commentary on Garry Tan’s Architecture

Why this is in the vault

Extends and sharpens Tan’s thin-harness thesis that we have in the vault (2026-04-11-garry-tan-thin-harness-fat-skills.md). The commentary introduces three specific elaborations that weren’t clean in the original: explicit “Fat Code” layer, the “not allowed to do one-off work” operational rule, and Claudia’s migration principle.

The three additions to the thesis

1. Fat Code as an explicit third layer

Tan’s original framing talked about deterministic vs latent operations but this commentary makes it a named architectural tier:

• Fat Skills — fuzzy judgment in markdown files
• Fat Code — deterministic logic that must execute precisely
• Thin Harness — connections only

The rule: “Do the right thing in the right layer; everything else is architecture astronomy.”

2. “Not allowed to do one-off work”

Hard operational discipline:

• If something will run again, first manually run 3-10 samples
• Approve them
• Solidify into a skills file
• If it runs automatically, add a cron job

The test: “If I ask you to do the same thing twice, you’ve failed.”

3. Migration principle (credit: Claudia)

Architecture isn’t static:

• Deterministic code migrates to the skills layer once it needs contextual judgment
• Skills migrate to code once they become fully deterministic
• “Once you stop fighting this migration, the architecture stabilizes”

This is the same insight as database normalization — you don’t decide the structure upfront; you let query patterns reveal the right shape.

4. Self-rewriting skills (YC example)

Tan’s YC team uses a skills file that:

• Reads feedback from founder events
• Identifies patterns
• Generates improvement suggestions
• Rewrites itself

Result: “okay” ratings dropped from 12% → 4% event-over-event.

Mapping against Ray Data Co

Where we align with the thesis:

1. Fat Skills — 22 skills in ~/.claude/skills/, each in markdown. ✓
2. Fat Code — scripts in ~/.claude/scripts/ (postgrid-api.py, imessage-send-file.sh, vtt-to-text.py, sql-guardrail.sh). ✓
3. Thin Harness — Claude Code CLI + MCP servers + cron jobs. ✓
4. Self-rewriting skills — /improve skill exists. Currently interactive, not fully autonomous. Opportunity to push further.

Where we should tighten discipline:

1. “Not allowed to do one-off work” — I’ve violated this multiple times. Examples from the last 48 hours:

   • Book chapter processing (9 sub-agents): ad-hoc pattern, should be a /process-book skill
   • Responding to shared X articles: ad-hoc each time, could be a /process-shared-article skill (fetch, analyze, file, cross-link, assess dissent/convergence)
   • Manual SoR identification during audit: already pushed into /audit-model, good

2. Migration awareness — I should watch for patterns where:

   • Code is being invoked enough that judgment-adjustment would help → candidate for skill
   • A skill is being called with the same args every time → candidate for code

3. The “twice” test — I should mentally tag every non-trivial action with “if the founder asks me to do this again, is there a skill?” If no, add one.

The migration principle in our system

Looking at recent work:

• /generate-tests started as “write me some dbt tests” (ad-hoc) → became a skill when the testing matrix pattern emerged
• /audit-model started as “walk me through the matrix for this model” (ad-hoc) → became a skill after the MG gold_opp_pipeline case study
• /postgrid started as “can we send a postcard?” (ad-hoc) → became a skill after the API probe succeeded

This is the migration principle in action. Each ad-hoc request that happened more than once got solidified into a skill.

What’s still ad-hoc that should migrate:

• Book/PDF chapter processing → /process-book skill
• Shared-article assessment (X links, Substack posts) → /process-shared-article skill
• Dissent cross-check updates (adding to the harness-thesis-dissent doc) → part of a broader /update-cross-check skill

Related

• 2026-04-11-garry-tan-thin-harness-fat-skills — the original Tan article
• 2026-04-13-moura-entangled-software-agent-harnesses-dead — Moura’s “harnesses are dead” dissent
• 2026-04-13-jaya-gupta-ai-lock-in-state-moat — state layers as moat
• synthesis-harness-thesis-dissent-2026-04-12 — the dissent cross-check
• ../04-tooling/rdco-state-ownership-architecture — our architecture doc; aligns with Fat Skills + Fat Code + Thin Harness
• ../../../.claude/skills/improve/SKILL.md — our self-improvement skill; candidate for more autonomous operation per the YC example