Teaching Vibe Coding: A 15-Week Course, and What I Would Change

I taught HTML syntax in week 12. My students had been building, revising and deploying real websites since week 2.

That inversion is the decision other instructors ask me about most, and it is the one I would keep. What follows is the whole thing: the fifteen-week structure, the hundred-point rubric, what 27 graded submissions actually produced, and the four things I got wrong.

The decision people argue with

The traditional order is syntax, then structure, then a project. This course ran brief → generated site → deployment → critique → syntax.

By week 12, when I finally put <section> and <div> on a screen, every student in the room had already shipped something that used them. The lecture stopped being vocabulary and became explanation. They were not learning what a tag is. They were learning why the thing they had already built worked — and, more usefully, why the thing that broke had broken.

The risk is real and worth naming: a student who never opens the file learns nothing. Weeks 12 and 13 exist precisely because building alone does not produce understanding. The inverted order buys attention. It does not buy comprehension. You still have to teach the syntax — just later, to people who now have a reason to care about it.

The fifteen weeks

Week	In class	What they submitted
1	What web engineering is now; what a portfolio is for	—
2	First site from a plain-language brief	A portfolio page, posted publicly to the course board
3	The IAFA framework — identity, audience, function, aesthetic	The same page rebuilt from their own IAFA brief
4	Agent-driven building, session 1	Portfolio, revision 1
5	Agent-driven building, session 2	Portfolio, revision 2
6	Repository to live URL	Portfolio, revision 3 — midterm criteria published
7	Reading other people’s sites	Their live URL, plus what makes it theirs
8	Midterm	URL by a hard deadline, a 15-minute written test, and a peer evaluation of a classmate’s site
9	Databases — a form that actually stores something	A department site with a working board
10	Dissecting sites they admire	A URL they admire — and the 100-point rubric is published
11	Build week	URL in the post title
12	index.html, line by line	—
13	HTML practice; second peer scoring	Scored submissions
14	Physical AI lecture; build a small game; students write exam questions	Game, plus a question bank
15	Final exam	15-minute test, plus a Physical AI site submitted privately

Four decisions worth stealing

1. Publish the rubric five weeks before it is used

The hundred points went out in week 10 for an exam in week 15. Not as a courtesy — as an intervention. A rubric held back until grading measures how well students guessed what you wanted.

The honest caveat is in the results below: publishing it moved design and content, and did almost nothing for accessibility. A rubric describes; it does not assign.

2. Peer review twice, and let the second one count

Week 8 is diagnostic, week 13 is scored. What this teaches is not judgement of others. It is that somebody will actually look — which changes what a student is willing to ship. My impression is that students who had read six classmates’ sites wrote sharper briefs afterwards, but I cannot separate that from ordinary practice effects, so treat it as an impression rather than a finding.

3. Let students write the exam questions

Week 14 asks each student for short-answer and multiple-choice items. Writing a good multiple-choice question means knowing what a plausible wrong answer looks like, which is a harder test of understanding than answering one. It also produced a better question bank than I would have written alone.

4. Give the final exam a subject nobody can fake

The week-15 brief was a Physical AI site, on a subject lectured in week 14. A generic “build a portfolio” prompt lets a model generate plausible filler forever. A brief about a specific technical subject reveals in about ten seconds who read anything — and it did.

What 27 submissions actually produced

Twenty-seven final submissions came in with source code attached. Scored against the rubric above:

Measure	Result
Average total	50.5 / 100
Median	50.6
Highest	81.4
Lowest	17.3
Content & storytelling	56% of available points
Visual design & UX	53%
Technical functionality	45%
Responsive & accessible	44% — lowest

The failure patterns clustered:

• 67% shipped a single HTML file (18 of 27)
• 44% finished without connecting a database (12 of 27)
• 41% shipped zero accessibility attributes (11 of 27)
• 37% had under 2,500 characters of body text (10 of 27)
• 33% had not one media query (9 of 27)

Four things I would change

1. The point weights are backwards

Content is worth 30 points and functionality 20. As a claim about what makes a website good, that is defensible. As a grading instrument it is close to backwards.

Category	Points	Correlation with total score	Separation per point
Visual design & UX	30	0.79	90
Responsive & accessible	20	0.73	71
Technical functionality	20	0.70	100
Content & storytelling	30	0.61 — weakest	73

Content carries the most weight and discriminates the least. Which is exactly what you would predict once a model is in the room: it writes competent prose for everybody. Thirty points that nearly anyone can obtain is thirty points of noise in the grade.

Next time: 30 functionality, 25 design, 25 content, 20 accessibility. Not because content matters less to a reader — because it no longer tells me anything about the student.

2. A line in the rubric is not an assignment

Accessibility was worth 20 points and named alt text and keyboard operation in its own bullets. Eleven of 27 shipped no accessibility attributes at all. Nine had no media query on a rubric whose first accessibility bullet was mobile.

The fix is one week whose only deliverable is a phone screenshot of your own site and a keyboard-only walkthrough of it. Ten minutes of class time, and it would have moved the lowest category in the course.

3. The database week needs to be two weeks

Week 9 introduced stored, retrievable data. Twelve of 27 finished the course without ever wiring one up — and functionality is the category with the widest gap between the strongest and weakest groups, at 3.6×. The widest gap in the course sits behind its shortest unit.

4. The tool moved under us

Week 10’s literal instruction to students was to install the current version. Between week 4 and week 10 the interface had changed enough that my week-4 screenshots were wrong.

Plan for it. Teach the shape of the operation — describe, generate, run, correct — rather than the button, and never let a graded step depend on a menu path. Any course built on this class of tool will have at least one version break per semester.

If you have three hours, not fifteen weeks

Format	What survives	What you give up
3-hour workshop	One brief, one build, one deploy, one verification pass	Databases, peer review, and any syntax at all
5-day intensive	The above, plus a database and one round of peer review	Iteration — nobody rebuilds the same site three times
15 weeks	Everything, including the part where they get bored of their own site and improve it	Nothing, except the tool version you started on

The part that must not be cut is verification. It is the only piece that transfers to work that is not this assignment. A workshop where everyone leaves with a working page and nobody leaves able to tell whether it works has taught a trick, not a skill.

What I would not change

• Build before syntax. The week-12 lecture works because of what came before it.
• Deploy in week 6, not week 14. A URL you can send to your family changes how seriously the work gets taken. A year later, 50 of 53 deployed student sites were still responding — the only address that died was a paid domain nobody renewed.
• Publish the rubric early. The failures above are failures of assignment design, not of transparency.
• Examine on a subject, not on a genre. “Build a portfolio” is gradeable. “Build a site about this specific thing I taught last week” is diagnostic.

One external anchor, for anyone writing this up formally: Cindy Royal published a student-centred model for AI-augmented coding education in Journalism & Mass Communication Educator (2026), arriving at a compatible conclusion from a journalism programme rather than an engineering one. The finding travels across disciplines better than I expected it to.

Frequently asked questions

Do students actually learn to code this way?

Some do and some do not, and the rubric shows which is which. Building first buys attention; it does not by itself buy understanding. That is why weeks 12 and 13 exist — the syntax lecture lands differently when every tag on the screen is one the student has already shipped. A student who never opens the file learns very little, so the course has to force the file open somewhere.

How do you stop students from submitting whatever the model produced?

You cannot, and chasing it is the wrong fight. Instead make the graded thing hard to fake: a live URL you have to defend in front of classmates, a database that either stores a comment or does not, a phone layout that either survives or does not. Prose is the one category a model levels for everyone — in this cohort it separated the top group from the bottom group by only 1.7×, against 3.6× for whether the thing worked.

When should the rubric be shown to students?

Before it matters, not after. Mine went out in week 10 for a week-15 exam. The measurable caveat: publishing a rubric line does not produce the behaviour it describes. Accessibility was worth 20 points and named alt text and keyboard use explicitly, and 11 of 27 still shipped zero accessibility attributes. Anything you want to see has to be a submission, not a bullet.

What tools does a course like this need?

A browser, a text editor, one AI assistant and one free hosting account. Everything in this syllabus was done with an agentic coding tool plus a free deployment host. Expect the tool to change under you mid-semester — mine did, which is why week 10 opens with “install the current version” rather than a screenshot.

Is fifteen weeks necessary?

No. The three-hour version keeps the brief, one build, one deploy and one verification pass. The part that must not be cut is verification, because that is the only part that transfers. A workshop where everyone leaves with a working page and nobody leaves able to tell whether it works has taught a trick, not a skill.

Does this work outside computer science?

It appears to. Cindy Royal reached a compatible conclusion from a journalism programme, publishing a student-centred model for AI-augmented coding education in Journalism & Mass Communication Educator in 2026. The subject of the portfolio matters less than the fact that a stranger can open it.