If we treat implementation abundance as a reversible condition that can be turned up or down per area (via capability-tiered agent access, stricter harness gates, or manual-only boundaries), in which real-world cases would deliberately reducing agent use—reintroducing implementation scarcity—produce better outcomes for taste, apprenticeship, and system coherence than maximizing judgment leverage everywhere?

Answer

Deliberately reintroducing implementation scarcity is useful in a few concrete zones where learning, coherence, or safety depend on humans doing real implementation work, not just review.

1. Where reducing agent use helps

• Core domain & boundary seams

  • Areas: domain models, key service boundaries, core Rails models/controllers, routing, authorization, money flows.
  • Why manual-first: these encode system shape and long-term taste; cheap agent edits encourage local "just make it work" decisions that erode coherence.
  • Practice: capability tiers that make these files manual-only or senior-only; agents allowed only for tests, docs, and scratch spikes.

• Apprenticeship tracks

  • Areas: carefully chosen feature slices where juniors are meant to learn design, not just prompt-and-tweak.
  • Why manual-first: constant agent drafts collapse the struggle phase; juniors learn harness use, not modeling, naming, or debugging.
  • Practice: agent-off blocks for juniors ("no agent except for reference"), plus sidecar agents for questions and examples, not diffs.

• New architecture or pattern introductions

  • Areas: first iterations of a new module system, data access layer, event schema, or cross-cutting concern.
  • Why manual-first: early examples become templates; if agents generate them, they mirror general-web patterns instead of local taste.
  • Practice: declare "pattern seed" branches as manual-only until 2–3 hand-crafted examples exist, then open to agents with strict tests.

• High-coupling refactors

  • Areas: large rename/re-shape passes across a monolith, shared helpers, or critical APIs.
  • Why manual-first: agents are good at local edits but bad at holding whole-system invariants; overuse amplifies subtle drift.
  • Practice: humans drive the first passes and write strong verification; agents only run scripted, constrained transformations.

• Taste-critical surfaces

  • Areas: library APIs, DSLs, CLI verbs, central abstractions, and any code meant as a teaching reference.
  • Why manual-first: these are what people copy; agent noise here spreads mediocrity through the codebase.
  • Practice: protect reference modules with higher craft bar and manual-only / senior-only lanes; allow agents in call sites, not in the reference itself.

• Early-stage product shaping

  • Areas: first versions of a new product line or major UX flow.
  • Why manual-first: the main work is discovery and framing; agents bias toward known patterns and inflate scope.
  • Practice: humans sketch and hand-build the first thin slice, then selectively use agents for variants, instrumentation, and edge cases.

2. How to turn abundance down without losing all leverage

• Per-boundary capability tiers

  • Mark boundaries as: manual-only, senior+agent, or open.
  • Let agents write tests/docs almost everywhere but gate core code in key seams.

• Diff-first review + lane shaping

  • Keep agents active in low-risk, repetitive areas (glue, migrations, boilerplate).
  • Require manual-first branches or lanes for areas tagged as training, pattern-seed, or taste-critical.

• Time-boxed scarcity, not permanent bans

  • Use "manual sprints" for juniors and new patterns; then relax constraints once examples and checks exist.

3. When this beats maximizing judgment leverage

• Teams with real juniors and explicit apprenticeship goals.
• Monoliths where architectural erosion is already visible (e.g., cross-boundary drift metrics rising).
• Products whose value comes from a strong, distinctive internal design (Rails-style opinionated stacks, domain-heavy systems).

In these contexts, implementation scarcity in selected areas produces better long-term taste, apprenticeship, and coherence than pushing agents into every lane and relying only on senior review to catch problems after the fact.