0.3 How to follow along (projects, checkpoints, and "ship points")

How to use this guide

This guide is designed to be followed by building, not by reading end-to-end. Each section is meant to feed into a concrete outcome: a runnable prototype, a stabilized checkpoint, or a shipped slice.

• Read small → build immediately: consume one concept, then apply it in code.
• Keep steps narrow: ask for small diffs, run them, then iterate.
• Write down what changed: a tiny log of prompts and outcomes keeps you moving.

Projects

Projects are the backbone of this guide. They force you to connect prompting, code, and reality (running, testing, debugging, shipping).

Why projects matter

• They create real constraints: inputs, outputs, edge cases, and failure behavior.
• They make “done” measurable: the app runs, the tests pass, the user flow works.
• They expose the whole loop: spec → prompt → diff → run → fix → repeat.

How to follow a project

1. Start with a one-page spec: what it does, what it won’t do, and how you’ll know it’s done.
2. Ship a walking skeleton: the thinnest end-to-end path that proves the architecture.
3. Iterate in small slices: one feature or fix per loop, verified each time.
4. Harden: add tests/checks, better error handling, and guardrails.

Checkpoints

Checkpoints are scheduled moments where you stop adding features and instead stabilize what you have. They prevent the classic vibe-coding failure mode: rapid growth followed by a fragile mess.

What a checkpoint includes

• Run it from scratch: a clean install/setup path.
• Fix sharp edges: confusing errors, missing docs, brittle assumptions.
• Pay down debt: rename things, extract modules, delete dead code.
• Add a safety net: tests, smoke checks, or minimal eval cases.
• Write the “current truth”: a short doc describing what works today.

Ship points

Ship points are explicit moments where you declare: “this is good enough to publish as a version.” They’re how you keep momentum and avoid endless iteration.

What “shipped” means here

• The app does one useful thing end-to-end.
• It has a clear run path (commands, env vars, setup).
• Failure modes are handled (not perfectly, but intentionally).
• You can change it without fear (some tests/checks exist).

A repeatable workflow

Use this as your default “session loop” while working through the guide.

1. Set intent: define the smallest next improvement.
2. Constrain: files to touch, libraries, runtime, style rules, and “don’t change” boundaries.
3. Ask for a plan: 3–7 steps, with risks called out.
4. Request a small diff: avoid rewrites unless you’re intentionally doing a migration.
5. Run verification: tests, a demo flow, or a reproduction case.
6. Log outcomes: what worked, what broke, what you learned.
7. Decide: checkpoint, ship point, or next slice.

Templates you’ll reuse

Session log (copy/paste)

Date:
Goal (one sentence):

Inputs:
- Relevant files / context:
- Constraints:

Prompt(s) used:

Changes made (high level):

Verification:
- Commands run:
- Results:

Notes / next step:

Ship point checklist

- [ ] README has run instructions
- [ ] App has a working end-to-end flow
- [ ] Basic tests / smoke checks exist
- [ ] Error paths are intentional (not stack traces to users)
- [ ] One cleanup pass: names, structure, dead code removed

Recommended cadence

A sustainable cadence beats heroic sessions. Here are three modes that work well:

• 30 minutes: one small diff + one verification run.
• 60 minutes: one slice + a short checkpoint cleanup.
• 90 minutes: one slice + tests/checks + a ship point.

Where to go next

• 0.4 Required vs optional tools (AI Studio, editor, Git, runtime)
• 0.5 A note on UI changes & product naming
• Part I — Foundations
• Part II — Google AI Studio: First Contact