Public worked example · v1 · 2026-09-06
Build a task board with AI
Save a task, reload the page, and check that it is still there. Learn which work belongs in the screen, server and database, then use tests to check the code an AI coding tool proposes.
This is an AI-assisted reference implementation for teaching, not a student's project or evidence of student achievement. Use fictional tasks only. Run the example server on your own computer; do not expose it publicly.
For middle/high-school learners who can read basic HTML and Python and run terminal commands. Beginners should check files and commands with a tutor first. Requires Python 3.10+ and a browser. Running the example needs no paid AI tool, packages or API keys.
1. Does the saved task come back?
Extract the download and open a terminal in the task-board folder. Run the tests, start the server, then visit http://127.0.0.1:8766. On Windows, use py -3 instead of python3 if that is your Python launcher.
python3 -m unittest -v
python3 server.py --db tasks.sqlite3The first command checks the implementation against its rules. The second starts a server on this computer and stores tasks in tasks.sqlite3. Stop with Ctrl+C. Restart using the same database file; saved tasks should remain.
Agree on the specification before coding
- A title contains 1–80 characters after trimming surrounding spaces.
- A new task is incomplete and can be marked complete.
- Blank titles are rejected without being saved.
- Saved tasks remain after a server restart.
- A failed save must not be reported as successful.
A specification is a set of observable promises. Write the storage rules and failure behavior before asking an AI tool to build the app.
2. Separate the screen, API and database
| Component | Example files | Responsibility |
|---|---|---|
| Frontend: the user-facing screen | index.html, app.js | Read the title, send a request, check the response and refresh the list. |
| Backend: the request-processing server | server.py | Receive requests through an API, an agreed way for programs to communicate, and validate the title. |
| Database: stored records | tasks.sqlite3 | Keep each task's ID, title and completion state in a file, independently of a page reload. |
cursor = db.execute("INSERT INTO tasks (title) VALUES (?)", (title,))This line from server.py sends the title as a separate value. SQL is the language used to instruct the database; the ? placeholder keeps the submitted title separate from the SQL command.
| Request | Body | Result |
|---|---|---|
GET /api/tasks | None | 200: saved tasks |
POST /api/tasks | {"title":"Write a test"} | 201: saved task / 400: invalid input |
PATCH /api/tasks/1 | {"done":true} | 200: completed / 404: unknown ID |
Use the browser developer tools' Network tab to inspect a save request and response. Responses represent done as 0 or 1; the completion request requires the boolean true. Those types are part of the contract.
3. Check what the AI changed
Example instruction: “Read the specification and file responsibilities first. Explain your plan. Add a test that sends a whitespace-only title directly to the API. Leave unrelated files unchanged and report the actual test output and remaining limitations.” Use this with your chosen coding tool, such as Codex or Claude Code, then read its proposed changes.
if (!response.ok) throw new Error(data.error || "Request failed.");This line from app.js checks whether the server reported success. A button click is not proof that a task was saved.
Illustrative tutor feedback and revision exercise
“The browser's required field does not protect the API. Show a test that sends spaces directly.”
The supplied implementation includes both server validation and a database constraint. In a disposable copy, remove both and observe the blank-title test fail, then restore them. Record the actual output. This is a proposed exercise, not historical student feedback or a fabricated revision log.
The seven tests cover create/read, blank and long titles, SQL-like text, completion, restart persistence, request origin/content type, and oversized input. Passing these tests is not a production security assessment.
Scenario quizzes: decide before revealing the explanation
1. Tasks vanish after reloading. Inspect CSS or the storage path first?
The storage path. Check the POST response, GET result and database file location. CSS changes appearance; it does not preserve records.
2. The screen blocks empty titles. Is server validation still necessary?
Yes. A request can bypass the screen. Send spaces directly to the API and check both the 400 response and the absence of a new database record.
3. Storage fails but the screen reports success. Which part needs review?
Both the server's commit timing and the frontend's response handling. A transaction groups database work into success or failure. Commit before acknowledging success, then check the HTTP response in the screen.
4. Local tests pass. Can you publish by changing the server address?
Not yet. This demo has no login or per-user permissions. Review a production server, HTTPS, access controls and backup/restore before a separate deployment exercise.
4. Add a feature without losing old data
Homework: add low/normal/high task priority. Plan how to change an existing database before asking AI to implement it. A migration changes the storage structure while preserving existing records.
self.assertEqual(self.request("GET", "/api/tasks")[1][0]["title"], "Survive restart")This line from test_server.py checks that a title survives a restart. Add a similar check after your migration.
Submit the specification, source diff, before/after test output, a screenshot showing an old task after migration, and a note separating AI suggestions from your decisions. Check empty/error states and keyboard operation too.
| Criterion | Evidence for 2 points |
|---|---|
| Specification | Allowed values and failure behavior are explicit. |
| Existing data | A test proves old records survive the change. |
| API and tests | Server checks cover valid and invalid input. |
| Accessible screen | Labels, keyboard use and result announcements are checked. |
| AI review | The learner explains personal decisions and remaining limitations. |
Suggested tutor gate: 8/10 with full marks for data preservation and validation before the next extension. This is an exercise rubric, not an academy-wide grading policy.
Tutor session and pre-deployment checklist
Suggested 60–90 minutes: run/predict 10; trace requests 15; test 20; extend with AI 15–30; explain 10. Adjust to readiness; this is not a measured lesson duration.
Do not expose this demo or connect a public tunnel. Before a real deployment, review a production server, login/per-user permissions, HTTPS, secrets, migrations, backup restoration, request limits, monitoring and rollback with a tutor. Rehearse separately with synthetic data.
Technical references: Python explicitly does not recommend http.server for production. See the sqlite3 documentation for parameter binding and storage behavior.
Continue learning
High-school AI development course · Agentic engineering guide (Korean)
International-school AI and EC portfolios · Science/gifted-school AI portfolios
Book a consultation (Korean) to discuss learner readiness and the scope of tutoring.