---
title: "Productive struggle in learning — Erkan Malcok"
description: "When does difficulty help learning? Explore productive struggle, the risks of instant AI help, and ways to preserve the thinking learners need to do."
date: "2026-09-01"
updated: "2026-09-07"
canonical: "https://erkanmalcok.com/articles/productive-struggle-in-learning/"
kind: "Opinion"
series: "education-and-ai"
tags:
  - "Pedagogy"
  - "AI in education"
---

# Productive struggle in learning — Erkan Malcok

Why some difficulty earns learning — and some shortcuts remove it.

A learner is stuck on a problem. A teacher, parent, or tool intervenes quickly,
explains the next step, and the task moves forward. Everyone feels relief.

That relief can be expensive.

Some difficulty is not a sign that teaching has failed. It is often the condition
under which understanding becomes retrievable later. The educational literature
calls this **productive struggle**: effortful work on a problem that remains
within reach, where the learner is challenged but not abandoned.

The risk with instant answers — human or machine — is not help itself. It is
help that arrives before the learner has done the kind of thinking the task was
meant to produce.

## What you will take away

By the end of this article, you should be able to:

- distinguish productive effort from avoidable friction;
- choose hints that preserve the learner’s agency; and
- give AI a support role without outsourcing the learning objective.

## The idea

Learning is not only exposure to correct information. It also depends on:

- **Recall** — retrieving what was learned before, under mild pressure.
- **Repair** — noticing that an approach fails and adjusting it.
- **Discrimination** — learning when one method applies and another does not.
- **Effortful construction** — building an explanation or solution step by step,
  not receiving one ready-made.

Productive struggle is the interval in which those processes still have room to
run. Work on productive failure shows that initial problem-solving can prepare
learners for later instruction when the task and support are designed carefully
([Kapur](https://doi.org/10.1080/07370000802212669)). The learner may be slow,
uncertain, or visibly frustrated. That discomfort is not proof that the task
should be simplified immediately. It may be evidence that useful thinking is
still happening.

This is easy to confuse with a belief that suffering is good for its own sake.
It is not. Unproductive struggle — repeated failure with no path forward, no
feedback, and no sense of progress — wastes time and erodes confidence. The
distinction matters.

## Productive and unproductive struggle

A rough practical test:

| Signal | Productive struggle | Unproductive struggle |
| --- | --- | --- |
| Progress | Small advances, partial models, better questions | No change after sustained effort |
| Error | Mistakes that reveal a specific misconception | Random guessing or disengagement |
| Support | Hints that preserve thinking (“What have you tried?”) | Hints that replace thinking (“Here is the answer”) |
| Affect | Frustration with continued engagement | Shutdown, avoidance, or learned helplessness |
| Aftermath | Better recall or transfer on a related task | No improvement when the prompt changes slightly |

The goal is not maximum difficulty. It is **appropriate difficulty**: hard
enough to require thought, supported enough that the learner does not conclude
the subject is impossible or not for them.

In computing education, appropriate difficulty might mean debugging a program
that almost works, explaining an algorithm in plain language, or predicting the
output of code before running it. In each case, the struggle is tied to a
specific capability the teacher values.

## What instant help removes

When help arrives too early, learners can still finish the task. What they may
not build is the underlying competence.

Common losses:

1. **Retrieval practice.** The answer appears before memory is tested, despite
   evidence that retrieval can strengthen later retention
   ([Roediger and Karpicke](https://doi.org/10.1111/j.1467-9280.2006.01693.x)).
2. **Error signals.** A wrong approach is corrected before the learner notices
   why it fails.
3. **Ownership.** The final product reflects the tool’s reasoning, not the
   learner’s.
4. **Confidence calibration.** Smooth completion suggests mastery that may not
   survive a small change in the question.

This connects directly to a separate problem:
[fluent answers are not understanding](/articles/fluent-answers-are-not-understanding/).
A polished response can hide absent reasoning. Removing
struggle often increases fluency while decreasing learning.

That does not mean teachers should withhold support until learners are exhausted.
It means support should be **timed and shaped** so that thinking remains the
learner’s work.

## A classroom example

Suppose Year 10 pupils are asked to write a function that returns the largest
value in a list.

A pupil submits this:

```python
def largest(numbers):
    biggest = 0
    for n in numbers:
        if n > biggest:
            biggest = n
    return biggest
```

It works for many test cases. It fails for lists of negative numbers.

**Unproductive intervention:** replace the function with a correct version and
move on. The lesson ends; the misconception about initialisation remains.

**Productive intervention:** ask targeted questions.

- What happens if the list is `[-3, -1, -2]`?
- Should `biggest` always start at `0`?
- What value should `biggest` take before the loop begins?

The pupil might arrive at:

```python
def largest(numbers):
    if not numbers:
        raise ValueError("numbers must not be empty")
    biggest = numbers[0]
    for n in numbers[1:]:
        if n > biggest:
            biggest = n
    return biggest
```

An empty list has no largest value, so this version rejects it explicitly with
`ValueError` before accessing the first item.

The struggle was not the syntax. It was the assumption that “largest so far” can
start at zero. That assumption is worth surfacing because it will reappear in
other contexts.

An AI assistant can play either role. It can ask Socratic questions, generate
counterexamples, or propose test cases. It can also hand over a corrected
function in one sentence. The instructional design — and the norms around tool
use — determine which behaviour dominates.

## Designing for struggle

Teachers and task designers can make productive struggle more likely without
turning lessons into endurance tests.

**Start from the capability, not the format.** Ask what the learner should be
able to do after the task, then design difficulty around that capability.

**Make process visible.** Require intermediate artefacts: a plan, test cases, a
short written justification, a prediction before execution. These are harder to
outsource without detection and easier to discuss.

**Use hints that preserve agency.** Prefer:

- “What is the smallest case?”
- “Run your code on an empty input.”
- “Explain step three in your own words.”

over:

- “Here is the completed solution.”

**Change the surface, not only the number.** If every problem is the same shape
with different integers, learners learn the template, not the idea. Mild novelty
exposes template dependence quickly.

**Separate draft from polish.** A rough correct argument is more valuable than a
fluent finished essay the learner did not construct. Polish can come later; the
initial reasoning cannot always be reconstructed afterwards.

**Build norms early.** If the classroom culture rewards speed and perfect
presentation, learners will rationally choose tools that optimise those signals.
If it rewards explanation, testing, and revision, struggle becomes socially
acceptable.

## Using AI without removing it

AI does not have to eliminate productive struggle. It can support it when the
role is explicit:

| Role | Example prompt or use |
| --- | --- |
| Questioner | “Ask me three questions about my draft without giving the answer.” |
| Counterexample generator | “Give me inputs that might break my function.” |
| Explainer on demand | “I got this error. Explain what it means, not how to fix it yet.” |
| Practice partner | “Give me a similar problem with different constraints.” |

What tends to undermine struggle is the default posture of many tools: complete
the task, smooth the prose, remove uncertainty. That posture is closely related
to why [LLM fluency is not reasoning](/articles/llm-fluency-is-not-reasoning/).

For educators, the practical question is not “AI or no AI?” It is: **which parts
of this task must remain the learner’s thinking for the learning objective to be
met?** Everything else is negotiable.

For learners, a useful habit is to pause before asking for a full solution and
ask instead: *What am I trying to figure out? What have I already tried? What
would count as evidence that I understand this?*

## What to try next

Productive struggle is not romanticised difficulty. It is a design choice about
where effort should sit.

If you teach, tutor, or write tasks in technical subjects, consider:

- Which steps in your current assignments could be completed fluently without
  understanding?
- Where would a five-minute struggle teach more than a five-second answer?
- What support preserves thinking rather than replacing it?

Preserve struggle where it earns learning. Remove friction where it does not.
The art is telling the difference — and that judgement is itself part of serious
teaching.

## Related reading

- [Fluent answers are not understanding](/articles/fluent-answers-are-not-understanding/)
  explains why polished completion is weak evidence of learning.
- [LLM fluency is not reasoning](/articles/llm-fluency-is-not-reasoning/) offers
  checks for AI-generated explanations and solutions.

## References

- [Kapur, "Productive Failure" \(Cognition and Instruction\)](https://doi.org/10.1080/07370000802212669)
- [Roediger and Karpicke, "Test-Enhanced Learning" \(Psychological Science\)](https://doi.org/10.1111/j.1467-9280.2006.01693.x)