Building a working thing you could not build alone, then making it live
The situation
Students can now produce working software without being able to write it. The build is fast and getting it to work is where the effort moved — noticing precisely what is wrong, describing it so another person could reproduce it, verifying rather than trusting. Those are assessable professional skills with a research literature behind them, and they transfer whether the artifact is a game, a calculator, a landing page or a diagnostic reference.
Want to do this yourself first? Build a classroom review game in an afternoon walks the whole loop with the actual prompts. To turn it into a graded student project with outcomes and a rubric, see Assigning an AI build.
Steps
-
Write a testable specification before you open any tool
Paper, before any tool
Three to six statements that must be true of the finished thing, each one checkable by someone else in under a minute. “A second person can join from their own phone” is a specification. “It should be fun” is not. This is the step that separates experts from novices in design research, and it is the step students skip.
What you only learn by doing it: Atman and colleagues watched 19 practising engineers and students work the same design task and found the experts spent substantially more effort on scoping the problem. If you want one habit to transfer out of this, it is this one.
-
Make the assistant propose a design, then find what is wrong with it before approving
PlayLab AI Anthropic-Claude for Education
Give it the role, the specification and the constraints, and require a written plan back before any code. Then read the plan adversarially: name at least two things it assumed, got wrong, or left out. Approve only after those are fixed.
What you only learn by doing it: Finding the discrepancies is the assessable act, not approving the plan. A student who approves a plan unchanged has almost certainly not read it, and that is worth saying out loud in advance.
-
Build the smallest version that actually runs
Core behaviour only, running locally, with an address you can open. No styling, no extra features. You want the earliest possible moment where you can use the thing instead of reading about it.
What you only learn by doing it: Expect a local address that only works on that machine. Students routinely believe they have shipped something at this point; they have not, and the distinction matters for the final requirement.
-
Play-test as a stranger, on a second device
A second device, or a private browsing window
Use it as someone who was not in the room. For anything involving more than one person, use two devices or two browser profiles. Record every discrepancy between what you expected and what happened — do not fix anything yet.
What you only learn by doing it: Separating noticing from fixing is deliberate. Students who fix while they test stop noticing, and noticing is the scarce skill.
-
Describe each defect so another person could reproduce it
The same conversation, and your defect log
One defect per report, in a fixed structure: what you did, step by step; what you expected; what actually happened. Then request the change and ask for it to be kept small.
What you only learn by doing it: In a seven-institution study of CS2 students, they located only about 70% of the bugs but fixed 97% of the ones they located. The failure is in finding and describing, not in editing — which is exactly why the log, not the fix, is what gets graded.
-
Verify against an external standard, including accessibility
Universal Access Bot (Accessibility) Read&Write (Everway)
Check the build against the written specification point by point, then against a short accessibility list: everything reachable by keyboard alone, every control labelled, nothing conveyed by colour alone, readable contrast. Fix what fails.
What you only learn by doing it: Generated interfaces ship unlabelled controls and colour-only status by default. Treating WCAG 2.1 AA as a graded requirement turns a compliance exposure into a learning outcome, which is the better trade in every direction.
-
Publish, test it cold, and compare what you predicted against what happened
Whatever hosting your course provides
Publish, then open the live link on a device that was never part of the build and hand it to someone uninvolved. Before you watch, write down what you expect them to struggle with. Afterwards, compare that prediction against what they actually did and against the rubric.
What you only learn by doing it: The comparison step is load-bearing. Prediction on its own does not improve judgement — in one study students stayed just as overconfident across thirteen exams — but comparison against an explicit external standard is the kind of calibration practice that does help.
Where this breaks down
Do not build this on a personal paid subscription. The Chancellor’s Office is explicit: “Reliance on free consumer tools or personal subscriptions may create inequitable access and should not be the basis for required coursework,” and faculty “should not be expected to require AI use until appropriate institutional tools are available” (CCCCO/ASCCC/CCCCIO memo ESS 26-52, 3 August 2026). Use an institutionally supported tool, and note that requiring a paid subscription also disqualifies a section from Zero Textbook Cost designation.
Offer a path for students who opt out. The H in the system’s own HUMANS framework is a human-centred approach in which people “should be able to opt out, where appropriate.” A required AI assignment needs an alternative that reaches the same outcomes.
Accessibility is an obligation and it attaches on day one. Title 5 §55200(c) requires that a student with a disability can “acquire the same information, engage in the same interactions, and enjoy the same services… with substantially equivalent ease of use.” Whether a student-published artifact is covered by the federal Title II web rule is genuinely unsettled — the third-party exception does not address coursework — and that ambiguity is a reason to put conformance in the rubric, not a reason to wait.
Publishing makes it public. Nothing identifiable about students on a live URL, a moderation answer for anything that accepts text from users, and a plan for taking it down. Work hosted on a personal account disappears when that account lapses.
The confident student is the one to watch. In a controlled study, people writing code with an AI assistant produced less secure code while being more likely to believe it was secure; those who distrusted the assistant and reworked their prompts did better. Observational work with novices found weaker students over-relying on incorrect suggestions and showing what the authors called an illusion of competence. Build the verification step in; students will not supply it themselves.
Know when to stop. Some builds reach the point where every fix breaks something else. Give students standing permission to roll back or cut scope, and assess them on recognising the moment rather than on grinding past it.
Provenance: this sequence is our construction. It is grounded in published research on debugging instruction, defect reporting, design expertise and AI-assisted programming — cited in the companion Teach Me lesson — and in California Community Colleges guidance on required AI use and accessibility. No study has tested this workflow as a whole, and no practitioner has yet verified it for this site.