Additional lesson · 00–02 minutes
Meet a web app: Study Sprint.
A web application is software used through a browser to carry out a task. A website can contain apps; the categories overlap.
One student. One task. A short plan.
A sprint is a short, focused work session. Our fictional student has 25 minutes to review notes. Study Sprint helps divide that time into preparation, focused work, and reflection.
Your role today: explore this prepared app, learn how its parts work, then describe a change Claude Code could make. No coding setup is needed to begin.
44-minute lesson. Use fictional text. Reflections are local, unsaved, unsubmitted, and ungraded. Paper, pair discussion, or a projected demonstration works too.
This app uses a fixed rule; no AI model is needed to run it. Next: meet the controls, then try the app.
Additional lesson · 02–05 minutes
Try Study Sprint, one step at a time.
- 1 Predict
- 2 Try the app
- 3 Compare
- 4 Continue
Now: inspect the labeled preview, then predict what Build my plan will show. Write below, or make your prediction on paper or aloud.
Working app · these controls create the plan
Lesson reflection
This box records your idea about the app. It does not enter a task or create a plan.
For Review notes + 25, the plan is 2 prepare + 20 work + 3 reflect = 25. Compare it with your prediction. Other durations change the work minutes; the task identifies the plan. This output is not saved.
Keep the same app in mind: next we trace how input becomes a result.
Additional lesson · 05–09 minutes
Trace the rule. Predict 45 minutes.
A rule transforms the input. Here, prepare takes 2 minutes and reflect takes 3; work gets the remaining time.
2 + 40 + 3 = 45
Work = 45 − 5 = 40. For 15 minutes, the same rule gives 2 / 10 / 3. We changed an input, not the rule.
A successful result is one case. Next: what should happen when the task is missing?
Additional lesson · 09–12 minutes
A state is what the app shows and allows.
Blank or whitespace-only tasks need recovery: ask for a task, keep 45 selected, focus the task field, and create no plan. Correct it to Review notes; the result becomes 2 / 40 / 3.
Run blank, then spaces only, then a valid task. Observe the error, preserved duration, and recovery.
These visible states are built from cooperating parts. Next: name each responsibility.
Additional lesson · 12–15 minutes
Four responsibilities, one working page.
Meaning and structure: heading, labels, input, menu, button, result region. Native controls provide some built-in behavior.
Presentation: spacing, color, type, and layout at different screen sizes.
Custom behavior: read the values, calculate the plan, and update the result.
The software that runs the page: renders HTML/CSS, executes JavaScript, and handles native controls.
Point to one Study Sprint example for each responsibility. These roles can live together in one file or across several files.
Next: two controlled rounds. Predict → observe → explain → retest, with only the current case open.
Additional lesson · 15–19 minutes
Round 1: change appearance, then retest.
- Round 1 of 2 Appearance · Current
- Round 2 of 2 Selected behavior · Upcoming
Before: Review notes + 25 produced 2 prepare, 20 work, 3 reflect.
We will enlarge the button and add form spacing using a prepared CSS variant.
Before: 2 / 20 / 3. After: 2 / 20 / 3. CSS changed presentation; the calculation stayed the same. Rerunning this case provides evidence that this behavior still works—it does not test every case.
Apply the prepared style change, then retest.
Next action: move to Round 2 of 2, where selected custom behavior is bypassed.
Additional lesson · 19–23 minutes
Round 2: bypass selected custom behavior.
- Round 1 of 2 Appearance · Not completed
- Round 2 of 2 Selected behavior · Current
Simulation: the demo bypasses custom plan generation. Its JavaScript is still running; native HTML required validation remains active.
You can type. The browser rejects an empty required task. A valid task produces no custom plan in bypass mode. After restoring normal behavior, the same Review notes + 25 case gives 2 / 20 / 3.
HTML and the browser supply native controls; our JavaScript adds the plan and whitespace recovery.
Try blank first, then Review notes. Restore normal behavior and submit the valid case again.
After completing both rounds, continue: connect an observed effect to a change request.
Additional lesson · 23–24 minutes
One change can involve several parts.
The menu needs a new choice. The existing general rule may already calculate it correctly; inspect and test before changing more code.
Ask: “Which responsibility might change, and what must keep working?”
Do not infer correctness from a button’s appearance. Observe the result.
Next: where are the files edited, and where do you inspect the change?
Additional lesson · 24–28 minutes
Edit project files. Inspect the browser.
study-sprint/ index.html styles.css app.js
These are example filenames, not a required three-file structure. HTML, CSS, and JavaScript roles can also share one HTML file.
Trace the loop: files → preview → browser → observed check → a specific revision request to Claude Code.
An AI coding tool can build an app that contains no AI feature. Next: preview and sharing are different.
Additional lesson · 28–32 minutes
A preview address is not a public link.
http://localhost:3000 is an example. “Localhost” points to the viewer’s own device, not automatically to yours.Backend
Application work on a server, such as processing shared records. A server can deliver static files without adding that application logic.
Storage
Keeps information for later. Displaying a result does not save it. This Study Sprint demo computes in the browser and has no save feature.
Add backend or storage only when a task needs them. Next: pairs request one bounded change.
Additional lesson · 32–39 minutes
Pairs: request one change and its check.
Choose a change: more spacing; a 30-minute choice; or remembering a task after reopening. Classify it as presentation, behavior, or saving information; explain any overlap.
Write the desired change, an example input and expected result, and one condition that must keep working. Swap with a partner and make the check more precise.
Copy your request for later Claude Code work if useful. Remembering a task is a future storage discussion, not a requirement for this first design. No reflection is sent or automatically exported.
Worked request:
In Study Sprint, add a 30-minute choice. Keep the existing choices. For Review notes + 30, show 2 prepare, 25 work, 3 reflect. If the task is empty or spaces only, ask for it and keep the selected duration.
Spacing concerns presentation. A new time choice affects the interface and needs a behavior check. Remembering a task requires storage; do not assume a displayed result is saved.
The request is a plan for later work, not a build or new submission. Next: explain the result yourself.
Additional lesson · 39–44 minutes
Explain it. Check it. Name your next question.
- Explain the 45-minute plan using input, action, rule, and output.
- Should a spacing change alter it? Describe a check.
- Where would you test a Claude Code edit?
Individual formative reflection: unsaved, unsubmitted, ungraded. Paper or spoken response is also welcome.
Worked explanation: Review notes + 45 is the input; Build my plan is the action. The rule gives 2 + (45 − 5) + 3 = 45, so output is 2 / 40 / 3.
Spacing should not alter that calculation. Rerun the same input, then test blank and whitespace-only task recovery. Inspect the local preview in a browser after Claude Code edits the files.
Next design studio: follow the guided route through the original design lesson. Together we will map responsibilities, label three states, and draft a testable contract. This introduction does not complete the packet. Bring your remaining question.
Bring the remaining question into the design lesson. Keep the task, visible behavior, and human check connected.