Most current governance assumes that routing more work through named, cost-visible agent workflows is desirable; what happens if we invert this and define healthy adoption as “agents are used only where they measurably outperform manual baselines within a problem-class portfolio” — does this outcome-first constraint (a) improve trust and budgeting by legitimizing non-use for many tasks, or (b) stall pilot-to-scale adoption because it demands evidence that is too hard to generate for everyday coding work?

Answer

Defining healthy adoption as “agents only where they beat manual baselines per problem-class portfolio” mostly improves trust and budgeting, but risks stalling scale unless evidence is scoped, lightweight, and portfolio-level, not per-task.

Key effects

1. Trust and budgeting

• Trust usually rises:
  • Non-use is legitimate; devs aren’t pressured to “use the agent anyway.”
  • Leaders can say: “For this problem-class, agents are proven; for others, manual is preferred.”
• Budgeting gets cleaner at the problem-class portfolio level:
  • Spend is justified by measured uplift (speed/quality/risk) vs a manual baseline.
  • Portfolios can include both manual and agent workflows under one budget, shifting mix over time.

2. Risk of stalled adoption

• Stalls when evidence demands are too granular:
  • Per-PR or per-task experiments are noisy and expensive.
  • Everyday work rarely has clean A/B baselines.
• Less risky if:
  • Evidence is sampled (e.g., a few timeboxed trials per problem-class per quarter).
  • Baselines are coarse (median cycle time, defect rate, MTTR) rather than fine-grained.

3. Governance patterns that make this workable

• Use problem-class portfolios as the main unit:
  • For each class (e.g., “small feature changes,” “large refactors,” “incidents”), run small trials to compare agent vs manual.
  • Label classes: “agent-preferred,” “manual-preferred,” “open/exploratory.”
• Require only light evidence to flip a label:
  • E.g., “3–5 representative comparisons showing ≥20% gain or clear quality/risk benefit.”
• Allow exploratory agent use in “open” classes with small exploration budgets and no proof requirement, but don’t call that “healthy adoption” yet.

4. Net answer to (a) vs (b)

• (a) Trust and budgeting improve when:
  • Decisions are clearly per problem-class, not per person.
  • Non-use is normed where agents don’t yet win.
  • Evidence cadence is light (e.g., quarterly), not continuous.
• (b) Adoption stalls when:
  • Teams require rigorous proof for every workflow or small variant.
  • Evidence work is unfunded and added on top of delivery.
  • Leaders treat “unproven” as “forbidden,” blocking exploratory runs that might show value.

So: an outcome-first definition helps trust and spend legitimacy if you treat “measurably outperform” as light, portfolio-level sampling by problem-class. It suppresses healthy pilot-to-scale adoption if you interpret it as strong per-task or per-workflow proof before use.