If we flip the current emphasis on monolith + opinionated stack and instead assume a token-efficient but highly modular ecosystem (multiple services, third-party APIs, CLIs) as the default context bridge for agents, which pieces of the existing harness playbook (boundary tags, drift metrics, diff-first review, designer-owned flows) stop working or become counterproductive, and what new coordination or verification mechanisms become necessary to preserve small-team leverage and human-verifiable code across boundaries?

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

Answer

In a highly modular, token‑efficient ecosystem, some monolith-first patterns stop cleanly transferring, and you need more cross-boundary coordination in the harness.

  1. What breaks or becomes counterproductive

  • Boundary tags (per-repo/monolith)

    • Weakening: tags tied to dirs in one codebase don’t see SaaS APIs, CLIs, or other repos.
    • Failure mode: local cleanliness hides system-level spaghetti (ad-hoc cross-service calls, glue scripts).
    • Counterproductive when: teams over-optimize for intra-service purity while ignoring flaky contracts and auth sprawl between services.

  • Drift metrics (inside one codebase)

    • Weakening: cross-boundary changes show up as “just another HTTP call” or CLI invocation; drift tools see nothing.
    • Failure mode: architecture drifts at the integration layer (bash glue, infra as code, workflow engines) that has no tags.

  • Diff-first review (single-repo mental model)

    • Weakening: safety depends on changes in several repos, IaC, and external configs; a single diff hides coupling.
    • Counterproductive when: reviewers accept each small diff as “safe” while no one reviews the composed behavior.

  • Designer-owned flows (within one app)

    • Weakening: flows now orchestrate external APIs, CLIs, and data moves.
    • Failure mode: designers can ship powerful cross-system automations without clear owners for quotas, failure modes, or rollback.
  1. New coordination/verification mechanisms

  • System-level change intents

    • Require a short “change intent” per multi-system modification: which services/APIs, data paths, and failure classes it touches.
    • Harness: agent annotates PRs and scripts with inferred intent; humans confirm.

  • Cross-boundary contracts registry

    • Treat API schemas, CLI contracts, and data contracts as first-class.
    • Harness: store them in a central registry; agents diff them, detect breaking changes, generate contract tests.

  • Integration lanes and composite review surfaces

    • Add a lane for cross-system changes: aggregate the relevant diffs (code, IaC, workflows) into one review view.
    • Policy: high-risk integrations must be reviewed in this composite view, not as isolated PRs.

  • Verification layer focused on flows, not files

    • Promote end-to-end checks that hit real services (or faithful mocks) for key flows.
    • Harness: scenario tests per user/task flow; agents maintain them and run them on integration changes by default.

  • Agent-visible topology map

    • Maintain a simple map of services, CLIs, and key third-party systems plus who owns them.
    • Harness: agents must consult this map before wiring new calls; warn on unknown or deprecated paths.

  • Ownership and safety tiers for tools

    • Classify tools/APIs into safety tiers with clear owners.
    • Harness: restrict which flows (and which roles) can call high-tier tools; log and review usage.
  1. What still works but must be generalized

  • Boundary tags → domain boundaries

    • Move tags up a level: tag services, APIs, and data domains instead of just directories.
    • Use them to limit cross-domain flows and drive integration reviews.

  • Drift metrics → contract and coupling drift

    • Track: new cross-domain edges, contract changes without matching tests, growing glue code.
    • Use periodic “integration sweeps” instead of only monolith sweeps.

  • Diff-first review → diff-plus-flow review

    • Keep reading diffs, but always show them in the context of affected flows and contracts.

  • Designer-owned flows → designer-owned scenarios

    • Let designers own user journeys and scenario tests.
    • Require shared engineer sign-off for any flow that crosses domains or uses high-risk tools.

Net: in modular ecosystems, harness logic must move from “keep this repo clean” to “keep these flows and contracts coherent,” or small teams lose leverage and human-verifiable code at the seams.