Vibe Coding: Ship with AI

1. What vibe coding actually is

"Vibe coding" — building software by describing what you want and steering an AI that writes it — is neither magic nor a fad: it is a shift in where the human work lives, from writing every line to specifying, reviewing, testing and correcting. This lesson defines the practice honestly, separates what AI pair programming is good at from what it reliably gets wrong, sets up the workflow and guardrails, and makes the central argument of this whole course: the less you write yourself, the more it matters that you can read, test and debug. The vibe is a starting condition, not a maintenance strategy.

2. Prompts that produce working code

A prompt is a specification under time pressure: the same principles that make requirements good — context, acceptance criteria, constraints, examples — make prompts productive, and the same failure of vagueness produces the same failure of output, only faster. This lesson covers structuring prompts, the patterns that consistently improve code output (role, plan-first, examples, constraints, refusal to proceed), context selection and window discipline, the techniques for reviewing and repairing output, and how to build a prompt library your whole team benefits from. The craft is not incantation; it is writing requirements well.

3. Reading code you did not write

The skill vibe coding makes non-negotiable is reading unfamiliar code fast and correctly: you did not build the mental model while you wrote it, so you must reconstruct it from the artifact. This lesson covers how to read a generated diff systematically (top-down, contract-first), building the missing mental model with tools, the red flags that mark AI-generated code specifically, verification techniques from reading (desk-checking, tracing, test-reading), and how to organise code so *others* — human or AI — can read what your session produced. Reading is the review, and the review is the safety net.

4. api hiding

ai website

1. Build a working page in an hour

Theory meets the clock: this lesson is the full loop executed under a one-hour budget — scope ruthlessly, specify, generate in small slices, verify each, deploy early, and leave it better than the demo. You will build a real, public page with state and persistence, using the context file, prompt templates, reading checklist and reflection ritual from the previous lessons. The lesson's argument is experiential: an hour is enough when the loop is right, and the difference between an hour and a day is discipline, not typing speed.

2. Iterating and debugging with AI

The first generation is a hypothesis; everything after it is iteration — and in iteration the AI is at its most useful *and* its most dangerous, because a plausible wrong fix compounds quietly under a running system. This lesson covers the disciplined loop of change (one thing, verified, committed), debugging with evidence before theory, the failure modes of AI fixes (patching symptoms, weakening tests, the confident wrong root cause), refactoring generated code while green, and managing a long session so it stays a tool rather than a swamp. Fix causes; keep the loop short.

3. Polish, publish, and keep it alive

The demo is not the product: this lesson is the closing discipline of a build — the quality checklist that turns a working thing into a shippable one, the deploy you can repeat and reverse, the security and accessibility passes that generated code skips, and the maintenance reality that starts the day after launch. You will polish with the instruments (not the eye alone), publish with receipts, and leave the project in a state where the next session — next month, possibly by someone else — can continue it. A build is only finished when it is alive and legible.