A degree says a student passed. It does not say how they work.
Sudo Learn exists to close that gap for engineering institutions: to replace a claim on a resume with a record of how a student actually builds software, gathered while they do the work rather than asked for afterwards.
The resume is broken for engineering students
An engineering resume is a list of assertions. Five languages, four frameworks, three projects, a percentage. None of it is evidence. The student cannot prove any of it, the professor who signed the project cannot either, and a recruiter with two hundred applications treats the whole thing as noise and falls back on the name of the college.
So students optimise for the list. Another certificate, another cloned tutorial project, another line. Meanwhile the things that actually decide whether someone is useful in their first six months on the job — how they read an error, how long they stay stuck, whether they can work without being told what to do next — appear nowhere at all. They are the hardest things to fake and the only things nobody is recording.
Grading the final file is not enough
A lab submission is one file at one moment. It cannot tell you whether the student wrote it in an afternoon or in eleven minutes at 3 a.m. after pasting it out of a chat window. Two students hand in the same working program: one fought through nine failing runs and found the bug, the other never saw an error because they never wrote the code. Graded on the artefact, they score the same.
This got worse, quickly. Generative tools are now good enough that the final file has almost stopped carrying information about the person who submitted it. The answer is not to ban the tools — students will use them at work — it is to stop treating the artefact as the evidence and start looking at the process that produced it.
What we measure instead
Every number in Sudo Learn comes from something the student did in the editor. If we cannot name the signal it was computed from, we do not show the number.
How many failing runs a student takes for each successful one — and whether that ratio falls across a semester.
How long the student stays stuck once something breaks. Recovery is a skill; it shows up here before it shows up in marks.
Editing in circles: the same lines rewritten again and again without the program getting any closer to working.
Minutes of unbroken work, as opposed to hours with the editor open.
How much of what ended up in the file came from the mentor rather than from the student.
One composite a department can sort by, with every input that produced it visible underneath.
Those metrics settle a student at L1, L2 or L3 and mark them On Track, At Risk or Flagged. A student who has not started yet is shown as empty, never as a zero, and the professor can always open the signals behind a flag before acting on it.
Three layers
The product is small on purpose. There are three pieces and each one earns its place.
The IDE
Sudo Code, a desktop editor built on VSCodium. Students get a real environment — a terminal, git, extensions, their own files — and it records how the work happened while they use it.
The mentor
A Socratic AI that sits in the editor and answers a stuck student with a question, a hint or a place to look. It will not hand over the finished function, and both the prompt and the reply stay in the record.
The record
The metrics computed from that work, kept per student across their courses and their years: how they debug, how long they stay stuck, how much of their code is their own, and whether any of it improves.
The layers only work together. Telemetry without a mentor is surveillance with no help attached. A mentor without telemetry is another chat window. Both without a record change nothing at the level of a department.
Built in Pune, for Indian engineering departments
We build in Pune and we work with Indian engineering colleges: large classes, lab hours that have to be accounted for, accreditation paperwork that asks what a course outcome actually achieved, and a placement season where a department is judged on students it can say very little concrete about.
That shapes what we build. Sudo Code runs on the machines students already have, in a college lab or at home, on Windows, macOS or Linux. Accounts are created by invitation, department by department, so nothing depends on an IT project. And every metric maps back to a course and its outcomes, because that is the unit a department is actually held to.
Start with one department
Six to eight weeks, a group of students you choose, no cost for the pilot period. At the end we go through what was recorded, together.