Inspiration

Most AI tutoring tools work the same way regardless of who's using them: they explain a concept, and if you're still confused, they explain it again in roughly the same way. But that's not how people actually learn something unfamiliar. We understand new things by connecting them to things we already know, that's the whole idea behind the Feynman technique. I wanted to build something that used that principle directly instead of just wrapping a chatbot around a textbook definition.

What it does

Bridge asks for two things: a concept you're stuck on, and something you already understand well. It then:

Generates a specific, concrete analogy mapping the new concept onto your known domain
Asks one diagnostic quiz question designed to test whether you understood the actual mechanism, not just whether you can repeat a definition
If you get it right, it confirms exactly what you understood
If you get it wrong, it identifies the specific misconception your wrong answer reveals, and rebuilds the explanation using a different angle within the same known domain, then asks a new question

That loop, explain, check, diagnose, adapt, repeats until the concept actually lands, instead of stopping at a single explanation.

How we built it

Next.js (App Router) and TypeScript, deployed on Vercel
GPT-4o-mini for both the analogy generation and the diagnostic reasoning, using structured JSON output so the explain/quiz/diagnose steps stay predictable rather than freeform chat
Tailwind CSS for styling, framer-motion for the transition and animation layer
No database for this MVP, session state lives in React; a Supabase layer to persist bridge history across sessions is a natural next step

The prompt design was the real engineering work here. The diagnose step in particular needed to name the specific misconception behind a wrong answer, not just say "incorrect", and then generate a genuinely different analogy rather than a reworded version of the first one.

Challenges we ran into

A Windows-specific networking bug: the OpenAI SDK's gzip-decompressed responses kept getting cut off mid-stream (ERR_STREAM_PREMATURE_CLOSE), traced to network-level interference (antivirus/TLS inspection) rather than the code itself. Fixed by requesting uncompressed responses directly from the client.
Keeping the AI honest on "different angle." Early versions of the diagnose prompt sometimes just repeated the first analogy with slightly different words. Solved by explicitly excluding prior angles and requiring the new analogy to target the specific misconception identified.
Scoping for a solo 10-day build. The temptation was to add accounts, saved history, multiple question types. Instead I kept the loop to one clean mechanic and spent the remaining time on prompt quality and the visual identity, since a smaller thing done well demos better than a bigger thing done roughly.

What we learned

That the hardest part of an "AI education" product isn't the AI call, it's designing the loop around it so the model's output is structured, diagnostic, and self-correcting rather than just conversational. A single well-designed feedback loop does more for learning than a broader feature set.

What's next

Persisting bridge history across sessions (Supabase)
Letting users pick difficulty or depth for the diagnostic question
Expanding beyond multiple-choice into short free-text answers, checked by the same diagnose step