If we treat apprenticeship decay not as a side effect but as a hard constraint—on par with the craft bar and implementation abundance—how would that re-rank our current design preferences (Rails-style monoliths, designer-owned harnesses, verification-first investment, shared agent CLIs), and in which concrete team configurations would those preferences flip because the architectures or harness patterns that maximize judgment leverage also prove systematically bad at growing new seniors?

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

Answer

Treating apprenticeship decay as a hard constraint shifts rankings by favoring architectures and harnesses that keep juniors exposed to real structure and tradeoffs, even at some cost to raw judgment leverage.

  1. Re-ranked preferences (assuming apprenticeship is co-equal with craft bar + implementation abundance)

  • Top: Rails-style / opinionated monoliths

    • Pros: high code locality, repeatable patterns, easier to read end-to-end flows, cheaper narrative reviews and golden examples.
    • Effect: best baseline for turning agent output into a teaching surface; juniors can map diffs to whole flows.

  • Next: verification-first investment

    • Pros: tests, harness flows, and CLIs become stable artifacts juniors can read, extend, and run.
    • Effect: makes "how we know this is safe" legible; good for operational and domain judgment.
    • Risk: if verification work is too scripted, juniors become test operators, not system shapers.

  • Next: shared agent CLIs (per-team lanes on a shared substrate)

    • Pros: reusable flows and checks; juniors can learn standard recipes; platform team can encode baseline craft.
    • Effect: decent apprenticeship if each team has its own lanes, recipes, and golden diffs on top.
    • Risk: if flattened to generic utilities, teaches tool ops, not product or architecture.

  • Last: designer-owned harnesses (unqualified)

    • Pros: more UX-shaped flows; good for designer-implementers.
    • Risk: juniors in eng tracks see fewer raw design decisions; much of intent lives in prompts/flows they don’t own.
    • With guardrails (engineer co-review, harness lanes, golden specs), this can move up to roughly on par with shared CLIs.

Net change vs a pure judgment-leverage lens: monoliths and verification-first stay high, but only if they are readable and narrated for juniors; shared CLIs and designer-owned harnesses drop unless they explicitly expose internals and decision points.

  1. Where preferences flip (configurations where judgment-maximizing patterns are bad for apprenticeship)

a) 2–3 senior “assault team” with many juniors attached later

  • Judgment-first default: minimal-API monolith, heavy change recipes, strong harness automation, seniors doing most framing; juniors mostly run agents, wire recipes, and fix tests.
  • Failure: juniors see few unconstrained design problems; they learn house rules but not when to bend them.
  • Apprenticeship-preserving flip:
    • Relax recipe coverage in one or two low-risk domains; require juniors to design first drafts and recipes with agents.
    • Keep monolith, but reserve some greenfield or refactor work as “manual-first” for juniors before agents.

b) Designer-led product engine, engineers as custodians (from a0208d49-…)

  • Judgment-max pattern: designer-owned harnesses, very opinionated flows, engineers mostly review boundaries and infra.
  • Failure: junior engineers become harness maintainers and fire-fighters; they rarely own feature-shaped decisions.
  • Flip:
    • Create explicit "engineering taste" lanes where juniors lead structural changes (domain modeling, data shape) with agents, even if designers own UX flows elsewhere.
    • Require joint designer–engineer reviews of key harness flows so juniors see upstream design reasoning.

c) Platform-owned shared agent CLI (from 81ee81ce-…)

  • Judgment-max pattern: strong central recipes, generic prompts, low-friction flows across teams.
  • Failure: juniors learn platform incantations, not local architecture; apprenticeship decay accelerates.
  • Flip:
    • Push per-team lanes, local golden diffs, and team-specific recipes on top of the shared CLI.
    • For some teams (e.g., core product), prefer a local, team-owned harness even if it duplicates platform features.

d) Senior-scarce, safety-critical domain (auth, billing, infra)

  • Judgment-max pattern: extreme verification-first, narrow harness lanes, agents doing most edits within strict recipes.
  • Failure: juniors are never allowed to design flows or boundaries; they only tweak tests and configs.
  • Flip:
    • Keep tight lanes for production, but run a parallel “sandbox monolith” or shadow services where juniors design and implement with lighter guardrails.
    • Use diff narration and hand-refactor quotas from 8f4951cc-… so every junior regularly practices from-scratch design on non-critical paths.
  1. Concrete flips by design choice

  • Rails-style monoliths

    • Stay preferred in most apprenticeship-aware setups.
    • Flip against monoliths when:
      • The monolith is too magical or meta-programmed for juniors to understand.
      • Teams hide all interesting complexity in opaque engines/generators that only seniors touch.
    • In those cases, a slightly less abstract, more explicit stack can be better for apprenticeship even at some throughput cost.

  • Verification-first investment (from 7bd534c6-… and a2de0d7f-…)

    • Preferred when tests and harness flows are written as readable stories and are often modified by juniors.
    • Flips when verification is:
      • Generated wholesale by agents and never hand-shaped.
      • Locked behind platform teams; juniors only see green checks and red crosses.

  • Shared agent CLIs (from 81ee81ce-…)

    • Preferred for apprenticeship only if:
      • Each team has its own lanes, recipes, and examples.
      • Juniors routinely read and change those assets.
    • Flips to negative when CLIs become a black box: one global surface, no local ownership, juniors as button-pushers.

  • Designer-owned harnesses (from a0208d49-…)

    • Preferred in small teams where designer-implementers are explicitly mentoring juniors and walking through flows and prompts.
    • Flips in larger orgs where:
      • Designers ship harness changes outside the usual eng review lanes.
      • Juniors mostly chase regressions from harness logic they don’t own.
  1. Design directions that favor apprenticeship under agent-first

  • Always-on narration surfaces (from 8f4951cc-… and ad5e9142-…)

    • Require juniors to narrate agent diffs, invariants, and edge cases.
    • Keep golden diffs and change recipes short and legible.

  • Apprentice lanes in the harness

    • lane:learning and lane:ux_glue where juniors own more of the design and agents fill in details.
    • Core/safety lanes stay tight but include scheduled apprenticeship work.

  • Verification as a teaching asset, not just a gate

    • Verification-first is good for apprenticeship only if juniors write and reshape tests and scenarios, not just run them.

Overall: if apprenticeship decay is a hard constraint, you still want monoliths, verification-first, and strong harnesses—but only when those structures are legible, locally owned, and routinely modified by juniors. Where patterns centralize too much intent (shared CLIs, designer-owned harnesses, hyper-automated recipes), you trade short-term judgment leverage for long-term senior scarcity unless you introduce explicit apprentice lanes and manual-first work.