Why this is in the vault
Guy Podjarny (Tessl co-founder, ex-Snyk/Blaze CEO) argues on The Analytics Engineering Podcast that skills need a code-like lifecycle (versioning, evals, security review) or teams are just "scaling vibes," and that companies will increasingly own a purpose-built harness rather than rent a frontier lab's — a claim dbt Labs' Tristan Handy corroborates from his own build.
Mapping against Ray Data Co
This directly reinforces the RDCO harness-engineering thesis's central bet: brigade-house (private) as the owned dev harness vs. the generated public ray-plugins surface, and the skill-agent-brigade pattern (station-spec-author → station-test-author → station-code-author → station-critic) already IS the "skill as reusable software with a lifecycle" Podjarny describes — RDCO independently arrived at treating skills as versioned, reviewed, tested artifacts rather than markdown files hoping to stay relevant. Podjarny's three-bucket context taxonomy (policies/specs/workflows) and forcefulness tiers (rules always-loaded / skills hint-loaded / passive docs searched) is a useful diagnostic lens for auditing RDCO's own ~/.claude/skills/ sprawl — the "hundred skills competing for the same sliver of attention" problem is a real and not-yet-addressed risk as the skill count grows (60+ skills currently listed). His owned-vs-rented harness argument, and specifically the point that any org running multiple agent types (coding, legal, DevOps, sales) needs shared context/constraints no single frontier lab's harness manages, validates why RDCO builds sub-agent stations and per-domain configs (see [[2026-07-18-agent-brigade-v2-simplification-design]]) instead of relying purely on Claude Code's native defaults. The cost-driven open-weight-model swap-in argument (GLM 5.1, DeepSeek) is not yet an active RDCO consideration — worth flagging as a periphery-of-knowledge question for /curiosity given RDCO's Anthropic-only model posture today.
The core argument
Podjarny's agentic stack: models are the OS, tools let agents act, context (skills = "the canonical unit of context, the new code") is what actually executes, all wrapped in a harness that sets UX/constraints/container. His core coinage — "the inability to scale vibes" — describes teams that instinct-iterate on prompts solo, then hit a wall the moment a skill is shared or reused: no eval means no way to know if a teammate's change to a shared skill helped or hurt, or whether it truly needs a frontier model vs. a cheaper one. Security exposure compounds this: malicious skills lifted from the open ecosystem, negligent skills missing safety instructions, vulnerable skills that guide an agent into leaking credentials into logs. His fix is treating a skill as reusable software: versioning, quality review, dependency management, evals, security checks — which is what Tessl (an "agent enablement platform") productizes via Tessl Review, Tessl Verifiers, an eval platform, a package manager, and observability tooling. On the second thesis — owning vs. renting a harness — Tristan Handy's dbt Labs experience is the corroborating data point: he expected building a dbt-specific harness to be a bad idea given how good Claude Code/Codex already are, and found "it's not actually that hard to build a harness, and the ability it gives you to tune for your specific factory is pretty profound... I've become a believer in the multi-harness world."
⚠️ Sponsorship
Newsletter is sponsored by dbt Labs (disclosed in-email footer): a dbt Summit 2026 promo block (Sept 15-18, Las Vegas, discount code) appears mid-issue, and the guest interview itself is dbt Labs' own podcast (host Tristan Handy is dbt Labs' founder/CEO) featuring a Tessl co-founder — not a third-party paid placement, but worth noting the interview functions partly as promotion for dbt Labs' own harness-building narrative (Handy's "I've become a believer" quote flatters dbt's own R&D bet). Treat Handy's corroboration as interested-party testimony, not independent validation.
Related
- [[2026-05-01-claw-vs-harness-engineering]]
- [[2026-05-10-harness-moat-two-layers-portability]]
- [[2026-08-01-scaffolding-vs-harness-the-erosion-axis]]
- [[2026-04-23-harness-thesis-cluster-synthesis-kurian-ternus-il]]
- [[2026-06-09-fable5-harness-review]]
- [[skills-as-building-blocks]]