What a learner's detour taught me about learning

Recently, a learner on Pravaha spent five attempts trying to get past the AI coach without answering its questions himself.

He opened the browser’s developer console and started experimenting. First, he tried setting the answer field directly using JavaScript. When that didn’t work, he tried custom JavaScript to simulate someone typing. That didn’t work either. So he kept trying variations.

When I noticed the pattern, my first thought was: if he had put this much effort into the learning unit, he might have finished it already.

But the conversation we had afterwards was more interesting than that.

The coach asks for thinking, not recall

After a learner goes through the material in a Pravaha learning unit, the AI coach steps in with questions. These are meant to make the learner think through what they have just learned.

The coach might present a scenario, ask how they would approach a use case, or change a constraint and ask whether their original answer still holds. The point is to get them to connect ideas and explain their reasoning.

I care much more about that than whether someone can recall a definition. For an engineer building with AI, looking something up or getting an explanation is easy. They still need a mental model that helps them judge whether an answer makes sense, recognise what might go wrong, and decide what to do next.

That is what these conversations are trying to build and assess.

Of course, a learner can try copying the coach’s question into another AI tool and pasting its answer back. Pravaha has checks around that behaviour. I’ll leave the mechanics out of this post, because they aren’t the interesting part of the story.

In this case, those checks became a challenge the learner wanted to solve.

The detour took more effort than the unit would have

Pravaha’s dashboard gives trainers a view of how learners are progressing, with enough detail to spot patterns that might need a conversation. That is where I noticed these repeated attempts.

As his trainer, I brought it up with him. We had a candid discussion about what he had tried and why.

I was impressed by how much he had figured out. He had investigated the interface, formed ideas about what the checks might be doing, and tried different approaches. There was technical curiosity there, along with persistence.

There was also an obvious problem. His stated goal was to become an AI FDE or AI engineer. The unit was intended to help him move towards that goal. Instead, he had spent a substantial amount of time trying to avoid doing the thinking it asked of him.

I pointed this out. His explanation was simple:

That stayed with me.

I had initially read his behaviour as laziness. But laziness doesn’t fully explain someone making five attempts, writing JavaScript, examining the results, and trying again. He was willing to work. He had found a problem he wanted to work on more.

A detour is a question, not an answer

There is a familiar developer instinct here. Give us a repetitive task and we may spend an afternoon automating something that would have taken twenty minutes to do manually. Sometimes that investment pays off. Sometimes the side problem is simply more enjoyable.

This learner had found his side problem.

I wouldn’t say he learned nothing from it. Trying to understand and work around a system teaches a person quite a bit. But it had taken him away from the concepts he had set out to learn, and it was worth asking why.

Was the unit too easy? Did its relevance to his goal feel unclear? Was he avoiding a concept he found difficult? Or was he discovering that investigating how a system works interested him more than the learning path he had chosen?

His behaviour raised those questions. It didn’t answer them.

That distinction matters. One incident doesn’t establish that someone has chosen the wrong career goal or should abandon a course. Learning also involves working through things that aren’t immediately exciting. But when someone repeatedly finds energy for the detour and very little for the intended work, there is something worth exploring.

A completion percentage won’t say what that something is.

The dashboard shows the detour. A person asks why.

The platform did something useful: it identified a pattern and made it visible to me. That gave us a starting point for a conversation we might otherwise never have had.

A trainer can use that moment to understand what is going on. Perhaps the learner needs help connecting the material to the work they want to do. Perhaps they need a different challenge. Perhaps they need someone to point out, quite directly, that their current choices aren’t helping them reach their stated goal.

And sometimes the goal itself needs another look.

This is why I think a human in the loop remains important in training. There are moments when guiding a learner means looking beyond their latest answer and asking about their choices, interests, and reasons for being there.

What the detour was really about

It would be easy to tell this as a success story about Pravaha’s checks. A learner tried to get around them, and they held up.

But the more useful outcome was hearing him say that hacking around the platform was more interesting than completing the course. That was something we could work with. It gave us a reason to examine the relationship between what he said he wanted to become, what he was willing to practise, and what actually held his attention.

A learning platform should help people make progress towards their goals. Sometimes that means asking a probing question about the material. Sometimes it means giving a trainer enough context to ask a different question altogether: what are you really trying to learn here?