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.