Inspiration
What if the success of an AI tutor were measured not by the answer it gives, but by what the learner can do after the conversation?
Many AI tutors optimize for producing the correct answer as quickly as possible. In mathematics, however, the pause before the next step is often where learning actually happens. When AI removes that moment too early, it can make the current exercise easier without helping the learner become more independent.
ThinkFirst Tutor began with a different principle:
Think first. Ask safely. Return to independent action.
We wanted asking for help to feel safe and effortless, while ensuring that the help never replaces the learner's thinking. The tutor should respond to visible work, offer the smallest useful intervention, and then return control to the learner.
What it does
ThinkFirst Tutor is an AI tutor for learning how to solve linear equations.
Each session begins with a generated problem such as:
$$ 3(x - 2) = 18 $$
The learner writes a step, a partial solution, or the last operation they trust. Instead of immediately explaining the whole solution, the tutor diagnoses the visible attempt and chooses the smallest intervention that can unblock progress.
The first intervention is usually one Socratic question. If the learner still needs support, hints escalate gradually—from a question, to a concept cue, to one bounded worked step. The tutor does not expose hidden chain-of-thought or jump directly to the final answer.
Learners can also use low-friction help signals such as “I'm stuck,” “Check my last step,” or “Give me a small hint.” The interface makes the learning stage visible: Attempt, Diagnose, Guide, and Transfer.
Solving the original equation is not enough to complete the session. ThinkFirst Tutor generates a distinct transfer problem and asks the learner to apply the same method independently. Only successful transfer completes the learning loop.
The interface also identifies whether a response came from live GPT-5.6 or the deterministic safeguard, so the system's behavior remains understandable without reading server logs.
How we built it
I built ThinkFirst Tutor during OpenAI Build Week with Codex as my primary implementation partner, running GPT-5.6 Sol at ultra reasoning effort.
I remained responsible for the educational principles, product decisions, and evaluation of tutor behavior. I repeatedly tested the deployed application as a learner, copied problematic conversations into the development session, and explained why a response was mathematically or pedagogically wrong.
Codex helped transform those observations into engineering work: inspecting the codebase, tracing the responsible state transition, implementing bounded fixes, writing regression tests, preparing pull requests, running verification, and checking the deployed experience in a real browser.
The application uses:
- Next.js App Router, React, TypeScript, and Tailwind CSS
- GPT-5.6 through the server-side OpenAI Responses API
- Zod-backed Structured Outputs for validated tutor responses
- A deterministic pedagogical state machine and safe fallback
- Seeded equation generation for reproducible problem variants
- Vitest for policy and misconception regression tests
- Vercel for previews and the public production deployment
The browser never calls OpenAI directly. The server validates learner input, sends only the visible attempt and current tutor state to GPT-5.6, validates the structured response, and applies an additional guard before returning it to the interface. An incorrect response is rejected if it reveals the protected answer.
The deterministic policy follows the same learning stages without requiring external credentials. It supports reliable judging, explicit help signals, and safe fallback behavior when a live request is unavailable.
This was not a one-prompt build. Our working loop was:
- Test a real learner interaction.
- Identify the smallest incorrect behavior.
- Trace whether it came from validation, routing, the deterministic policy, the live model, or the interface.
- Convert the conversation into a regression test.
- Implement the correction.
- Verify the result in a preview or production deployment.
At one release checkpoint, 732 automated tests passed alongside lint, production build, and HTTP verification.
Challenges we ran into
The hardest challenge was not producing mathematically correct text. It was keeping every response pedagogically bounded.
A response can be mathematically true and still be a poor tutoring response. For example, the tutor once asked a learner to repeat a division step they had already completed. In another interaction, a valid intermediate equation was diagnosed as if it were an error. These transcripts became regression cases for the deterministic policy and presentation layer.
Generated coefficients introduced another challenge. Diagnoses and hints could not assume that every equation was still (3(x-2)=12). Every response needed to remain consistent with the current generated equation, its solution, and its transfer problem.
We also encountered a Structured Outputs integration failure: a Zod field used
.optional() in a form that the API schema did not support. The application
could see the API key and attempt live mode, but the request failed before it
reached the model. Fixing the schema restored real GPT-5.6 responses.
The interface required several iterations as well. Early versions exposed too much information at once. We moved toward a focused, chat-like flow with progressive disclosure, clearer visual attention, and explicit live-versus- deterministic provenance.
Finally, we learned not to treat a passing local build as proof that a feature was finished. Pull-request checks, preview deployments, production behavior, and browser verification all became part of the definition of done.
Accomplishments that we're proud of
- We built an attempt-first tutor rather than an answer-delivery chatbot.
- The tutor responds to the learner's actual written step.
- Hints escalate one level at a time.
- A new transfer problem is the completion gate.
- Both learner input and model output are validated at runtime.
- A protected-answer guard prevents incorrect live responses from shortcutting the exercise.
- Generated equations produce coefficient-aware diagnoses and transfer tasks.
- The deterministic path makes the complete experience testable without an API key.
- The interface clearly distinguishes live GPT-5.6 responses from safeguards.
- The complete learning journey is publicly deployed and works on desktop and mobile.
- Conversation failures were converted into automated regression tests.
Most importantly, ThinkFirst Tutor demonstrates a complete learning loop: attempt, diagnosis, guided retry, and independent transfer.
What we learned
We learned that technical correctness is not the same as pedagogical correctness. Tests must verify not only whether the software runs, but whether the tutor respects what the learner has already done and returns agency to the learner.
Exact conversation transcripts were more valuable than abstract bug reports. “Something feels wrong” became a reproducible state, a failing test, and then a bounded correction.
We also learned that live AI and deterministic software do not need to be opposites. GPT-5.6 provides flexibility when interpreting learner language, while deterministic safeguards provide reproducibility, explicit safety boundaries, and a reliable judging path.
The strongest contribution of the AI coding agent was not simply generating more code. It shortened the distance between observing a learner problem and testing a precise solution. Human judgment still determined the learning goal, the acceptable intervention, and whether the final experience was genuinely helpful.
Finally, treating independent transfer as a real product state changed the API schema, interface, test suite, and definition of completion. It became the organizing principle of the entire application.
What's next for ThinkFirst Tutor
The next step is mastery-based difficulty progression. A learner could move through a sequence such as:
$$ x - 3 = 2 $$
$$ 4x + 1 = 9 $$
$$ x - 2 = 2x + 1 $$
$$ 3(x - 2) = 18 $$
Progression would be based on demonstrated transfer, not simply on completing a fixed number of exercises.
We also want to add:
- A broader library of mathematical skills and misconception maps
- Teacher-authored learning policies and problem sequences
- Evaluation sets comparing hint helpfulness with independent transfer
- Better longitudinal evidence of which skills a learner can use without help
- Accessibility and performance measurement, including an INP baseline
- More transparent controls for teachers and researchers to inspect tutor decisions without exposing private reasoning
The Build Week MVP intentionally remains focused on one mathematical skill. The next phase is to test whether the same attempt-first, transfer-based learning contract can support a much broader curriculum.
The final demo video was assembled with Codex running GPT‑5.6 Sol from recorded application screens, narration, and synchronized captions.
For transparency, Claude Fable 5 was used once for a repository housekeeping task: creating the initial MIT LICENSE file. :-D
Built With
- codex
- css
- github
- next.js
- react
- tailwind
- typescript
- vercel
- vitest
- zod
Log in or sign up for Devpost to join the conversation.