Module 00Term 1 · Foundations

Orientation: The Vibe Engineer Mindset

Sign in to save your progress across devices. Until then it is kept in this browser.

Why this matters

A demo has one user who is you, on a good network, with clean data, doing the happy path once. Production has thousands of users, bad networks, hostile input, concurrent clicks, flaky dependencies, a cloud bill and a regulator. AI tools are excellent at demos. The gap between demo and production is exactly the 111 items on the poster.

Learning outcomes

  1. Explain the difference between a prototype, an MVP and a production system, and what each owes its users.
  2. Classify any feature by blast radius (what is the worst outcome if it is wrong?).
  3. Adopt the tech lead stance: the AI is a fast, confident junior engineer who never says "I don't know."

Lessons

0.1 The five failure lenses

For any feature, ask the five questions. This is the habit the whole school builds.

Lens Question Modules
Adversary What if the user is an attacker? M05, M06
Scale What if 1,000 people do this at the same moment? M03, M09, M10
Failure What if the thing I call is slow, down or returns garbage? M07, M08
Change How do I ship and undo this safely? M11
Visibility How would I even know it broke? M12, M13

0.2 Blast-radius classification

  • Class A, reversible and private: a UI tweak. Ship freely.
  • Class B, data-bearing: stores or reads user data. Needs access control + backups.
  • Class C, money or identity: payments, auth, credit decisions. Needs idempotency, audit trail, tests, review.
  • Class D, irreversible or external action: sending messages, moving money, deleting data, agent actions. Needs human approval and a kill switch.

0.3 Why AI code fails in specific, predictable ways

AI models optimise for "looks correct and runs." They reliably:

  • skip authorization checks (the code works for the honest user),
  • put secrets where they are convenient (frontend env vars),
  • write the happy path and swallow errors,
  • query in loops (N+1),
  • invent packages that do not exist (slopsquatting risk),
  • report "done" and "all tests pass" without running anything.

Knowing the pattern is half the defence.

0.4 Case studies (read before Week 1)

  • CVE-2025-48757, Lovable: missing Row-Level Security exposed read/write access across 170+ generated apps. Lesson: a client that talks directly to the database is only as safe as the database's policies.
  • Replit / SaaStr, July 2025: an agent with production credentials deleted a live database during a code freeze. Lesson: separate environments, least privilege, human approval on destructive operations, tested backups.
  • Veracode 2026: around 44% of AI code-generation tasks introduced a known vulnerability; the security pass rate has stayed near 56% for four years. Lesson: model upgrades will not save you; process will.

Lab 0: Audit your own app

Take an app you have already built with AI.

  1. List every feature and give each a blast-radius class.
  2. Run the five lenses on the two highest-class features.
  3. Run gitleaks detect over the repo history.
  4. Open your browser dev tools on the live app; search the loaded JS bundle for key, secret, sk_, service_role.

Definition of Done

Reflection prompt

Which of the 111 items did you assume your AI tool or hosting platform "handles for you"? Write down how you would verify it.