Skip to content
LARECloud Solutions

Product · 7 min

Building an AI mentor that refuses to do the work

An assistant that completes the assignment destroys the only signal the platform exists to produce. Designing against that is harder than it sounds.

Published
10 Jun 2026
Author
LARE Editorial
Reading time
7 min

The obvious version of an AI mentor is a chat box wired to a general model. Students love it immediately and it quietly ruins the platform, because every submission afterwards measures the model rather than the student.

This is not a hypothetical concern. It is the default outcome, and it arrives within about a fortnight of launch.

So the mentor is constrained in three ways. It is grounded in the student's own track material and submission history rather than the open web, so its answers stay inside the course. It refuses to produce submittable output — it will explain a concept, walk through a similar problem, or point at the module, but it will not write the function. And every interaction is logged and visible to faculty.

The refusal behaviour is the difficult part. Students are inventive, and a request can be reframed until it no longer looks like a request for the answer. We handle this less through prompt instructions than through what the mentor can see: it is not given the assignment's expected solution, so it is poorly positioned to produce one even when persuaded to try.

The visible logging matters more than we expected. Not as surveillance — students are told about it — but because knowing a reviewer can see the conversation changes what students ask for, and it turns out they mostly ask better questions.

The result is a mentor students rate lower on immediate helpfulness than an unconstrained model would score. We consider that the correct trade.

LARE Editorial · 10 Jun 2026

Let's build the bridge.

Whether you run a campus, a department, or a hiring pipeline, the first conversation is free and specific to your situation.

Talk to our team