The project is the whole point of a bootcamp. Nobody hires a graduate for their quiz scores. They hire them because they shipped a working app, debugged it, and can explain the choices they made. Which is exactly why grading those projects is so brutal.
A single capstone might be a repo with forty files, a README, a short demo video, and a written reflection. Marking that properly takes 30 to 60 minutes. Multiply by a cohort of 25, then again by every project across a 12-week course, and you have an instructor who is marking on weekends and resenting it by week six.
Why project grading breaks people
It is not just volume. Three things compound it.
- Context switching. Every submission is different. Different stack choices, different file structures, different ways of solving the same brief. The instructor reloads context from scratch each time, and that is mentally expensive in a way that marking 25 identical quizzes is not.
- Drift. The first submission gets a careful, generous read. The twenty-fifth gets a tired skim at 11pm. Same rubric, very different rigour. Students notice, and it is genuinely unfair.
- Feedback debt. Good feedback is where the learning happens, but it is the first thing to get cut when time runs short. So students get a grade and one line, and the most valuable part of the assessment evaporates.
The instinct to automate, and where it goes wrong
The obvious move is to throw a test suite at it. Automated tests are great for the parts of a project that are objectively right or wrong - does it compile, do the endpoints return the right shape, does it pass the unit tests. Keep those. They are fast and reliable.
But the things that actually separate a strong graduate from a weak one are not test-suite-shaped. Code readability. Whether the architecture makes sense. Whether the README explains the thinking. Whether the demo video shows real understanding or memorised lines. You cannot grep for judgement, and an autograder that pretends you can will pass clever-but-shallow work and fail thoughtful work that took an unusual path.
Split the work by what it actually needs
The model that holds up is a two-layer split.
Layer one - deterministic. Tests, linters, build checks. Automated, instant, no human needed. This clears the binary stuff off the instructor’s plate entirely.
Layer two - judgement. Code quality, design decisions, the written reflection, the demo. This is where an AI assessment layer earns its keep, not by replacing the instructor but by doing the first read for them.
The tool reads the repo, the README, and the video against the rubric the bootcamp already uses, drafts a score for each criterion, and points to the specific evidence - this function, that paragraph, this moment in the demo. The instructor then reviews a structured first pass instead of starting from a cold repo. This is the exact problem Scorafy is built for, and the instructor still signs off every result.
Why the instructor must stay in the loop
Two reasons, one practical and one principled.
Practically, your instructors know things the rubric does not capture. They know this student struggled all term and just had a breakthrough. They know the brief was ambiguous and several reasonable readings exist. That context changes a grade, and it should.
On principle, a grade that affects whether someone gets a certificate or a job reference is a decision with real weight. It should not be made by software alone - both good practice and emerging rules like the EU AI Act treat education decisions as high-stakes. The assessor reviews, adjusts, and owns the outcome. The AI just gets them to a starting point in two minutes instead of forty.
What consistent grading does for the cohort
When the first pass is structured and evidence-linked, submission one and submission twenty-five get the same rigour. The 11pm skim stops happening because the instructor is reviewing a draft, not building one from nothing. Students get feedback that points at specific lines and specific decisions, which is the feedback that actually changes how they code.
And the instructor gets their evenings back. That is not a soft benefit. Burnt-out instructors give worse feedback, leave mid-cohort, and take institutional knowledge with them. Protecting their time is protecting the quality of the programme.
A practical starting point
Pick one project type - say the mid-course API build. Keep your existing rubric exactly as it is. Run a handful of past submissions you already graded by hand through an assistive first pass, and compare. If the draft scores line up with your instructor’s and the cited evidence is sound, expand it. If they do not, your rubric probably needs sharpening anyway, and you have found that out cheaply.
The goal is not to take instructors out of grading. It is to stop grading from taking your instructors out.