Help that makes students think, not copy.
The mentor is built into Sudo Code. It reads the open file and the last terminal output, and it answers the way a good teaching assistant does — with the question that gets the student unstuck, not with the finished solution.
A general-purpose assistant will write the function. That is what it is for, and it is why a student can finish a lab having learned nothing except how to phrase a request. The mentor in Sudo Code is configured for the opposite outcome: it explains the shape of the problem, points out the assumption that is wrong, and leaves the implementation to the person being assessed on it.
Six decisions that make it a mentor rather than an autocomplete.
It answers with a question
Ask how to connect to Postgres and the mentor asks which driver the project already depends on, and what the connection string needs to contain. The student reaches the answer; the mentor makes sure they can get there.
Intentional friction
It will not paste a finished implementation into the editor. It explains an approach, points at the failing assumption, and stops short of the code — the part the student is there to write.
A daily budget, not a paywall
Each student gets 60 mentor credits a day: a fast answer (Claude Haiku, Gemini Flash) costs one, a strong one (Claude Sonnet, Gemini Pro, GPT-5) three, Claude Opus ten. Inline completions have their own daily allowance. Enough for a full lab session, finite enough that students read the error before they ask.
It knows the context
The mentor sits inside the IDE with the open file, the project tree and the last terminal output. It does not need a student to paste their code, and it does not answer as if the project did not exist.
Every prompt is a signal
The prompt and whatever code entered the editor after it become part of the record: how much of the work was AI-generated, how specific the question was, and whether reliance is falling over the semester.
Trends, not transcripts
Professors see dependency and depth moving over weeks. They do not get a reading feed of student conversations. The mentor is a tutor, not a surveillance channel.
Sixty credits a day.
Every student gets sixty mentor credits a day, resetting at midnight, plus a separate allowance for inline completions. A quick answer costs one credit, a strong one three, the largest model ten. The models are the same ones professionals use: Claude, Gemini and GPT, chosen per question from the status bar. The limit is real and deliberate: when help is finite, the first move changes — read the traceback, form a hypothesis, try it, and only then ask, with the specifics that make the answer useful. The institution can switch the mentor between teaching, assist and copilot modes.
Students learn to spend the budget on the questions they cannot resolve alone. That is the same instinct that separates an engineer who can be handed an unfamiliar codebase from one who cannot.
What a session looks like
- student
"My insert fails with a foreign key error."
- mentor
"Which table is the constraint pointing at, and does the row it needs exist yet? Look at the order your two inserts run in."
- student
Reorders the inserts. The run exits clean.
AI use becomes something you can measure.
The question institutions keep asking is not "are students using AI" — they are. It is "how", and whether that changes as they get better. These are the metrics that answer it.
The share of a student's committed code that arrived from a mentor exchange rather than being typed.
How specific and well-framed the questions are — naming the error, the constraint and what was already tried, versus asking for the answer.
How many prompts a student sends per program run. A high ratio means asking before trying.
Whether dependence falls as a student gains ground. A first-year leaning on the mentor is expected; a final-year still leaning the same way is the thing worth noticing.
You see the trend. Not the transcript.
A professor's view of mentor activity is a set of numbers moving over time: AI-generated share, prompt depth, prompts per run, and whether reliance is decaying across the semester. That is enough to spot the student who has stopped writing their own code, and enough to start a conversation about it in week four rather than at the viva.
It is deliberately not a reading feed. Prompts are processed to compute the metrics above; they are not published to staff as a conversation log.
Using AI well is part of the record.
Nobody is penalised for asking. What the record shows is the quality of the asking — whether a student can frame a precise technical question, and whether they need fewer of them as the years go on. Both are things employers care about and neither is visible on a transcript.
Telemetry sharing and leaderboard visibility stay under the student's control in settings.
See how your students actually use AI.
Run a pilot with one cohort. Within a semester you will know which students are building their own reasoning and which are outsourcing it.