Design systems
that hold.

Every student confirms the full stack runs end-to-end on day one. Then the course opens with the central question: what makes a problem genuinely hard? You read and annotate a 60-line multi-file program you've never seen — tracing execution across files, predicting output before running.

You trace the behaviour of a multi-function, multi-file program under different inputs — writing your prediction before each run. The quiz tests whether you have the vocabulary to talk about why code fails at scale, not just when it does.

Each of the three complexity types gets dedicated class time with its own case study. Social complexity is the hardest layer — understanding what people actually need is a design problem, not a communication problem. You decompose three non-trivial problems on paper before touching any code.

You choose the problem, you design the algorithm, you build the program — without any AI assistance. This is the foundation the rest of the year depends on. The problem intuition you build here is what lets you evaluate AI output critically later.

AI becomes available — but as a critic, not a code generator. Before asking AI anything, you write your prediction: what do you expect it to say? Then you log every interaction: what was challenged, how you responded, and — critically — what you disagreed with and why.

The code-reading challenge is the final check of Unit 1 — can you annotate what each section does, trace execution, and identify the design decisions in code you've never seen? Pathway guides are distributed; you read them and annotate two you're considering.

Before any architecture work, you conduct the first stakeholder consultation using a structured protocol that distinguishes stated needs (what they say they want) from latent needs (what they'll discover they needed when they use a real system). This distinction shapes every design decision that follows.

No code is written until the architecture document is approved. This is a hard gate. The document must be specific enough that a classmate could implement from it. AI may help you research approaches — the architecture is yours.

Build begins. Your approved architecture is your contract. The question at the start of every class: "Am I building what I designed, or have I drifted?" AI use log entries must include your prediction of what AI will say before you ask.

Disrupted week: UN Day Wednesday Oct 21, Parent–Teacher Conferences Thursday–Friday Oct 22–23. Use the available time for independent build work. Students who have not yet received design approval must resolve this before Autumn Break.

The bug-injection exercise: a 30-line AI-generated program that runs without crashing but produces wrong results. Your task is to find and explain each bug before testing with inputs. AI produces plausible-looking errors — this exercise builds the skill to catch them. The mid-project check is a 10-minute conversation, not a grade: show the component you're least confident about, and name one thing that has surprised you.

A different-pathway partner reads your architecture document and asks: "What would break first under real load?" You document the challenge and write a response — either a design change or a justified defence. This is adversarial thinking as a design practice.

The second stakeholder consultation is the most valuable Criterion D moment available to you. A stakeholder who says "not quite" is giving you more than one who says "yes." Document the gap between what they said they needed in Week 1 and what they discover using a real system now.

3-day week only — Thanksgiving Thursday and Friday. Project submission, written evaluation, and AI category analysis due. Students who name specific failures — including places AI led them wrong — score higher than students who claim everything went fine.

Schema design decisions cascade upward through every layer. A bad schema makes every query harder, every API more complex, and every client less reliable. You design schemas on paper before writing any code, then use AI to interrogate your design — not generate it.

No AI this week. Raw SQL is the honest tool — understanding what an ORM does requires being able to do it without one. Every JOIN you can't write on paper is a JOIN you can't debug in production. You write queries on paper, predict the result set, then run and verify.

An API is a contract between a server and everything that talks to it. Precision in HTTP methods, status codes, and response shapes is professional courtesy to every future client — including future you. You build a multi-endpoint API with Mode 1 discipline before the break.

Security is structural — authentication and validation are not features added at the end, they are design decisions that affect the schema, the API contract, and the client. You add auth and validation to the API you built before the break, using AI to interrogate your choices.

This is the first Mode 3 experience of the year — and it is deliberately placed here. Students entering Unit 4 having never experienced Mode 3 would face a cold start on a large assessed project. This mini project gives everyone one complete Mode 3 experience at manageable scope. Mode 3 is qualitatively different from Mode 2: you act as the architect, not the critic. That difference cannot be read about — it has to be encountered.

80 lines of code: an unfamiliar database-backed Flask API you've never seen. Annotate what each section does, trace the request-response cycle for two different endpoints, and identify one design decision and its consequence. This is the readiness check for Unit 4.

Unit 4 opens with a 15-minute written transfer reflection — before any pathway work begins. What thinking do you carry from Pathway A? What will you need to relearn? What questions does this new domain raise that you can't yet answer? Transfer does not happen automatically; it requires this explicit bridging moment.

Your architecture is specific and load-bearing: removing any component should visibly break something. Your schema is normalised and the normalisation is justified. Your criteria must be measurable — specific enough that you can point to evidence for or against each one.

Full AI access begins. You direct AI across the system — every piece of AI-generated code is read before it is run. The analytical log entries are categorised by type (clarification, code generation, debugging, evaluation). Daily question: "Am I building what I designed?"

4-day week (PD Day Monday). After a week away, you re-read your design doc and commit history before writing a new line. A different-pathway partner gets your architecture explained to them — their confusion tells you where your design is unclear.

The modification drill prepares you for the oral defense: identify three changes you could be asked to make live, make each one deliberately, and explain exactly what changed and why — including any side effects. The most expensive design errors are the ones discovered too late.

Different partner from Presentation 1. Focus: "What has changed since last time? What feedback did you act on?" The three test cases must include at least one that reveals a real flaw — not just cases designed to pass.

3-day week (P-T Conferences Thu–Fri). Second stakeholder consultation: show a partial working system and ask whether it still matches what they need. The program must be in a submittable state by close of Wednesday.

The 8-minute defense includes a code walkthrough and a live modification challenge — you make a specific change on the spot and explain what changed, why it works, and what else it affects. Mode 3 means you had full AI access — so the hardest questions will be about AI-generated code.

The capstone opens not with a problem pitch but an integration reflection: what does each pathway contribute to this system, where is the genuine boundary between them, and what is novel at that boundary that neither pathway could produce alone? Students who can't answer this don't yet have a capstone — they have two adjacent projects.

Write one sentence: "This project will NOT include…" Something must be out of scope. If nothing is, you haven't scoped it. Define done before you start.

Every significant piece of AI-generated code is read before it is run. The prediction sections in the AI log are the audit trail. A 60% done product that works is better than a 100% planned product that can't be demonstrated.

By May 14, all major components must be connected and demonstrable to the stakeholder. Testing phase: 5 documented test cases, including edge cases and at least one that reveals a real flaw. Practise the modification challenge with a partner before the defense.

Prepare the 12-minute defense with a partner. Identify the three most complex parts of your system and practise explaining each. Prepare a non-technical version for the authentic audience — what you built, why it matters, who it helps.

The 12-minute defense: a live code walkthrough, a modification challenge (change something on the spot and explain the full effect), and a simulation of stakeholder questions. The authentic audience presentation is a 5-minute non-technical version — what you built, why it matters, who it helps.