Framework
Scaffold or Surrender?
A practical conversation about any moment where AI is helping a learner, adult or child: is the tool scaffolding their thinking — supporting a decision they still make — or has it surrendered the thinking on their behalf?
Definition
Scaffolding means help that supports a learner toward a decision or skill they are still developing — a hint, a question, a worked example — and is meant to be removed as they grow. Surrender means help that takes over the decision entirely, so the learner gets an output without doing the thinking that would have made them more capable.
This framework turns my core principle — AI should scaffold thinking, not surrender it — into something you can actually check.
The problem it addresses
A person who used AI to get unstuck and a person who copied an answer can hand in identical work. The finished artifact does not distinguish the two. Ask for evidence of decisions, reasoning, testing, and revision rather than inferring understanding from a polished result.
The framework
Walk through eight questions about one specific piece of work. Record who contributed: learner, AI, another person, or shared. Look for consequential decisions the learner can explain, not a count of tasks performed without help.
There is no passing score. The last question asks for a further check, not a tie-breaker that proves learning. Use what is missing to plan the next task or hint.
A usable session checklist
Choose a project and version. Note the goal, prior experience, and assistance used. For each question, record an example or mark it “unknown.” Tick the box only when you have recorded evidence — the box does not mean the learner passed.
Record whose need is being served and what the learner chose. Example: “I chose a schedule because neighbors need to know when I am free.”
Write a concrete rule or success condition in the learner's words. Example: “One confirmed booking per time slot.”
Name one choice, an alternative, and a reason. Example: a simple slot list instead of a calendar, because the first version only needs a few times.
Keep the first draft or version and name what the learner, AI, and other people each contributed. AI-generated code is not automatically a failure; unexamined code is a question to investigate.
Keep a test, its expected result, and its actual result. Example: two requests for one slot reveal a missing booking rule. Record any hint that helped reveal the flaw.
Ask for an explanation without copying the tool's answer. Example: why a disabled button is not enough when two browsers show the same available slot.
Record the chosen change and why it addresses the failure. Example: enforcing the booking rule in the shared store, not just changing the display.
Try a changed requirement or related task, then repeat later. Record tools, hints, and assistance. A smooth explanation immediately after a walkthrough is not proof of lasting learning.
Use question numbers to organize your notes. Record who contributed, what you saw, what remains unknown, and what to try next. Do not enter private or sensitive information. Notes and ticks stay in this page only; copy your notes elsewhere before leaving or refreshing. They are not submitted or saved.
Keep two kinds of evidence separate
Project correctness
Define the requirement, run a test that could disprove it, and inspect the output or saved records. Keep expected and actual results. A working project may still contain reasoning its creator cannot explain.
Creator understanding
Ask the creator to explain a choice, predict a failure, and handle a changed requirement without the original walkthrough. Record tools and hints, and try a related task later. An articulate explanation may still accompany a broken project. Neither check substitutes for the other.
Two illustrative examples
These are teaching scenarios, not observed learners, measured improvements, or research findings. They show what to ask for; they do not establish that anyone learned.
An adult builds a dog-walking schedule
Possible surrender: accept an AI-generated schedule, ask AI to fix double booking, and accept “fixed” without inspecting how bookings are saved. The goal may belong to the adult; the important test and reasoning are still unknown.
Possible scaffold: state “one confirmed booking per slot,” trace two requests, ask AI for implementation options, and choose a rule enforced at the shared store. Keep the failed case and re-run it.
Next evidence: inspect saved records for project correctness. Separately ask the adult why a “Taken” label is insufficient and how cancellation changes the rule. Try a related reservation task later before inferring transfer.
Read the full written lessonA child explains why ice floats
Possible surrender: paste the assignment into AI and copy the answer. The assignment's goal came from elsewhere; copying gives no evidence that the child can explain density.
Possible scaffold: keep the child's first explanation, ask a question about what “less dense” means, then let the child draw, explain, and revise. Record the adult's or AI's hint instead of calling the work independent.
Next evidence: check the revised explanation for scientific accuracy. Separately ask the child to reason about another floating or sinking example without copying. Do not claim improved understanding before observing that check.
Common misuse
- Treating it as anti-AI. A perfect score of “the learner did everything” with no tool at all isn't the goal. Good scaffolding is a win.
- Scoring it like a test. It's a diagnostic conversation, not a grade. The point is to notice patterns and adjust.
- Applying it only after the fact. Its best use is before and during the work, to shape how the tool gets used — not just to judge a finished product.
How to use it
For adult learners
Keep your first attempt, one important choice, a failed test, and a revision. Then try a small change without the original walkthrough. Name any help you need; the goal is useful capability, not pretending you worked alone.
For parents and educators
Use the questions as a conversation, not an interrogation or an AI detector. Invite drawings, demonstrations, and other accessible ways to explain. Observe a small changed task, record the support given, and keep the stakes low.
For product design
Audit which decisions your default flow takes over. Consider hints, options, and visible revision history that hand choices back to the user. These are design intentions behind SayMake (an experiment), not evidence of measured learning outcomes.
Limitations and unresolved questions
- Not a validated assessment. This is a working checklist, not a research-backed score, a certification, or a way to establish that AI caused learning gains.
- Explanation is incomplete evidence. A fluent answer can be rehearsed. A changed task and a later related task offer additional evidence, but do not establish broad or lasting capability on their own.
- Support is not cheating. Prior knowledge, language, disability, and context affect what a learner can show. Keep appropriate accommodations and safety support; do not equate independence with removing all tools.
- Ownership is not all-or-nothing. Shared decisions can be valuable. Sometimes the immediate goal is getting necessary work done rather than learning every part; state that goal honestly.
- Not a safety or correctness audit. High-stakes code, health, legal, or financial work needs relevant expert review and domain-specific checks beyond this guide.
Open questions include whether the prompts are usable across contexts, which checks reveal understanding rather than rehearsal, and whether any capability transfers to later work. Real attempts and independent critique should drive the next revision.