PeerCheck
June 2026
The problem
One of our Holberton projects had a Task 5 where students were supposed to validate their own work. But this particular project felt different. We genuinely wanted to know if we'd done it right, not just tick a box. My classmates and I talked about it and agreed: a real structured review would have been far more useful than self-assessment. My SWE heard me say that and turned to me specifically: he knew I already had more background with AI tools than the rest of the cohort. "Adam, you should do the manual review yourself." That comment became the idea.
My approach
I built a Node.js API that reads a GitHub repo through the REST API, filters the relevant files, and streams a structured three-section review using Claude Haiku. Before generating anything, a two-tier validation step checks whether the repo actually matches the AI-IDE task: first a zero-token keyword scan on the README, then a Haiku preflight call that rejects repos unrelated to the task. This way, invalid repos are blocked before consuming any generation tokens. The review streams word by word via SSE, so students see the output appear progressively rather than waiting for a full response.
The POC
A Node.js + Express API deployed on VPS behind Nginx. SSE streaming so the review appears word by word as it generates. Two-tier validation: zero-token keyword check on the README, then a Haiku preflight call to confirm the repo matches the AI-IDE task. Max 900 tokens for the review, max 10 files read, 3000 characters per file. The review is structured in three fixed sections: what works, what to improve, what is not yet mastered. Optional email delivery via Resend. An AbortController stops the Claude stream immediately if the student closes the browser. A full review runs in under 10 seconds.
What I took away
Constraining the scope is what makes the output trustworthy. The real work was defining exactly what PeerCheck should evaluate and nothing beyond that. That precision is what made the AI feedback actually usable. I went in knowing nothing about SSE or the Claude API. I came out convinced that a tool which does one thing well produces results you can stand behind.
What I'd do in prod
I'd add a dashboard for the teacher to see who submitted and when. I'd avoid re-running the AI on the same repo twice if nothing changed. If multiple students submit at the same time, I'd add a queue so requests don't pile up and hit the API limit. The real end goal is to make PeerCheck work for any GitHub repo, not just this one Holberton project.