Course proposal: A Brief Introduction to Not Writing Code¶
AI-accelerated software engineering, with a human in charge.
This syllabus is for instructors, curriculum committees, and students. It's a proposal for an upper-level undergraduate computer science elective, and no institution has approved or adopted it. Anything in [square brackets] is a placeholder for the adopting department to fill in.
Last checked November 8, 2026.
TL;DR
- A 15-week elective on building real software with coding agents. A human stays accountable, so you read, test, review, secure, and explain everything you ship.
- Eight labs, a team term project that ships a small real app, three short AI-free checks, and individual oral walkthroughs. Labs 6 and 7 use the project itself, so the eval and review work happens once.
- About 9–10 hours a week in total, in and out of class, for a [3]-credit course.
- Every assignment is labelled AI-free, AI-as-tutor, or AI-accelerated, and every AI-assisted submission includes a short AI log.
- Students need one frontier coding-agent plan (about $20/month as of November 2026) or an institutional license. No GPU, no model downloads, no API keys.
- The readings are this knowledge base's modules, and the instructor guide has week-by-week teaching notes.
Course description¶
Catalog description (draft). Coding agents now read codebases, run commands, and write and test changes. This course teaches students to use them to build software faster without giving up engineering judgment. Topics include how language models work and fail; agent harnesses, tools, and context; a disciplined agent workflow (explore, plan, test first, implement, verify, commit); reviewing AI-written code; prompt injection and agent security; evaluating models on your own tasks; multi-agent and cross-model review; cost; open-source contribution; and the effects of AI on learning and careers. Some work is done without AI, to build and check fundamentals. Teams ship a small real application built with supervised agents and defend every line of it.
The phrase "vibe coding" originally meant accepting whatever a model writes without reading the code (module 00). Agents do much of the typing in this course. Students decide what to build, write the checks, read what matters, and answer for the result.
Bryan's take: When I say vibe coding, I mean AI-accelerated coding, not really vibe coding: AI-accelerated engineering with a human in charge, not blind acceptance of whatever the model produces.
The course carries [3] credit hours (placeholder; the workload estimates assume 3) and meets [meeting pattern, for example two 75-minute sessions per week: one discussion and demo, one hands-on lab]. Readings are due before each week's first session.
Prerequisites¶
[Data structures course number]or equivalent, with a grade of[C]or better.- Comfortable in one programming language. The starter repositories use
[Python and/or TypeScript]. - Git basics: clone, branch, commit, diff, merge, pull request.
- Comfortable at a command line.
- Helpful, not required: some web development, a software engineering course, any prior use of chat assistants.
Students show up at very different levels. Some have shipped code at an internship, and some have never used a coding agent. The instructor guide covers how the labs scale for both.
Learning outcomes¶
By the end of the course, students can:
| # | Outcome | Assessed by |
|---|---|---|
| 1 | Explain how a language model produces text (tokens, next-token prediction, sampling, context window) and use that explanation to predict at least three kinds of failure, such as invented APIs, tokenization errors, and context degradation. | Lab 1, AI-free check 1 |
| 2 | Configure a coding agent with least-privilege permissions and a short instruction file, measure what fills its context, and explain what the harness adds to the model. | Lab 2 |
| 3 | Complete the explore → plan → implement → verify → commit loop with tests written before the implementation, and show evidence at each step (failing output, passing output, diff summary). | Lab 3, term project |
| 4 | Review AI-written code with a checklist, verify each finding by reproducing or refuting it, and report recall and false positives for human and AI reviewers. | Labs 4 and 7, AI-free check 2 |
| 5 | Threat-model an agent workflow with the lethal trifecta and the Rule of Two, apply at least two architectural defenses, and say which risk each one removes. | Lab 5, project security review |
| 6 | Build an evaluation of at least eight golden tasks, run it blind on two agent configurations, and report results with error bars and without overclaiming. | Lab 6 (the project's eval set), AI-free check 3 |
| 7 | Run an independent, multi-reviewer, cross-model code review with adversarial verification, and judge whether it was worth its cost. | Lab 7 (the project's cross-model review) |
| 8 | Contribute a small, tested, disclosed change to a shared codebase that follows that project's contribution and AI policies. | Lab 8 |
| 9 | Evaluate claims about models, benchmarks, prices, and licenses against primary sources, with dates. | Reading responses, AI-free check 3 |
| 10 | Read, debug, and test code without AI, and explain every line of their own submitted work in a live walkthrough. | AI-free checks, walkthroughs |
Required tools and cost¶
| Item | Notes |
|---|---|
| A laptop | macOS, Linux, or Windows with WSL. Must run a terminal, git, a code editor, and a container or VM tool. No GPU needed. [Or: department lab machines.] |
| Git and a GitHub account | Free. Used for every lab and the project. |
| Python 3 and/or Node.js | Whatever the starter repositories use. [Specify versions.] |
| A container or VM tool | Docker or equivalent, for the sandbox in Lab 5. [Or: a department-provided VM image.] |
| One frontier coding-agent plan | For example Anthropic's Claude Pro (includes Claude Code) or OpenAI's ChatGPT Plus (includes Codex). Both were $20/month as of November 2026 (module 12 price snapshot). [Or: institutional licenses provided by the department.] |
| Optional: a second lab's tool | A free tier or a classmate-operated tool from a different lab, for the cross-model steps in Labs 4 and 7. Never required. |
A 15-week term covers about four billing months, so a plan costs roughly $80 before tax at November 2026 prices. Billing dates can push that to a fifth month, so budget $80–$100 before tax and check your renewal date. Students can cancel after the term.
- Check current education offers before you pay. Vendors change student and education pricing often. Anthropic and OpenAI both sell education or institutional plans (module 12, module 15), and what they include varies. This proposal doesn't assume any particular discount exists.
- No lab needs a pay-per-token API key, so don't use one. Agent sessions re-send the whole conversation every turn, and heavy use on API billing gets expensive fast (module 12).
- Free tiers are fine for a second opinion, but their limits are too tight for a main tool. As of November 2026, OpenAI's free tier gave only limited Codex access on a small model (module 12).
- Nobody's grade depends on ability to pay.
[Department: describe how students who can't buy a plan get access, for example loaner seats on a team plan or lab accounts.]Each term, the instructor checks that every lab fits within one $20 plan's limits (refresh checklist). - Consumer plans may let the vendor train on your chats and coding sessions, depending on a setting you control, and education and enterprise terms differ. Check that setting before the first lab (module 15).
Bryan's take: API pricing is too expensive for heavy agentic use. Subscriptions are what make it affordable to work this way every day.
Bryan's take: For coding, Claude and Codex are the best, in my opinion. Different models are better for different use cases.
Opinions about models go stale fast. The course works with any frontier coding agent that can read a repository, run commands, and edit files. Module 03 covers the current options.
Weekly schedule¶
Workload¶
Plan on about 9–10 hours a week in total, which is typical for a [3]-credit course: about [2.5] hours in class and 6–7.5 hours outside it. The schedule's last column estimates each week's outside hours for reading, labs, and your share of the project. Weeks 1–4 are lighter while you set up. No week is planned above 7.5 outside hours. If you're regularly well past that, tell the instructor, since the estimates are supposed to be checked against real students each term.
Two labs are done on the term project instead of next to it. Lab 6 is the project's eval set and Lab 7 is its cross-model review, so you do that work once and it's graded once.
Schedule¶
Read the listed sections before the week's first session. The default depth for every module is "Students: Foundations + In practice" (student path). Each lab comes out at least a week before it's due, and its header gives both weeks. AI-free checks take about 30 minutes, in class.
| Week | Topic | Read | In class | Due | Hours outside class |
|---|---|---|---|---|---|
| 1 | What this course means by vibe coding | 00 (all); 15: producing vs learning, academic integrity | The "using AI to code is like..." exercise (00 Try it); walk through the AI-use policy; tool setup clinic | Setup checklist; AI-free diagnostic (in class, ungraded) | 4 |
| 2 | What an LLM is | 01: next token, what it is not, tokens, sampling, hallucination, sycophancy, mental model | The human language model game (01 Try it); live demo: a hallucinated API | Reading response | 5 |
| 3 | Harnesses, tools, and MCP | 06: what a harness is, history, tools, MCP, baseline setup; 13: a loop in 30 lines | Live: the agent loop and the context breakdown; trace a 30-line loop | Lab 1 | 5 |
| 4 | Context engineering | 07: the ladder, prompting basics, what fills the window, context limits, instruction files | Trim a bloated AGENTS.md; rewrite vague prompts; AI-free check 1 |
Lab 2; teams formed | 5.5 |
| 5 | Agentic workflows | 08: the loop, it stops when it thinks it's done, autonomy, Yegge's stages, core loop, tests as contract, failure modes | Live: a full explore-to-commit session; discuss how much autonomy works | Project pitch | 6 |
| 6 | Learning with AI, integrity, careers | 15: the evidence, how to learn with AI, careers, deskilling | Write-the-policy exercise (15 Try it); AI-free debugging practice | Lab 3 | 6 |
| 7 | AI code review | 10: good and bad at, layered workflow, verify findings, severity, reviewing AI PRs, accountability | Live demo: tautological tests; review a seeded PR together | Project design doc | 6.5 |
| 8 | Security and prompt injection | 11: Foundations (all), incidents, coding-agent risks, defenses, student checklist | Live demo: injection through a README, in a sandbox; threat-model a workflow (11 Try it); AI-free check 2 | Lab 4; Lab 5 sandbox plan approved | 7.5 |
| 9 | The model landscape and reading claims | 03: names and tiers, places in the chain, best model for the job, picking next month; 05: what a benchmark is, claim checklist, benchmark-maxing; for Lab 8: 13 etiquette | Read a real launch post against the checklist; Lab 8 kickoff | Lab 5; Lab 8 phase 1 (project proposal) | 7.5 |
| 10 | Building your own eval | 05: harness matters, productivity evidence, vibes, build your own eval, small-eval statistics, reward hacking | Golden-task workshop; compute error bars by hand | Project: vertical slice deployed | 7 |
| 11 | Multiple agents | 09: Foundations (all), patterns, review swarm, cross-model review, parallel builders, budgets, anti-patterns | Debate vs vote (09 Try it); assign Lab 7 PRs within each team | Project security review; Lab 8 phase 2 (go-ahead received, or switch to the class repository) | 7 |
| 12 | How models are made; open vs closed weights | 02: pipeline, distillation, should you fine-tune?, models that tune themselves; 04: weights, openness spectrum, licenses, hardware math | Fine-tune, retrieve, or prompt? (02 Try it); license review (04 Try it); AI-free check 3 | Lab 6, which is the project's eval set | 7 |
| 13 | Costs and the open-source ecosystem | 12: three ways to pay, why agents eat tokens, worked example, cost per task; 13: map of the stack, AI slop, students contributing | The maintainer's chair (13 Try it); a quick team budget (12 Try it) | Lab 7, which is the project's cross-model review | 7 |
| 14 | Keeping up | 14: what stays stable, ups and downs, model, task, or harness?, launch claims, a routine, evaluating a release | Incident presentations (14 Try it); final-sprint working session | Lab 8 | 7 |
| 15 | Ship and reflect | Re-read 00: six ideas and 15: the human side | Final demos; revisit the week 1 analogies; course retrospective | Shipped app and demo; individual reflective report | 7 |
| Finals | Walkthroughs | Individual 10-minute walkthroughs of project code | 1 |
Term project¶
What you build¶
Teams of three or four use supervised coding agents to build and ship a small, real application for a real user. "Real" means someone outside the team relies on it, such as a campus club, a nonprofit, a lab group, a local business, or other students using your tool. "Small" means one clear job done well. Assessment focuses on how you specify, constrain, verify, review, and secure the agents' work, and what you learn doing it.
Constraints¶
- Name one person outside the team as your user and meet them at least twice. At least three people outside the team use the app before week 15.
- The app costs nothing beyond your agent plans. Deploy on a free hosting tier, or ship an installable package, CLI, or browser extension.
- The app makes no paid model API calls, and it doesn't need to use AI at all.
[Unless the department provides API keys.] - Use synthetic data. Real personal data stays out of development and prompts. An app that will store other people's personal data needs instructor approval and must follow
[institution's data policy](module 15). - Protect
mainwith branch protection and one approving review from a teammate who didn't write the change. Turn on secret scanning and run tests in CI.[Department: provide a private hosting plan that supports these controls, or an equivalent private service; do not require students to publish their coursework or buy hosting features.]Every pull request uses the PR template from module 10, including "What the agent did vs what I did." - Agents are always supervised. Any autonomy level is allowed if your checks can catch what you've stopped watching (module 08). Unattended runs need a turn cap, a sandbox, and a pull request a human approves. Skip-permissions modes are allowed only in a disposable sandbox (module 11).
- Keep your commit history, PR descriptions, AI logs, and exported transcripts of key decisions.
Deliverables¶
| Due | Deliverable | What it contains | Tier | Weight |
|---|---|---|---|---|
| Week 5 | Pitch | One page: the user, the problem, the smallest useful version, the biggest risk | AI-as-tutor | Gate (feedback only) |
| Week 7 | Design doc | Problem and user; requirements and non-goals; architecture and data model; the interfaces you'll write before agents build in parallel (module 09); test strategy (what is your oracle?); which tasks go to agents and at what autonomy; quota plan; risks | AI-as-tutor: agents may interview you and critique drafts; the decisions and the text are yours | 5% |
| Week 10 | Vertical slice | One end-to-end feature deployed, with tests and CI | AI-accelerated | Milestone (feedback only) |
| Week 11 | Security review | Rule of Two analysis for your agent workflow and for the app (module 11); the team checklist items that apply; every dependency verified as real and intended; scanner results; an independent fresh-session security review (a different lab’s model where available), with each finding verified; fixes | AI-accelerated | 5% |
| Week 12 | Eval set | This is Lab 6, done on your project: at least eight golden tasks from your project's history (three or more per member), with hidden tests, run blind on two agent configurations and summarized with error bars, plus the configuration your team chose for the final sprint and why. Nothing extra to submit. | AI-accelerated; task selection and scoring are yours | Graded as Lab 6 |
| Week 13 | Cross-model code review | This is Lab 7, done on your project: each member runs a review swarm with adversarial verification on a different teammate's pull request from week 10 on, using a different lab's model where possible. Confirmed High and Medium findings are fixed through reviewed PRs. Nothing extra to submit. | AI-accelerated | Graded as Lab 7 |
| Week 15 | Shipped app, repository, and demo | Working app with real users; README covering trade-offs, rejected alternatives, and a short section on what your eval (Lab 6) and reviews (Lab 7) found and what you changed; tests and CI green; a 10-minute demo that includes one thing an agent got wrong | AI-accelerated | 10% |
| Week 15 | Reflective report (individual) | "What I learned vs what the AI did" (below) | AI-free | 6% |
| Finals | Walkthrough (individual) | 10 minutes: explain code you merged, answer "what if" questions, show the test that guards it | AI-free | 4% |
Each team deliverable gets one score, adjusted per member using individual evidence: commits, reviews given, AI logs, and [peer evaluation process].
The reflective report¶
Write 1,000 to 1,500 words without AI, and back each answer with evidence from your commits, PRs, and logs.
- What I built. Your part of the system, in two paragraphs.
- What the agents did. Roughly how much of your merged code an agent drafted, and how you know.
- What I did that the agents didn't or couldn't. Decisions, specs, tests, reviews, debugging.
- Three times I overrode an agent, and why.
- One bug an agent introduced, and how it was caught (or missed).
- What I can now do without AI. Rebuild one small component without AI before you write this section (module 15, habit 7). What came easily? What didn't?
- Where I sit on Yegge's stages (module 08), and whether that was the right place for this project.
- What I'd do differently next time.
Assessment¶
| Component | Weight | Notes |
|---|---|---|
| Labs 1–8 | 45% | Labs 1–5 and 8: 5% each. Labs 6 and 7: 7.5% each, because they're done on the term project and serve as its eval set and cross-model review. Each lab has its own rubric. |
| Term project | 30% | Design doc 5%, security review 5%, shipped app 10%, reflective report 6%, walkthrough 4%. |
| AI-free checks | 15% | Three in-class checks, 5% each (weeks 4, 8, 12): reading code, predicting what code and tests do, finding bugs by hand, explaining core concepts. |
| Participation | 10% | Reading responses, in-class exercises, peer review, Lab 8 maintainer shifts if you use the class repository. |
[Grading scale.] [Late-work policy.] [Attendance policy.]
The instructor or a TA may follow up any submission with a five-minute walkthrough. Expect at least one per term besides the final. If a walkthrough shows you can't explain your submission, it doesn't count as yours yet, and you get one chance to redo the walkthrough or the work. The instructor guide describes how walkthroughs are run.
AI-use policy¶
This course requires both AI-assisted and AI-free work. The research summarized in module 15 finds that outsourcing the thinking weakens the skill you outsourced, while using AI to ask why, get hints, and check understanding mostly doesn't. Supervising agents also depends on skills you build by hand, like reading and debugging code. So the course mixes AI-free practice, AI-as-tutor learning, and full acceleration.
The three tiers¶
The labels come from module 15's suggested policy.
| Tier | What's allowed | What's graded |
|---|---|---|
| AI-free | No AI tools of any kind, including IDE autocomplete and AI features in search or editors. | The fundamentals you need without help. |
| AI-as-tutor | AI may explain, give hints, ask you questions, and critique your work. It may not write code or prose you submit. | Your own work, and your use of AI to learn. |
| AI-accelerated | Use any AI tools. | The result, your design decisions, your verification evidence, and your ability to explain every line. |
Two clarifications:
- A model you're studying isn't "AI help." In Labs 1 and 5 the model is the subject of the experiment. The tier governs who writes what you submit.
- You write your own reflections, AI logs, PR descriptions, and replies to reviewers in every tier. In AI-accelerated work, AI may critique them but not write them.
Tier for each assignment¶
| Assignment | Tier |
|---|---|
| Week 1 diagnostic; AI-free checks 1–3 | AI-free |
| Reading responses | AI-as-tutor. You're encouraged to have AI quiz you on the reading (module 00). |
| Lab 1: Tokens and temperature | AI-as-tutor |
| Lab 2: First agent session | AI-accelerated |
| Lab 3: Plan, test, build | Part A (spec and acceptance tests): AI-as-tutor. Part B (implementation): AI-accelerated. |
| Lab 4: Review AI code | Part A (hand review): AI-free. The rest: AI-accelerated. |
| Lab 5: Prompt injection | AI-accelerated, under the lab's mandatory safety rules |
| Lab 6: Your own eval | AI-accelerated for tooling. Task selection, hidden tests, and blind scoring are yours. |
| Lab 7: Multi-agent review | AI-accelerated |
| Lab 8: Open-source contribution | AI-as-tutor, or stricter if the project's own policy is stricter |
| Project design doc | AI-as-tutor |
| Project code and security review (the eval set and cross-model review are Labs 6 and 7) | AI-accelerated |
| Project reflective report and walkthrough | AI-free |
Rules that apply in every tier¶
- Every AI-as-tutor or AI-accelerated submission discloses AI use in an AI log (template below).
- You're responsible for everything you submit, including bugs, security flaws, and license problems an AI introduced (module 15).
- If you can't explain it in a walkthrough, it doesn't count as yours.
- Don't paste anyone's personal data or credentials into AI tools. Share a partner’s or teammate’s code only for assigned collaboration, with their consent and using the course-approved tools and data settings (module 15).
- The stricter rule wins. An open-source project's AI policy, a client's confidentiality request, or another course's policy overrides this one when it's stricter.
- Keep your commit history and export the transcript of any agent session that made a key decision. Most harnesses save sessions locally.
- When you're unsure whether a use is allowed, ask the instructor in writing before you submit.
AI log template¶
Put this at the end of each AI-as-tutor or AI-accelerated submission.
## AI log: <assignment name>
- Tier: <AI-as-tutor | AI-accelerated>
- Tools: <harness and version, model, plan>
- What I used AI for: <two to five bullets>
- What I did myself: <two to five bullets>
- One thing the AI got wrong that I caught, and how I caught it (or “none observed”):
- One thing I learned:
- Transcripts attached: <file names, for key decisions>
For commits, pull requests, and READMEs, a one-paragraph disclosure is enough. Use module 15's template:
AI assistance: I used [tool] to [explain X / suggest a fix for Y /
generate the initial version of Z]. I reviewed and modified the output,
[wrote the tests myself / rewrote the parser]. The AI incorrectly
[suggested a package that doesn't exist / missed an edge case], which
I caught by [running the tests / reading the docs].
If your tool adds a co-author trailer to commits, leave it on unless a project's rules say otherwise (module 15).
Accessibility¶
[Insert the institution's accessibility statement and the disability services office's contact information.]
For this course:
- A written or recorded walkthrough can replace an oral one as an accommodation.
- AI tools can be assistive technology, for example voice-driven coding or plain-language explanations (module 15). If you need one during an AI-free assessment, arrange it through
[disability services]in advance. It won't count against you. - Project interfaces must pass applicable accessibility checks and a keyboard-only test before the final demo. Use an automated checker for web interfaces, and document equivalent checks for CLI or installable tools. Generated interfaces often miss labels, contrast, and keyboard access.
Academic integrity¶
[Insert the institution's academic integrity policy and reporting process.]
In this course, these are integrity violations:
- Submitting AI-written code or prose in AI-free or AI-as-tutor work.
- Leaving out AI use that the AI log should have disclosed.
- Fabricating evidence or altering logs, transcripts, test output, or commit history to misrepresent what happened. Clearly labelled privacy redactions and the history-squashing step required by Lab 4 are allowed; retain original evidence privately.
- Submitting another person's work as your own, whether or not an AI was involved.
- Breaking the safety rules in Lab 5, or testing injection against systems you don't own.
- Violating an open-source project's AI policy in Lab 8.
The course doesn't use AI-detection tools as evidence, because AI use is hard to detect reliably (module 15). It relies on process evidence (commits, logs, transcripts) and walkthroughs instead. A walkthrough you can't complete isn't by itself a finding of misconduct. It means the work doesn't count yet.
Keeping this course current¶
This field changes monthly, and parts of this syllabus will be wrong within a term (module 14). Verification, context control, security, review, and honest evaluation should outlast the current names, prices, commands, and policies. Before each term, re-verify:
- Plans and prices for the tools students will buy, and current education offers (module 12).
- Data and training terms for consumer and education plans (module 15).
- Every command and setting a lab names: plan mode, the context view, checkpoints, review commands, permission and sandbox settings, hooks, non-interactive mode. For Lab 5, check how deny rules treat shell commands and whether each harness's own sandbox starts inside the recommended container.
- The free tools in Lab 1, a tokenizer page and a playground with a temperature control.
- The AI policies of open-source projects suggested for Lab 8 (module 13).
- That each lab still fits in one $20 plan. Run it yourself and note the quota used.
- That the live demos still fail the way they're supposed to. Models improve, and some demos stop working.
- The "Last checked" date of each assigned module. Anything older than about six months needs a check.
- The institution's AI and integrity policies, which are changing too.
The instructor guide's refresh checklist has the full list and how to check each item.
Sources¶
Everything in this syllabus draws on the modules of this knowledge base, which cite their primary sources. The most directly used:
- Module 00: the course's stance and ground rules.
- Module 08: the explore → plan → implement → verify → commit workflow.
- Module 10: review checklist, PR template, accountability.
- Module 11: threat models and defenses.
- Module 12: plans and prices.
- Module 15: learning evidence, the three-tier policy, disclosure, data privacy.