If we assume implementation abundance but not a stable product engine—i.e., high agent accessibility, weak domain boundaries, and rotating staff—how does the usual focus on harness ergonomics, reversible probes, and designer-implementers misfire, and what alternative organizing lens (for example, treating the context bridge and verification layer as primary shared infrastructure rather than team craft artifacts) better explains which agent-first practices will actually survive and add value in these high-churn environments?

dhh-agent-first-software-craft | Updated at

Answer

In high-churn, implementation-abundant orgs, many “craft-first” agent patterns don’t stick. A more accurate lens is: treat the context bridge and verification layer as shared infra with owners and SLOs, not as emergent team craft.

  1. How the usual focus misfires

  • Harness ergonomics

    • Misfire: local, lovingly tuned CLIs and sidecar loops assume long-lived teams and stable taste.
    • In churn: harnesses drift, no clear owner, commands rot; new people fall back to generic chat or ad-hoc scripts.

  • Reversible hunch probes

    • Misfire: assumes someone remembers intent and can promote/clean up.
    • In churn: probes become unowned branches, zombie tools, and invisible behaviors that erode the verification layer.

  • Designer-implementers

    • Misfire: assumes persistent designer/product ownership of flows.
    • In churn: designers rotate; their harness flows become opaque to successors and bypass architecture/safety norms.

  • Taste- and aesthetics-led code

    • Misfire: assumes a shared craft bar and stable review bottleneck.
    • In churn: reviewers optimize for “passes tests and closes ticket”; taste norms don’t propagate, so agent output converges to lowest common denominator.
  1. Alternative organizing lens: infra-first context + verification Treat two layers as primary, org-owned infrastructure:
  • Context bridge (what agents see and how)
  • Verification layer (what must be true before merge/production)

Under this lens, practices that survive:

  • Central, minimal context bridge

    • A small, versioned map of systems, domains, and allowed tools that all agents go through.
    • Owned by a platform group, not per-team; updated via PRs like an API surface.

  • Policy-encoded verification

    • Lane-based checks (risk class, data/money, hot paths) enforced in CI/harness, not left to reviewer memory.
    • Human review requirements tied to lane and boundary state, not to who wrote the diff.

  • Harness as thin shell over shared infra

    • Local CLIs just parameterize the central context bridge and verification rules.
    • When teams churn, infra stays; only thin wrappers get replaced.

  • Diff-first, spec-light review

    • Assume reviewers lack deep context; optimize for small, scoped diffs and machine-checked invariants.
    • Story/spec depth varies, but verification and boundary rules stay stable.
  1. Implications for which agent-first practices add value in churn

  • Likely to survive

    • Lane routing tied to verification layer (e.g., migrations, money, and cross-boundary changes always go through stricter paths).
    • Boundary-level "UNSTABLE" modes that flip areas to humans-first until signals clear.
    • Simple, org-wide glossaries and boundary maps embedded in the context bridge.

  • Likely to fade or backfire

    • Highly personalized harness UX and bespoke sidecar setups.
    • Probe-heavy, exploration-centric loops without automatic TTLs and cleanup.
    • Deep designer-owned harnesses without clear infra guardrails.
  1. Sketch of a better organizing model for high-churn environments

  • Single shared context bridge

    • Versioned config that defines: domains, ownership labels, tools per domain, default risk lanes.
    • All agents/harnesses must call through it.

  • Verification layer as a product

    • CI + policy engine that encodes: lane rules, tests required, human approver classes.
    • Metrics: defect rate per lane, UNSTABLE boundary count, review latency.

  • Harness patterns as tenants, not landlords

    • Teams can add commands and flows, but they cannot bypass or silently mutate context/verification.
    • When teams dissolve, infra still works for the next group.

Under this lens, implementation abundance is exploited safely even when teams churn: value accrues in infra that shapes agent access and checks, not in local harness craft or individual taste.