| name | assisted-mastery |
| description | Makes agent reasoning visible, surfaces tradeoffs, and fades help so humans build judgment. Use when reviewing or learning from agent-written code. |
| alwaysApply | false |
| category | workflow-methodology |
| tags | ["learning","assistance-dilemma","visible-reasoning","tradeoffs","skill-retention","automation-bias"] |
| dependencies | [] |
| tools | [] |
| usage_patterns | ["visible-reasoning","mode-selection","assistance-fading"] |
| complexity | intermediate |
| model_hint | standard |
| estimated_tokens | 2200 |
| modules | ["modules/modes-and-fading.md","modules/tradeoff-ledger.md","modules/research-basis.md"] |
| role | library |
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.
