Most current agent-first designs assume that implementation abundance naturally increases small-team leverage inside a single product engine; how does this assumption break if we instead treat agents as a shared CLI-accessible utility across several loosely coupled teams or products, and what new coordination, craft-bar, and apprenticeship failure modes emerge when judgment leverage depends on cross-team context bridges rather than a tight, high-context group?
dhh-agent-first-software-craft | Updated at
Answer
Treating agents as a shared CLI-accessible utility across loosely coupled teams breaks the implicit “small, high-context group” assumptions. Implementation abundance is now centralized, but context, taste, and verification are fragmented. New failure modes show up in:
- Coordination: cross-team queueing, priority conflicts, and context-bleed between products; harness governance becomes an org-level problem, not a team ritual.
- Craft bar: lowest-common-denominator prompts and verification; generic flows that don’t encode any one team’s taste; opaque cross-product pipelines that no single group feels responsible for.
- Apprenticeship: juniors learn to operate a powerful but generic utility, not to shape systems; skill formation decouples from local craft and becomes shallow “agent ops.”
To keep judgment leverage in this shared-utility model, orgs need explicit context bridges (per-team profiles, lanes, and guardrails) plus clear ownership for harness surfaces; otherwise the shared agent layer drifts toward cost-center tooling with weak craft and weak apprenticeship.