Application Build Studio

This lesson is a studio session: you apply every technique from this module to build a complete, working application end to end. The application is small enough to be realistic in a single session but large enough to require every skill you have studied — the build loop, multi-file prompting, interface design, data modeling, iteration discipline, version control habits, and steering the AI. You are not just practicing isolated techniques; you are integrating them into a coherent build process.

The Application: A Personal Reading Log

You will design and build (on paper, as a complete specification and prompt sequence) a personal reading log application with the following features: 1. Add a book: a form that accepts a title (required, string), author (required, string), status (required, one of: 'reading', 'finished', 'want-to-read'), rating (optional, integer 1-5, only valid when status is 'finished'), and notes (optional, string). 2. View the reading list: a page that displays all books, filterable by status. 3. Edit a book: the ability to update any field of an existing book record. 4. Delete a book: the ability to remove a book from the list. The application has three layers: a front-end (HTML/CSS/JavaScript), a back-end API (HTTP routes), and a database (one table: books). This specification is the describe phase for the entire project. From it, you will derive a complete build plan — one that any developer (or a well-prompted AI) could follow to produce this application.

Build plan structure: for each of the four features, you will produce: A. Database component — the table schema or schema change required. B. Interface specification — the HTTP route(s) that support this feature, with full input/output/error definitions. C. Anchor prompt — the one-paragraph project brief excerpt relevant to this feature. D. Scope prompt — the precise instruction for the AI for this loop. E. Verification checklist — the specific inputs you will test and the outputs you expect after this loop. This five-part structure for each feature is the build loop at scale made explicit. Every concept from Lessons 1 through 8 appears: the loop (A-E), multi-file prompting (C), interface design (B), data modeling (A), iteration discipline (E), and AI steering (C+D). Version control integration: at each milestone (after schema is finalized, after each route is verified, after front-end is connected), record a commit message describing the milestone. These form the commit history of your project.

Integrating the Full Loop

With the build plan complete, the actual build proceeds as a sequence of bounded loops — each one applying the full four-phase cycle. The discipline of this studio is not speed. The discipline is completeness: every loop has an explicit describe phase (your scope prompt), an explicit generate phase (the AI's output), an explicit review phase (reading the diff against the interface specification and verification checklist), and an explicit refine phase (correction prompt or acceptance). Two integration checkpoints deserve particular attention: Checkpoint 1 — Back-end complete, front-end not yet started: at this point, verify every route manually (using a tool like curl or Postman, or by tracing through the logic on paper). Confirm every interface specification is honored. Commit this state explicitly before touching any front-end code. Checkpoint 2 — Front-end and back-end connected: at this point, trace through each feature end to end. For the 'Add a book' feature: submit a valid book, confirm it appears in the database (or the in-memory store for the paper build), confirm it appears in the reading list view. For the 'Edit a book' feature: change a field, confirm the change persists. For 'Delete': confirm the record is removed and no longer appears. This is manual integration testing — not automated, but thorough. Version control at these checkpoints is mandatory: a commit after checkpoint 1 and a commit after checkpoint 2 are the two most important commits in the project.