Artist statement, process arc, the Five Questions from the Epistemic Stewardship Framework, disclosure statement, and the M6 completion checklist.
Twenty sessions, six milestones, one quarter question. This table traces how Baseline evolved from a vague idea about gesture games into a security-hardened, deployed platform.
| Milestone | Sessions | What Changed | Key Resistance |
|---|---|---|---|
| M1 — Exploration | 1–2 | Three Google AI Studio prototypes. Discovered the quarter question by building — not by planning. | Rejected VibeWord Animator as off-question before it could become the direction. |
| M2 — Position | 3–6 | Single game → multi-test platform. Position Statement written. "Not diagnostic" established as non-negotiable. | Rejected AI suggestion to stay small. Rejected healthcare provider access for v1. |
| M3 — Frontend | 7–9 | Homepage, color system, GAME_STANDARD.md. Bilateral Coordination Test functional. Camera mirroring solved. | 5-iteration mirroring fix. Per-hand scoring over total. Hard version control lesson. |
| M4 — Backend | 10–17 | Supabase auth + data persistence. Three tests deployed. User testing. Chart.js graphs. Deployed to Vercel. | Understanding before building backend. Audio detection algorithm. Shelved Rhythm Sync. |
| M5 — Security | 18–19 | RLS fixed, guest mode removed, XSS patched. Fine Motor Precision renamed and refined. Platform hardened. | Pragmatic XSS fix (escapeHtml helper) over full DOM API refactor. Deferred password complexity. |
| M6 — Reflection | 20 | Process book completed. All documentation, system maps, leverage points, and records of resistance compiled. Artist statement and disclosure written. Platform presented. | Deliberate documentation of the full arc. Reflecting on AI collaboration and design decisions made across all six milestones. |
I started this project by establishing clear guidelines in the PRD. What Baseline should measure, who it's for, and what it should enable. That decision to build from a defined position before writing any code became everything. Every session after that, when I faced a choice about features, architecture, or security, I came back to that PRD. Does this serve the goal? Does this track results over time the way I planned?
The core insight is simple but took the whole project to fully understand: what matters isn't a single score. What matters is seeing how your abilities change over time. I built graphs to show that change, a history page where you could come back again and again and watch your own progress. That's the meaningful data. Not the number, but the arc.
Learning to build Baseline meant learning to work alongside AI without letting it make my decisions for me. I brought Claude into almost every session, but I made sure I understood what it was doing. When it generated code, I asked it to explain. When it suggested a direction, I challenged it against the PRD. I learned enough about Supabase and Vercel to actually deploy this thing myself. I have a new understanding of the backend, I know where the data lives, and I see how the security works.
AI would often auto-suggest solutions that seemed reasonable, but when I slowed down and thought about whether they actually served the user, the answer was often no. I learned to say no, document why, and keep building toward what I actually believed was right. That discipline of articulating and marking down my process became its own form of clarity.
Going forward, I understand how to use AI as a tool in my UX workflow without outsourcing my decision-making to it. I know how to push back on suggestions, how to ask clarifying questions about the thinking behind a proposal, and how to stay grounded in user needs when AI offers something that feels easy but doesn't actually serve the design. That's the skill I'm taking with me.
The Epistemic Stewardship Framework asks five questions at project close.
AI would sometimes get ahead of itself and create solutions without being grounded in actual understanding of the user or the purpose of Baseline. It would generate features, write explanatory text, propose architecture patterns, all with confidence and fluency that made them seem reasonable. But they weren't connected to the core question of what Baseline actually does — help people track their abilities over time.
That ease of generation meant I had to work harder to slow down and ask: does this actually understand what we're building for? Or is this just plausible-sounding code that happens to compile?
In Session 8, AI suggested using total score for the Bilateral Coordination test. I rejected this and insisted on per-hand scoring instead (Left: 24, Right: 23, Symmetry: 96%). That wasn't a UX preference. It was a claim about what bilateral coordination actually means. The per-hand breakdown shows whether my hands are balanced or if one is compensating for weakness in the other. Total score would have hidden that.
That push back produced a test with actual clinical meaning, not just a game that gives a number. It meant refusing the convenience of a simpler output in favor of something that actually tells the truth about a user's body.
You can see the full pattern of these deliberate choices across the Records of Resistance. 53 moments where I pushed back to keep Baseline grounded in what it actually needed to be, where I slowed down and questioned AI's suggestions, and insisted on accuracy over convenience.
I'm a designer, not a coder. But by working with AI, I was able to actually build something real instead of just designing a prototype. I learned how MediaPipe works, how to build the backend with Supabase, and how to deploy with Vercel.
The key was asking Claude to explain what it was doing instead of just accepting the code. Once I understood it, the whole platform became more real to me. I could see where the data lives and how the security actually works.
I don't need to be a professional engineer to understand the code I'm working with. I just need to ask the right questions and actually pay attention to the answers.
I would establish clear standards before building. GAME_STANDARD was the unified phase architecture (Welcome → Practice → Test → Results) that I created in Session 8 after needing to do lots of manual adjusting with AI instead of having it already defined. Once I had it, every test after that was faster and cleaner because they all followed the same pattern.
If I started over, I would write GAME_STANDARD before building the first test. That one document saved so much friction and made the codebase feel intentional instead of scattered.
More broadly, I want to do more of that going forward. Establish the framework first. Understand the schema before writing the code. Document the standard before implementing variations. It feels slower at the beginning, but it compounds into speed and clarity later.
Baseline lets you track your own reaction speed, coordination, and precision over time using device sensors. You can measure yourself whenever you want and watch how you change. It uses interesting inputs like camera, microphone, and touch to test these functions in ways that weren't possible before.
Project: Baseline — AI 201, Spring 2026 · Lily Anderson
AI Tools Used: Claude (Anthropic) was the primary AI collaborator throughout this project, used in every session from 3 onward. Claude assisted with code generation, debugging, architecture decisions, and documentation. Google AI Studio (Gemini) was used in Sessions 1–3 for initial prototyping. MediaPipe Hands (Google) provides the computer vision inference that powers the Bilateral Coordination and Fine Motor Precision tests.
Nature of AI Use: Claude generated code on request, but all architectural decisions, measurement approaches, and design principles were established through deliberate conversation — and frequently through deliberate rejection of AI suggestions. The 18 Records of Resistance document the moments where AI suggestions were overridden and why. AI did not make creative decisions; it generated options from which I chose, or generated solutions that I evaluated, modified, and sometimes rejected entirely.
AI-Generated Content in This Document: The process blog entry summaries and structural scaffolding for this M6 document were drafted with AI assistance, then reviewed and edited. The Records of Resistance narrative text reflects my own words and reasoning, drafted with AI as a writing partner for structure. The artist statement was initially drafted with AI support, but I rejected that version entirely and rewrote it in my own voice and from my own reflection.
What AI Could Not Do: AI generated code and suggestions. The actual decisions were mine—what to name things, what features to prioritize, how to design the interface, what the data should show. I had to figure out what users actually needed from watching them test it. I had to understand why tracking change over time mattered more than a single score, or why the bilateral coordination test needed to break down results by hand instead of just giving a total. AI couldn't do those things because they required understanding the specific purpose of Baseline and what it was supposed to measure.