A student types "add a waitlist endpoint." The agent returns JWT, Redis, Postgres, and a welcome email. Looks senior. It is mostly fiction. This lab grades the guess log first. The diff comes second.
If that sounds harsh, good. Bootcamps keep shipping features that never had a chance to be true.
I wrote it because pull requests that solve an unassigned product are a grading nightmare.
The brief said POST /waitlist with an email. That is it. No auth story. No provider. No queue. The model filled every silence with a vendor. Students accepted the story because the code compiled.
Agents are autocomplete with confidence. Confidence is not evidence. This lab teaches one mechanical habit: no implementation until every material assumption is tagged.
We will use a tiny Node checker, a frozen requirements file, and a four-checkpoint rubric. You can run the whole thing on a laptop. The lab still works if you delete the optional infra paragraph below.
Students get one page. Instructors do not "clarify" in Slack. Ambiguity is the point.
Product brief (frozen): Add POST /waitlist JSON body: { "email": string } Response: 201 with { "ok": true } In-memory storage is acceptable No login, no billing, no email send Deliver in Node.js
Lab setup Fork a starter that contains server.js with a health check only, plus REQUIREMENTS.md (the brief above) and an empty ASSUMPTIONS.md. Pick any coding agent you already use. Paid, local, browser tab, whatever. Optional infra for a zero-invoice agent loop: point the agent at MonkeyCode. Disclosure: This article was prepared as part of MonkeyCode's product outreach. The only capabilities I am using here are free model access and a free server option. No model names, quotas, or hardware claims. If those matter for a syllabus, verify them on the product page before you publish dates. Install Node 20+. The grader needs no extra packages.
If the checker fails on an empty repo, that is correct. An empty assumption log is a failing lab, not a blank canvas.
Status is a closed enum: CONFIRMED — quoted from REQUIREMENTS.md or a written instructor answer REJECTED — considered and explicitly out of scope GUESSED — the agent (or the student) filled a silence
Budget rule: submitted code may depend on CONFIRMED rows only. GUESSED rows live in the table. They must not appear as branches, dependencies, or env vars. REJECTED rows are not a backlog. They are a fence.
Why a table instead of a vibe-y architecture note? Because I can grade a table. I cannot grade "we thought about architecture."
| If you see this in the diff | Required row | Else | |---|---|---| | jsonwebtoken, sessions, API keys | auth assumption, almost always REJECTED | fail checkpoint 2 | | Redis, queues, workers | durability / rate-limit assumption | fail unless CONFIRMED | | nodemailer, SendGrid, SMTP | email-send assumption | fail | | Postgres, Prisma, SQLite file | persistence assumption | fail unless the brief changed | | 409 on duplicates | uniqueness assumption | allowed only if CONFIRMED, or parked as GUESSED with no code |
Save as scripts/check-assumptions.mjs. It is deliberately picky. Treat it as a lab tool, not a production linter.
Is the smell list complete? No. It is a teaching fence. Students who rename nodemailer to mailer.mjs and call SMTP anyway still fail the human review. The script exists so the obvious fiction dies in CI.
Paste REQUIREMENTS.md into the repo. Do not edit it. If the agent rewrites the brief, that is an automatic zero for this checkpoint.
Why so strict? Because "helpful" rewrites are how a waitlist becomes a growth stack.