Capability Provisioning (right-sizing to the task)

Choosing model, reasoning/effort level, and context size as one coupled allocation for a given (sub-)task — matching capability to difficulty; distinct from model-routing (its automated, model-axis-only form) and extended-thinking (a single axis).

Also known as: capability provisioning, model/effort/context selection, minimum sufficient setting, task-difficulty routing

Documents (15)

Tensions

Can harness engineering actually solve the AI code quality problem?
from: What is the right approach to building harnesses around AI coding agents, and where are the limits?
Assessment: This is the central divergence in the literature. Osmani is most optimistic, operating from benchmark evidence that harness changes produce dramatic improvements on coding tasks. Böckeler occupies the middle ground, distinguishing solvable from unsolved harness domains. Beck is most skeptical, questioning whether harnesses address the root cause at all. The disagreement is partly empirical (what do the benchmarks actually measure?) and partly about scope (Osmani focuses on task completion; Beck focuses on long-term code value including flexibility). They may not be contradicting each other so much as talking about different time horizons: harnesses help with immediate task success, but the tarpit emerges over accumulated changes.
What is the right metaphor for the human-AI relationship in coding?
from: What is the right approach to building harnesses around AI coding agents, and where are the limits?
Assessment: These metaphors are not mutually exclusive but they lead to different design decisions. Garg's teammate metaphor emphasizes collaboration rituals and may underplay the need for hard constraints (you don't sandbox a teammate). Böckeler's governor metaphor is the most theoretically rigorous but may overclaim the applicability of control theory to creative work. Osmani's engineering metaphor is the most actionable but may miss the social and organizational dimensions. Thoughtworks' organizational metaphor captures the broadest scope but is the hardest to operationalize.
Will better models make current harness practices obsolete?
from: What is the right approach to building harnesses around AI coding agents, and where are the limits?
Assessment: Osmani makes the strongest case for permanence with concrete evidence of scaffolding migration. Beck keeps the door open for the Bitter Lesson hypothesis. The truth likely depends on the type of harness: mechanical safeguards (sandboxes, permission controls) may always be needed, while knowledge-transfer patterns (AGENTS.md, priming docs) may become less necessary as models improve at in-context learning.
Is the model a swappable, commoditized component (so selection is a cost decision), or is model choice load-bearing (so selection is a capability decision)?
from: When working with AI coding agents, how should you select the model, its reasoning/effort level, and its context size for a given task?
Assessment: Both camps are right about different task strata, and the tie is broken by the routing camp's own artifact. Commoditization holds on the bulk/background tier (musistudio and the Pragmatic Engineer are correct that a cheap or open model suffices for a large share of tokens), but model choice is load-bearing exactly on the hard tier — the 'hardest 40%' the routing camp routes AWAY (the Pragmatic Engineer's own gap notes 60%-of-token-spend is not 60%-of-value). nrehiew's 6.5x over-editing spread and stellaraccident's collapse are measured on precisely that hard tier. The clincher the swap camp does not concede: musistudio's OWN per-model transformers (tooluse, enhancetool, reasoning, deepseek, gemini) prove the harness is NOT model-agnostic — every model needs bespoke request/response rewriting just to work behind Claude Code, so the 'any model' artifact self-refutes. Delangue even concedes the frontier gap himself. Verdict: select cheap-and-swappable for bulk, and treat the model as a load-bearing capability decision for the hardest slice — the two positions are not competitors but a partition of the task distribution.
Context size: should you shrink the problem to fit a small usable window (decompose / reset), or grow and trust a large window?
from: When working with AI coding agents, how should you select the model, its reasoning/effort level, and its context size for a given task?
Assessment: The apparent 'grow / trust the big window' position for CODING largely dissolves once retrieval is separated from coding — which is exactly Pocock's move ('good for retrieval, less good for coding') and musistudio's (longContext is a routed escalation, not the coding default). No text argues you should code inside a full 1M window. The only genuine pressure toward trusting a bigger window is the vendor-forward Fable 5 / Opus 4.6 claim that coherence loss is being engineered away — but that is a moving target (convergence 5), not a stable dial, and even the harness paper only relaxed context resets AFTER measuring that the new model no longer needed them. A secondary, live sub-dispute survives: reset vs compact. Pocock, the harness paper and best-practices favor clearing/resetting to a fresh agent; Hills and Osmani lean on compaction. The reset camp has the better argument on today's models — compaction preserves the same anxious agent — but the disagreement is real and unresolved. Verdict: shrink-and-decompose is the default for coding; grow only as an explicit retrieval escalation; prefer reset over compact unless the model version has demonstrably killed context anxiety.
Effort/reasoning: does more thinking make output better, or does more reasoning make it worse (over-engineering / over-editing)?
from: When working with AI coding agents, how should you select the model, its reasoning/effort level, and its context size for a given task?
Assessment: This looks like a head-on collision but is really the corpus resolving a category error, so I keep it as a divergence-under-adjudication rather than a live two-camp fight. The two things bundled into one 'effort' dial are separable: reasoning DEPTH (deliberation and research before acting — what stellaraccident measures as the Read:Edit ratio) versus action SCOPE (how much the model rewrites — what nrehiew measures as over-editing). They are separable but DEFAULT-COUPLED: more reasoning, unconstrained, tends to produce more scope. nrehiew is the empirical bridge — constrained reasoning models are the MOST faithful, proving depth and tight scope combine positively when you address them separately. Fable 5 already acts on this, pairing 'reduce effort' with a distinct anti-over-engineering instruction. The actionable verdict: do NOT cut reasoning depth to fix over-editing (that is stellaraccident's exact grievance and it backfires into shallow, edit-first behavior); keep the depth and add an explicit scope constraint. The failure is treating one knob as if it controls both correctness-depth and edit-scope.
Who selects the model/effort/context — a human deciding per task, or an automatic router — and who is trusted to hold the dial?
from: When working with AI coding agents, how should you select the model, its reasoning/effort level, and its context size for a given task?
Assessment: The human-vs-auto axis is less about capability than about (a) whether task difficulty can be detected a priori and (b) who bears the principal-agent risk. No router in the corpus actually measures difficulty — musistudio routes by token-count and static scenario, and the Pragmatic Engineer's routers infer 'good enough' without a demonstrated oracle — so 'auto' today means 'static-heuristic', not 'optimal'. Automation is safe when the user owns the policy (musistudio) and dangerous when the router profits from the choice (Cursor Auto) or when the provider adjusts the dial invisibly (stellaraccident). Verdict: keep the human holding the difficulty judgment and the effort dial until routers can both measure adequacy and prove neutral incentives; automate only the mechanical dispatch, over rules you own and can audit.

Open gaps (49)