If we treat the context bridge and verification layer as the true “API” of an agent-first team—rather than the Rails app or CLI substrate—how do our current preferences for monoliths, CLI-heavy Unix pipelines, or service-y architectures need to be re-evaluated, and in what concrete situations would investing in a richer shared context/verification API matter more for small-team leverage and apprenticeship than choosing any particular stack shape?

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

Answer

Treat stack shape as secondary to how well you can feed and check agents.

  1. How this revalues monoliths vs CLIs vs services

  • Monoliths

    • Better when: domain is cohesive, most changes touch shared concepts, and tests are strong.
    • Re-eval: prefer layouts that make context-bridge slices small and legible (façades, flows, glossaries) over any particular Rails purity.
    • Risk: monolith with weak context bridge becomes a giant, opaque prompt source; review load stays high.

  • CLI-/Unix-style + services

    • Better when: behavior is naturally pipeline-shaped; contracts are narrow, text-first, and stable.
    • Re-eval: CLI/API design is effectively the context bridge; invest in command schemas, golden scripts, and contract diffs more than in service count.
    • Risk: many small services without good shared context/verification feel worse than a messy monolith.

  • Common shift

    • Judge architectures by: (a) how cheaply you can assemble task-specific context for an agent, and (b) how precise, automatable your verification is.
    • Stack is a means to context/verification clarity, not the goal.
  1. When a richer context/verification API matters more than stack choice

  • Cross-system, high-risk flows

    • E.g., billing, auth, data privacy spanning several apps.
    • Value: shared context bridge that knows the flow graph, key invariants, and test recipes beats arguing monolith vs services.

  • Senior-scarce, junior-heavy teams

    • E.g., 1–2 seniors, several juniors.
    • Value: a strong shared verification layer (lane rules, canned checks, diff explainers) plus good context bridging shrinks the seniority gap more than any language/framework choice.

  • Rapid probes in a stable domain

    • E.g., many reversible hunch probes on top of a mature product.
    • Value: reusable probe templates, scenario fixtures, and probe-specific verification hooks let you explore safely regardless of monolith vs pipelines.

  • Designer-/PM-driven changes

    • E.g., designer-implementers shaping harness flows.
    • Value: a context API that exposes domain entities, flows, and guardrails in human terms matters more than whether the backend is Rails or a CLI mesh.
  1. Concrete design directions for a “context/verification API”

  • Context bridge as API

    • Standard queries: “show me the flow for X”, “contracts touching Y”, “tests that guard Z”.
    • Task packs: small, reusable context bundles per lane/feature that agents can request.

  • Verification layer as API

    • Lane-specific check commands (money, auth, UX glue, probes).
    • Simple, scriptable verdicts: pass/fail plus a short risk rubric that agents and humans both see.
  1. Implications for apprenticeship and small-team leverage
  • Apprenticeship
    • Rich, shared verification scripts + diff explainers turn every review into a repeatable lesson surface independent of stack.
  • Small-team leverage
    • Tiny teams gain more by making context and checks reusable across agents and humans than by optimizing for one “perfect” architecture.

Summary: once context bridges and verification are the real API, you choose monolith vs CLI vs services based on which makes context slices and checks clearest and cheapest to maintain. For high-risk flows, junior-heavy teams, and designer-driven work, investing in richer shared context/verification usually beats further stack bikeshedding.