Assisted Mastery

A finished diff hides the thinking that produced it. The

thinking is what the human needs to keep. Show the work, surface

the choices, and hand back the parts worth struggling with.

Assisted Mastery

Overview

A coding agent that always returns the finished answer is maximally helpful to throughput and quietly corrosive to skill. The learning-science evidence is consistent: instructional support that helps a novice actively harms an expert (the expertise reversal effect, Kalyuga et al. 2003), so help must fade as competence grows rather than stay constant. Struggling with a problem before being shown the solution produces deeper understanding and transfer than being handed the answer (productive failure, Kapur 2008). And offloading the thinking to a tool measurably reduces what the human retains (the cognitive offloading and critical-thinking correlation of r = -0.75, Gerlich 2025; the Google effect, Sparrow et al. 2011).

This is the assistance dilemma: the same help that speeds the output erodes the judgment needed to verify it. The danger compounds with automation bias: AI-assisted developers in a controlled study wrote less secure code while believing it was more secure (Perry et al. 2023). You cannot verify what you do not understand, and a fluent diff signals competence it has not earned.

This skill does not slow down throughput work. It makes the reasoning a first-class deliverable alongside the code, surfaces the tradeoffs before a design is locked in, and lets the human choose how much of the work to keep for themselves.

The Three Practices

1. Make the reasoning visible

For any non-trivial change, emit the reasoning alongside the diff, sized to the blast radius:

• Assumptions: what the change takes for granted about the

codebase, inputs, and environment.

• Alternatives considered: the two or three approaches that

were viable, and why each was rejected.

• Ramifications: what this design makes easy later, what it

makes hard, and what would have to change to reverse it.

A high-blast-radius change with no stated reasoning is treated as incomplete, the same way an apprentice who "just did it" without showing their thinking would be sent back. This mirrors cognitive apprenticeship: the expert's invisible reasoning must be externalized before anyone can supervise or learn from it.

2. Surface tradeoffs before choosing

Do not present a single design as inevitable. State the decision, the options, and the axis each option wins on, then make the call and say why. Record consequential decisions in the tradeoff ledger so the reasoning is auditable later and the human can challenge it now. This is how novices were always trained into experts: by working through the positives, negatives, and ramifications of a decision, not by copying the conclusion.

3. Choose the mode, and fade it

Pick the assistance mode deliberately per task, and reduce it over time on skills the human is building. See modes-and-fading.md:

• Explain mode: the agent narrates the reasoning and the human

writes the load-bearing code. Builds judgment. Use on unfamiliar territory, high-stakes paths, and skills the human wants to own.

• Produce mode: the agent writes, the human reviews. Maximizes

throughput. Use on boilerplate, well-understood patterns, and reversible low-stakes work.

Default to produce mode for commodity work and explain mode where understanding is the point. As the human's competence on a given area grows, fade from produce toward explain to manual: permanent scaffolding is the failure mode, not the goal.

When to Use

• An agent produced code the human will have to maintain, review,

or be accountable for.

• The change touches an unfamiliar subsystem or a high-stakes path

(auth, migrations, money, concurrency).

• A design decision has more than one defensible answer.
• The human is trying to build skill in an area, not just ship.

Skip it for trivial, reversible, well-understood edits where the reasoning is self-evident: forcing a ledger entry on a typo fix is ceremony, and ceremony trains people to ignore the gate.

Red Flags

Related Skills

• imbue:graduated-implementation: the other direction of the same

axis. This skill fades scaffolding; that one ramps the ambition of the next increment as understanding is demonstrated.

• imbue:proof-of-work: evidence that the code works; this skill

adds evidence that the human understands it.

• imbue:rigorous-reasoning: anti-sycophancy when evaluating the

agent's stated tradeoffs rather than deferring to them.

• imbue:karpathy-principles: think-first and simplicity, the

pre-implementation companion to visible reasoning.

• leyline:decision-journal: the durable home for tradeoff-ledger

entries that outlive the session.

• leyline:risk-classification: choosing the automation tier from

the task's risk, the input to mode selection.

The measured evidence for blind-trust failure, the learning-science basis for fading, and the six workflow principles are preserved in research-basis.md.

Exit Criteria

• [ ] Non-trivial changes ship with stated assumptions,

alternatives considered, and ramifications, sized to blast radius.

• [ ] At least one consequential design decision in the session is

recorded with its rejected alternatives.

• [ ] The assistance mode (explain or produce) was chosen

deliberately and stated, not defaulted to "produce" silently.

• [ ] On a skill the human is building, assistance is lower than it

would have been at constant scaffolding (fading is applied).

Modes and Fading

How to choose an assistance mode per task and reduce it over time.

The Two Modes

Explain mode is not "produce mode with a paragraph attached." In explain mode the human writes the part that matters, and the agent withholds the finished answer so the struggle that builds judgment actually happens. The agent models the approach, points at the relevant interfaces, and reviews what the human writes.

Choosing the Mode

Tie the choice to risk and to whose skill is at stake:

1. Classify the task risk (see leyline:risk-classification). 2. Ask: is the goal to ship this, or to build the human's skill in this area? 3. Map:

State the chosen mode explicitly. A silent default to produce mode is how scaffolding becomes permanent.

The Fade Protocol

Expertise reversal means constant help eventually hurts. On any area the human is deliberately building skill in, assistance should decrease across encounters:

produce  ->  explain  ->  manual with review  ->  manual
(agent writes)  (human writes,   (human writes,        (human writes,
                 agent narrates)  agent reviews)         agent silent)

Move one step toward manual each time the human demonstrates they can do the previous step unaided. This is the apprenticeship fading model: support is withdrawn on purpose as competence grows, the opposite of permanent dependence.

Dropping a Tier on Confusion

Borrowed from aviation's "children of the magenta" lesson: when the automation is not doing what is needed, the operator must downgrade the level of automation rather than re-issue the same command at the same level. For coding agents:

• After two consecutive failed attempts of the same shape (same

file, same error class, same tool), do not try a third blind variation. Drop to a lower tier: switch to explain mode, run a read-only diagnostic, and have the human state what they believed and what the evidence now says.

This is the two-challenge rule already encoded in the project's global guidance, applied as a deliberate automation downgrade.

Research Basis: Assisted Mastery and the Verification Spine

The evidence base behind this skill and its sibling imbue:graduated-implementation. The SKILL.md Overview summarizes the load-bearing findings; this module preserves the full tables, cross-domain mechanism, and citations for auditing the claims. It also records the six workflow principles this research recommended, four of which this skill and its siblings now implement.

Thesis

The problem with AI-generated code is not the tool: it is blind trust of the tool's output. Experienced developers catch the flaws (bad architecture, hallucinated APIs, over-abstraction, outdated syntax); novices cannot, because you cannot verify what you do not understand. The historical fix for the analogous problem (novices copy-pasting from Stack Overflow) was not to ban the source: it was to force learners through implementation, trial-and-error, and explicit tradeoff reasoning until they understood the ramifications of design decisions. The design question for any coding-agent workflow is therefore: does it force understanding and verification, or does it enable blind acceptance?

Thread A: the flaws are real and measured

The expert-vs-novice gap is itself documented. A study of LLM-assisted debugging (arXiv 2505.08063) found novices fall into "rabbitholes of over-reliance" because they cannot verify output they do not understand. Simon Willison's position is the same from the other side: LLMs amplify existing expertise, because experts can spec precisely and judge viability. The contrarian view (Ptacek, "My AI Skeptic Friends Are All Nuts") argues skepticism is often craft gatekeeping: included for tension, but the controlled studies (Perry, METR) weigh against the strong form of it.

Thread B: how expertise is actually built

The learning-science literature explains why blind acceptance fails to build skill, and what does:

• Productive failure (Kapur 2008; meta-analysis Sinha & Kapur

2019): struggling with a problem before instruction produces deeper understanding and transfer than being handed the answer.

• Deliberate practice (Ericsson 1993): expertise comes from

effortful practice at the edge of ability with feedback, not from exposure to finished solutions.

• Desirable difficulties (Bjork 1994, 2011): conditions that slow

apparent performance (reduced feedback, effortful retrieval) improve long-term retention.

• Cognitive Load Theory and the expertise reversal effect (Sweller

& Cooper 1985; Kalyuga 2003): scaffolding that helps a novice actively harms an expert. Support must fade as competence grows. This is the assistance dilemma.

• Google effect (Sparrow 2011): when a tool will hold the answer,

we remember where to find it rather than the content itself.

An agent that always produces the finished diff is maximally helpful to throughput and maximally harmful to skill: it is permanent scaffolding that never fades, and it offloads exactly the reasoning that builds judgment.

Thread C (TRIZ): the convergent cross-domain mechanism

The contradiction: more tool autonomy and output volume (speed) degrades human understanding, verification, and retained skill (quality). Five high-stakes domains converged independently on the same three-part resolution:

1. Insert an intermediary verification step before the irreversible effect. Aviation pre-flight, WHO surgical checklist (complications down up to 40%), nuclear STAR, finance four-eyes. The aid never directly causes the consequential outcome without a gate. 2. Force the reasoning and state to be spoken aloud and closed back. Surgical read-back, nuclear three-way communication, aviation mode call-outs, cognitive-apprenticeship visible thinking. Tacit belief becomes a challengeable statement. 3. Make autonomy graduated and reversible, with a pre-licensed trigger to downgrade it. Aviation automation tiers and "children of the magenta," apprenticeship fading, the two-challenge takeover rule.

The single strongest rule, from automation-bias research (medicine: correct decision support cut errors ~40%, but incorrect support raised them ~25-33% and reduced independent verification): the agent must never be the sole verifier of its own high-stakes output, and verification effort must be designed to rise, not fall, exactly when the agent is most confident.

Thread D (code): mechanisms already built in the wild

What this means for night-market

This codebase already implements most of the verification spine: imbue:proof-of-work (STAR/evidence), imbue:scope-guard (over-abstraction), imbue:rigorous-reasoning (anti-sycophancy), imbue:karpathy-principles (think-first), leyline:decision-journal (ADRs), attune:war-room (council), and the two-challenge rule in the global CLAUDE.md.

The gaps this research exposed, now closed on this branch:

1. The assistance dilemma (this skill, imbue:assisted-mastery): visible reasoning, explain/produce modes, and fading scaffolding. 2. Active package-hallucination defense (imbue:dependency-verification plus the guard_package_hallucination.py hook). 3. Graduated autonomy (imbue:graduated-implementation plus the guard_scope_ramp.py hook, and the leyline:risk-classification automation-tiers module). 4. Independent verification for high-stakes changes (imbue:proof-of-work independent-verification module: the producing agent may not be its own sole verifier).

The six recommended principles

1. Verification effort must rise with agent confidence and blast radius, not fall. 2. For high-stakes changes, the producing agent may not be the sole verifier. 3. The agent's reasoning (assumptions, alternatives, why rejected) must be visible and sized to blast radius, not hidden behind a finished diff. 4. Assistance should be choosable and fade-able: an explain mode that builds the human's judgment, distinct from a produce mode for throughput. 5. Any suggested dependency must be proven to exist before it is recommended or installed. 6. Tradeoffs must be surfaced before a design is chosen, not reconstructed after.

Provenance

Originally captured as research session 19c28f3c (2026-06-01; channels: code, discourse, academic, triz). Session 3dfdba53 (see graduated-implementation modules/research-basis.md) extended it with the graduated-practice advancement criterion.

Sources

Full citations are embedded inline above. Primary controlled studies: Perry et al. 2023 (arXiv 2211.03622), METR 2025 (arXiv 2507.09089), Spracklen et al. 2024 (arXiv 2406.10279). Pedagogy: Kapur 2008, Ericsson et al. 1993, Bjork & Bjork 2011, Sweller & Cooper 1985, Kalyuga et al. 2003, Sparrow et al. 2011. Cross-domain: WHO Surgical Safety Checklist, NRC human-performance tools (STAR), CRM two-challenge rule, four-eyes principle.

Tradeoff Ledger

A lightweight record of a consequential design decision: the options, the axis each wins on, the choice, and the reasoning. It makes the decision auditable later and challengeable now, which is how working through tradeoffs builds the judgment that blind acceptance never does.

When to Record

Record a ledger entry when a decision has more than one defensible answer and is costly to reverse:

• Choosing a data structure, schema, or interface that others will

build on.

• Selecting a library or pattern over alternatives.
• Trading off simplicity against flexibility, or speed against

clarity.

Do not record trivial or obvious choices. A ledger full of ceremony entries trains people to skip it.

Entry Format

## Decision: <one line>

- Date: <YYYY-MM-DD>
- Context: <what forced this decision>
- Options:
  - A. <option>: wins on <axis>, loses on <axis>
  - B. <option>: wins on <axis>, loses on <axis>
  - C. <option>: wins on <axis>, loses on <axis>
- Choice: <which, and the deciding axis>
- Ramifications: <what this makes easy, what it makes hard,
  what reversing it would cost>

Where It Lives

For a session-local decision, keep the entry in the working notes or PR description. For a decision that should outlive the session, promote it to the project decision journal via leyline:decision-journal, which is the durable, indexed home for tradeoffs and lessons learned. The ledger format above maps directly onto a decision-journal entry.

Why Three Options

Two options is a yes/no framed as a choice; it hides the real design space. Forcing a third viable option surfaces the axis the binary was concealing. Stop at the point of diminishing returns, usually three to five, rather than enumerating every theoretical possibility. The global guidance to "generate 3-5 approaches before choosing" is the same rule, applied to design decisions.