Adaptive Scaffolding Needs Contingency: An AI Tutor That Escalates and Fades on What the Learner Does
Authors: Xinmeng Hou, Yuxuan Weng, Chin Hsien Yeh, Ding Lin Lee, Lishan Zheng, Fang Li, Wuqi Wang, Yang Liu
Organizations: National Institute of Education, Nanyang Technological University Singapore, Singapore · School of Computer Science and Engineering, Nanyang Technological University Singapore, Singapore · School of Art, Design and Media, Nanyang Technological University Singapore, Singapore · College of Computing and Data Science, Nanyang Technological University Singapore, Singapore · School of Information Engineering, Chang’an University Xi’an, China
Coding assistants raise task performance, but learners plan and monitor less. Giving less away, the usual fix, conflates two things: how much work a system carries (cognitive load) and what the learner must decide before help arrives (metacognitive demand). Our principle, preserved metacognitive demand, holds the second constant and lets the first vary. CoMeT implements it: support rises when a learner fails at a decision point and fades on take-up. Within subjects, 131 adult learners used CoMeT, an unrestricted assistant and a question-only tutor on three Python tasks. CoMeT matched the question-only tutor's demand, delivered artifacts twice as often as the assistant, and frustrated learners less than the question-only tutor, with delegation and load unchanged. Learners often did not answer. Fading held when their turn addressed the decision under support, and CoMeT surrendered the full answer in one session in sixteen, against one in six for the question-only tutor.
Figures & tables
System
Withholds
Structures
Gates
Escalates
Fades
Prior LLM systems
Unrestricted
–
✓
–
–
–
Hint tutor ( Bassner et al., 2024 )
✓
–
–
–
–
CodeHelp ( Liffiton et al., 2023 )
✓
✓
–
–
–
CodeAid ( Kazemitabaar et al., 2024 )
✓
✓
–
–
–
Question-only ( Westbye et al., 2026 )
✓
–
–
–
–
Table 1. The design space as five properties of a design. Withholds : keeps the answer back. Structures : supplies structuring alongside. Gates : makes release contingent on what the learner has shown. Escalates : increases support on demonstrated failure. Fades : withdraws it on success.
Figure 2. The contingency dimension. Grey points are prior systems; an arrow is a release made once, labelled with its trigger; Tutor C escalates one rung at a time and returns to the first on take-up. Shaded bands mark where each failure mode becomes more likely. Positions are illustrative. A two-dimensional plot with cognitive load carried by the system on the horizontal axis and metacognitive demand on the learner on the vertical axis. Grey points mark prior systems near the low-demand region. Tutor A sits at high load and low demand, Tutor B at low load and high demand. Tutor C starts beside Tutor B and steps rightward along three labelled rungs, with a dashed arrow returning it to the first rung on take-up. Shaded bands near each corner are labelled unproductive success and unproductive failure.
Figure 3. The CoMeT interface under Tutor C across the three phases of one task: (a) Planning, editor locked and sketchpad active; (b) Monitoring, editor unlocked; (c) Evaluating, self-review before the gate opens. Numbered regions are named in the key. Four quadrants. Three are annotated screenshots of the same web interface, one per phase. In (a) Planning, a task statement sits at top left, a phase stepper runs across the top, a sketchpad panel is in the centre, the code editor is greyed out, and a chat panel is on the right. In (b) Monitoring, the code editor is active with a terminal below it. In (c) Evaluating, the stepper has advanced to review and submit, the chat panel carries a self-review prompt that the learner answers before the tutor replies, and a submit button has appeared in the top bar. The fourth quadrant is a key naming the eight numbered regions: task statement, phase stepper, the gate, sketchpad, code editor, tutor chat, terminal, and the self-review turn.
Figure 4. The two baselines. (a) Tutor A answers or builds on the first ask. (b) Tutor B returns one metacognitive question and releases only through the welfare floor, on surrender. Placement, the gates and the event record are shared with Tutor C. Two flow diagrams side by side. Left, a learner turn enters Tutor A and exits in one step as either a direct answer or a built artifact placed in the workspace. Right, a learner turn enters Tutor B and exits as one metacognitive question; a separate branch labelled welfare floor releases the artifact only when the learner states they are giving up. Both diagrams end in the same placement and event-record box.
Figure 5. Tutor C. One ladder over the task’s authored decision points: take-up returns it to the first rung and moves to the next open point; no take-up raises it one rung, through three asks, after which that point alone is conceded. A flow diagram of Tutor C. A learner turn enters a support ladder over the current open decision point: the tutor asks, the learner replies, and the reply is judged. A reply judged to take the support up returns the ladder to its first rung and the tutor advances to the next open point; a reply that does not raises support one rung, and once the asks for that point are spent the tutor concedes that point alone and moves on. Side boxes show the authored coverage points, how a reply is judged, the ladder reset, the stage gates, the welfare floor, where artifacts are placed, and the events recorded each round.
n
%
Age
18–20
17
13.0
21–23
79
60.3
24–26
31
23.7
27 or older
4
3.1
Gender
Table 2. The analysed sample ( N=131 ). The lower block gives counts across the five response options, from 1 (never, or not at all confident) to 5.
Construct
Measure
Unit
Source
RQ
Self-report, after each task
Cognitive effort (demand as experienced)
effort on the task, effort on the approach (5)
per task
learner, report
1
Perceived task load
this task itself was complex (5, agreement)
per task
learner, report
1
Germane load
I really had to make sense of the task (5, agreement)
per task
learner, report
1
Help fit
direct help received, help wanted (5)
per task
learner, report
2
Ownership
tutor authorship, who did the work (4); could do it alone (5); understands the solution (5)
per task
learner, report
2
Table 3. Measures. Scale points in parentheses. Self-report items are answered once per task unless noted, so each participant supplies three readings, one per tutor. Source says who produced the record: the tutor, the learner, or the learner’s self-report. The RQ column names the question each measure serves; – marks the process measure that carries the manipulation check rather than a question.
Figure 6. Design and procedure. (a) The six tutor orders, one per sequence, with the realised allocation n . (b) One session in the order met, with questionnaire item counts, and the three gated phases of a task. The strip is a sequence, not a time axis; no part of the session was timed. Two panels. (a) A six-row table. Each row is one of the six orders in which the three tutors can be met, shown as tinted cells lettered A, B or C under the headings Task 1, Task 2 and Task 3, with the number of participants assigned to that order at the right, summing to 131. (b) A strip of eight blocks in order: consent, intake, the three tasks, comparison, reflection and debrief, each block carrying its questionnaire item count. A wedge widens from the Task 1 block into an expansion below, showing the three phases of one task — Planning, Monitoring and Evaluating — each box carrying at its foot the gate condition that ends that phase: plan submitted for review, one clean run, self-evaluation then checks. The last arrow leads to the after-task questionnaire.
Code
What the learner supplied
Example
Take-up evidenced
Demonstration
The substance of a decision, correct or not
Base fare first, 0.60 for children and seniors, 1.40 for adults; then the peak surcharge, adults only.
Artifact
A pasted plan, program or run result, with no articulation
A claim to be done or to understand, with no task content
All three test cases have run and the output matches.
Request or resistance
Asks the tutor to decide, or pushes back; reasoned argument against the tutor codes as demonstration
Can I start writing the code now? What else needs changing in my plan?
Table 4. Warrant codes for fading episodes, ordered from highest to lowest warrant, each with one learner turn from the corpus. Each episode receives exactly one code, the highest that applies.
Tutor C
Tutor A
Tutor B
C – A ( SE )
C – B ( SE )
RQ1 · Metacognitive demand and cognitive load
Effort
3.44
2.98
3.34
+0.46 *** (0.09)
+0.11 (0.09)
Effort on approach
3.28
2.95
3.27
+0.33 *** (0.09)
+0.03 (0.09)
Planned first
3.49
3.25
3.48
+0.24 (0.09)
+0.01 (0.09)
Perceived task load
3.36
3.30
3.29
+0.07 (0.08)
+0.08 (0.08)
Germane load
3.85
3.74
3.78
+0.11 (0.08)
+0.07 (0.08)
Table 5. After-task self-report ( N=131 participants, 393 sessions). Means by tutor and mixed-effects contrasts against Tutor C (positive = Tutor C higher), with Holm-corrected p within each family. All items 1–5 except tutor authorship (1–4, higher = more of the work done by the tutor). Bold contrasts survive correction; the asterisks carry the same information.
Tutor C
Tutor A
Tutor B
C vs A
C vs B
Delegation
Asked the tutor to build
50.4%
51.1%
23.7%
OR=0.95[0.64,1.42] , p=.82
OR=3.29[1.98,5.48] , p<.001
Learner turns
16.8
5.0
14.0
RR=3.30[2.72,3.99] , p<.001
RR=1.16[0.94,1.44] , p=.17
Delivery
Tutor-written artifact delivered
48.1%
23.7%
0 9.2%
OR=2.99[1.80,4.98] , p<.001
OR=9.71[5.29,17.85] , p<.001
Lines of code the tutor wrote
25.3
15.4
0 4.5
RR=1.64[1.26,2.13] , p<.001
RR=5.57[3.93,7.90] , p<.001
Table 6. Behaviour from the event log, per session ( N=131 , 393 sessions). Rates are the share of sessions in which the event occurred; turns, lines, programs and runs are means. Contrasts are population-averaged GEE estimates clustered on participant, with task and position as covariates: odds ratios ( OR ) for the rates, rate ratios ( RR ) for the counts, each stated as Tutor C against the named tutor.
Figure 7. (a) Share of decisions still open at fading that the tutor later conceded, by what the learner had supplied; 95% bootstrap intervals resampled on participant, rows grouped by aim. (b) Take-up rate by rung; the first three bars are the tutor’s asks, the last the spent ladder, where the point has already been conceded. (a) A dot-and-interval chart of concession rate by warrant code, in two groups. Aimed at the decision under support: the learner explained it 30.3 percent (95 percent interval 25.3 to 35.1, 669 open decisions), pasted a plan or program 25.9 (18.0 to 33.4, 332), said they were fine 20.4 (12.5 to 28.6, 49), asked the tutor to build 33.7 (22.8 to 44.8, 86). Aimed somewhere else: wrote about another decision 65.0 (47.1 to 80.0, 20), wrote about the interface 54.9 (23.1 to 89.2, 51). The first four intervals overlap one another; the interval for another decision lies above them, while the interface interval is too wide to separate. (b) A bar chart of take-up rate by rung, with a dashed line after the third bar: the tutor's three asks at 37.0 percent of 718 rounds, 27.5 percent of 338 and 21.8 percent of 188, then rounds on a spent ladder, where the tutor concedes and builds, at 14.7 percent of 273.
Asked the tutor to build
Full answer surrendered
Distress detected
Tutor
%
p
%
p
%
p
Tutor A
51.1
1.00
59.5
<.001
0 0.8
.006
Tutor B
23.7
<.001
16.0
.007
16.0
.021
Tutor C
50.4
–
0 6.1
–
0 8.4
–
Table 7. What it took to get the full answer ( N=131 participants, 393 sessions). Each cell is the share of sessions in which the event occurred at any point; full answer surrendered is an end state, the whole answer given away, not the delivery rate of Table 6 , which counts a session as soon as the tutor places any artifact, whole or partial. A build request is the same act under every tutor, but Tutor A builds what is asked and no more, so its cell counts sessions in which it produced the complete program, in chat or in the workspace; Tutor B and Tutor C surrender only through the welfare floor. p : McNemar exact, paired within participant, against Tutor C.
Appendix figures & tables2 assets
Supplementary material from the paper’s appendix.
Appendix
#
Identifier
Prompt
Scale
1
task_authorship
Who did the work on the task you just finished?
4-point: I did it myself, without the AI / I did it, with the AI helping / I told the AI what to do and it did it / The AI did it
2
task_alone
Could you write this again on your own, without the tutor?
5-point: Definitely not / Probably not / Maybe / Probably yes / Definitely yes
3
task_understand
How well do you understand the solution you just submitted?
5-point: Not at all / A little / Parts of it / Most of it / Completely
4
task_planned
How much did you work out your approach before writing code?
5-point: Not at all / A little / Some / Quite a lot / A great deal
5
task_effort
How hard did you have to think during this task?
5-point: Hardly at all / A little / A moderate amount / Hard / Very hard
6
task_effort_approach
How hard did you have to think about HOW to solve it — the approach, not the typing?
5-point: Hardly at all / A little / A moderate amount / Hard / Very hard
Appendix
Table 8. The after-task questionnaire, in the order asked.
Identifier
Prompt
session_think
With which tutor did you do the most thinking yourself?
session_plan
With which tutor did you think most about HOW to solve it before you started coding?
session_monitor
With which tutor did you check your own work most carefully as you went?
session_effort
With which tutor did you have to think hardest?
session_own_work
With which tutor did the solution feel most like your own work?
session_learning
Across the three tasks, which tutor helped you LEARN the most?
Appendix
Table 9. The comparative items, in the order asked.
Students increasingly use LLMs as tutors for coursework and problem solving. Little is known about the level of assistance LLMs provide when students use them as tutors in authentic learning interactions. This matters because tutoring responses can differ substantially in how directly they help students complete a task. We operationalize this dimension as scaffolding level and develop a five-level scale, validated against human annotations, that characterizes responses according to the degree of direct assistance they provide. We apply the scale to 14,637 LLM responses from 203 students in a university AI course. Responses are overwhelmingly concentrated at high levels of assistance, with more than 95% classified as either Explaining or Solving. Scaffolding level is systematically associated with students' subsequent conversational behavior, but provides little additional predictive information about performance on three subsequent exams beyond prior achievement and dialogue behavior. These findings provide an empirical baseline for LLM assistance in tutoring interactions and a measurement framework for evaluating how alternative tutoring designs change that assistance.
A central pedagogical value evaluated in AI tutor benchmarks is scaffolding: guiding students through graduated steps toward a solution. Alignment and evaluation methods for embedding scaffolding behaviour into chatbots, however, rest on an implicit assumption: that students will take up the scaffolding and engage in the conversation. To examine whether this assumption holds, we introduce an evaluation pipeline around two metrics - Chatbot Scaffolding and Student Uptake - and apply them across nine datasets of 9,490 chats, spanning AI tutor benchmarks and real-world deployments of educational chatbots. Our analysis reveals that while benchmarks assume a high-scaffolding, high-student-uptake environment, students in real-world settings exhibit lower levels of uptake overall - frequently bypassing the chatbot's pedagogical framing to drive the interaction toward their own learning goals at little interpersonal cost. We argue that bypassing scaffolding is not necessarily detrimental; rather, it frequently highlights a mismatch between a chatbot's pedagogical framing and the student's learning goals. To meaningfully evaluate the effectiveness of a chatbot's assistance, future benchmarks must move beyond the assumption that students will simply take up the scaffolding, and instead evaluate how these chatbots navigate diverse learning contexts and student-driven interaction patterns.
Alexandra Neagu, Jeffrey T. H. Wong, Marcus Messer +2
Department of Mechanical Engineering, Imperial College London, UK · Department of Electrical Engineering, Imperial College London, UK · Department of Earth Science and Engineering, Imperial College London, UK
The democratization of Large Language Models has given rise to vibe coding, where novice programmers prioritize semantic intent over syntactic implementation. Without pedagogical guardrails, we argue this is fundamentally misaligned with cognitive skill acquisition. Drawing on Kirschner's distinction between cognitive offloading and outsourcing, unrestricted AI encourages novices to outsource the intrinsic cognitive load required for schema formation rather than merely offloading extraneous load. This accumulation of epistemic debt creates fragile experts: developers whose high functional utility masks critically low corrective competence. To quantify and mitigate this debt, we conducted a between-subjects experiment (N=78) using a custom Cursor IDE plugin backed by Claude 3.5 Sonnet. Participants were recruited via Prolific and UserInterviews.com to represent AI-native learners. We compared three conditions: manual (control), unrestricted AI (outsourcing), and scaffolded AI (offloading). The scaffolded condition employed a novel Explanation Gate -- a real-time LLM-as-a-Judge framework enforcing a teach-back protocol before generated code could be integrated. Results reveal a collapse of competence: both AI groups significantly outperformed the manual control on functional utility (p < .001) and did not differ from each other (p = .64), yet unrestricted AI users suffered a 77% failure rate on a subsequent 30-minute AI-blackout maintenance task, vs. only 39% in the scaffolded group. Qualitative analysis suggests successful vibe coders naturally self-scaffold, treating AI as a consultant rather than a contractor. We discuss implications for AI-generated software maintainability and propose that future learning systems must enforce metacognitive friction to prevent mass production of unmaintainable code. Replication package: https://github.com/sreecharansankaranarayanan/vibecheck
Sreecharan Sankaranarayanan
Extuitive Inc. (Flagship Pioneering) Cambridge, Massachusetts, United States of America