Project Info
Inspiration
In high school, we took a calculus class with a teacher named Ms. Collins, and we struggled. Not the kind of struggle you fix with pure hard work and grit, but the kind where the class moves on, and you quietly fall further behind every week. What made Ms. Collins different is that she took time out of class and, based on daily quizzes, she would then match students into groups based on what they struggled with on the quiz, and had the students do problems together for the rest of class, then step in to interact with each mini group. She would never treat the class as one group moving at one speed. She figured out exactly what level each student was at, met us there, and never gave us the answer, only stopping by and giving well-placed hints to let us find the answer ourselves. She changed what learning felt like for us, and she made us want to turn around and help others teach the way she taught us. When this hackathon started, we read that students across the world are still performing below pre-pandemic levels. That statistic hit us hard, because we knew what being behind feels like from the inside, and we knew what it took to get out: not more content, but a teacher who could see precisely where we were stuck and respond to that. Most students will never get a Ms. Collins. This felt like the moment to take the imprint she left on us and build it into something anyone, anywhere, could use. That's why we built Rung, a differentiated-instruction platform that does what she did: find the exact rung each learner is standing on, and help them take the next one.
What it does
The teacher sets up a digital classroom for students, and when students join, they must take a short diagnostic. After students have taken it, based on the results, Rung builds a separate focused practice plan for every skill that needs work. When they get stuck, an AI tutor offers three escalating levels of help: a nudge, a hint, and a guided step, but never the answer, because Ms. Collins never just gave us the answer either. On the other side, teachers get a live heatmap of exactly where each student stands, one-click actions from that evidence, and AI-drafted mini-lessons for small groups who share the same gap that include YouTube videos that the students can watch for guidance.
How we built it
We built Rung on Next.js, Supabase, and GPT 5.6. We drew a clear line between what GPT helps with and what the app decides itself. GPT helps with explanations, tutoring students through a problem, creating practice sets, and crafting lessons for teachers. The app handles answer scoring, skill updating, and group formation. Before writing any code, we created our features list and crafted architecture.md and contracts.md so we had clear guidance for Codex to build the data flow and UI. This made it much easier to efficiently implement each feature, make modifications where necessary, and verify the functionality of the app. We validated model outputs before showing them, prevented any answer leaks in hints, and used safe fallbacks when the model failed to provide valid input. Before pushing a new feature, we iterated on our test cases to ensure functionality was preserved, growing our test suite up to 230 tests across 36 files.
Challenges we ran into
The hardest challenge was preventing AI from being used to shortcut learning. We did not want a tutor that simply reveals an answer after one wrong attempt. The hint flow needed to progress from a small nudge to a more direct hint to one actionable guided step, while still leaving the student to do the actual problem. Generated practice created a similar challenge. Early outputs could be malformed, target the wrong kind of problem, repeat an item, or use math parameters that did not make sense. We solved that by limiting what the model can return. It only proposes structured problem parameters; server code validates those parameters, rejects anything outside the supported formats, and then constructs the prompt, number-line visual, and answer rule itself. The model never supplies the answer key. Moreover, we built fallback behavior for every AI feature so the core student and teacher experience still works if an API key, model call, or network request is unavailable. Lastly, we ran into quite a few UI edge cases that Codex did not flag and were only seen through the app itself. This made us much more intentional about manually testing each flow after implementation. We had to verify loading states, ensure the application acts differently when within a workspace versus sample data, and provide stylistic updates to better structure the UI.
What we learned
We learned that great teaching is an algorithm and a heart, and software can only carry the first part, so it had better carry it faithfully. Practically, we learned that writing precise specs up front is the single biggest multiplier when building with AI; that the right question isn't "what can the model do?" but "what should the model never do?"; and that deterministic guarantees are what turn an impressive demo into something a real teacher could trust. Mostly, though, we learned that the way one teacher made us feel in a calculus classroom could be translated into product decisions: diagnose precisely, meet learners where they are, hint before you tell, and always show them the next rung. Ms. Collins did that for one classroom. Rung is our attempt to do it for every student the pandemic left behind.
Rung
Rung is a differentiated-instruction prototype for middle-school math. A learner takes a short check-in, receives a separate AI-assisted focused-practice plan for each skill that needs work, and gets answer-safe AI support. Teachers can view evidence in a heatmap, take a quick action, and open an AI-assisted small-group mini-lesson.
Correctness, scoring, and mastery are deterministic server decisions. GPT-5.6 helps with bounded explanation, tutoring, practice planning, and lesson drafting; it never decides whether an answer is correct or whether a learner has mastered a skill.
What judges should try
Student flow
- Visit
/demo, enter any name, and start the five-question check-in. - Finish the check-in. Rung creates one selectable practice plan for each skill that was not mastered; completed plans remain marked when you return.
- In a plan, submit one wrong answer. Use the three tutor levels—nudge, hint, and guided step—and then submit again.
- Finish the plan and open the practice summary. It shows correct answers, first-try successes, total attempts, retries, and the questions that needed another try without revealing answer keys.
- Use Plan, My Work, and Progress in the student header. Plan returns to the current class’s assigned practice sets; My Work shows completed evidence; Progress shows the current skill climb.
Example learner name: Alex.
Teacher flow
- Visit
/teacher-workspaceand create a workspace with any teacher/class name. - Copy its join code or link; open it in an incognito window or separate browser profile. Join as a learner and complete the check-in. For a suggested group, have two learners miss the same skill.
- Return to the teacher workspace. The heatmap is based on those workspace learners and their stored evidence, not the fictional sample class.
- Hover a
Needs supportorDevelopingcell and choose Assign 3Q. Return to that learner, refresh, then open Plan to find the assignment under From your teacher. - Open Mini Lesson from a suggested group (or a
Needs supportcell). The route displays the workspace group, an AI-assisted 15–20 minute lesson, validated AI-generated matched practice, and a vetted skill-aligned video. Not startedoffers a one-time reminder.Masteredis informational only.
Example teacher/class: Ms. Jordan, Period 3 fractions.
The fixed fictional sample heatmap is also available at /teacher/dashboard.
How we used Codex and GPT-5.6
Codex accelerated the project from scaffold through polished demo: it helped establish the Next.js structure, implement API routes and student/teacher flows, refine UI interactions, resolve merges, add tests, and maintain the project documentation. We directed and reviewed the product decisions throughout. We kept a running log of the work in CODEX_LOG.md and IMPLEMENTATION_LOG.md.
Our approach was to figure out what GPT-5.6 is actually good at and hand it that work, instead of just prompting it for whatever came next.
It's at its best when the target is precisely specified. So we wrote architecture.md and contracts.md ourselves, and had Codex freeze the typed contracts, seed IDs, and fallback shapes before any feature work started. When the contract was locked, Codex was fast and rarely wrong. When it was vague, we lost the time savings to re-review. Writing the spec up front was the biggest speedup of the whole project, and it also let us run Codex sessions on the server logic, the AI layer, and the student UI in parallel without them stepping on each other.
It's also better than us at precision-heavy code. Exact fraction arithmetic, database migrations, schema changes: the kind of code where a small mistake shows up weeks later as a blank dashboard with no error message. Codex wrote all of it, and caught at least one of those silent failures before it shipped.
It's good at reading everything. When a tester hit a bug we were sure was caching, Codex traced the whole data path and found the actual cause, which was somewhere none of us had looked. It even found and fixed a leak that its own fix introduced. Before the demo we also pointed a GPT-5.6 Sol review at the codebase, and it flagged the seams most likely to break live; we had Codex fix them. And it wrote tests right after implementing each behavior, which is exactly the point where we would have skipped them. The suite ended at 219 tests across 35 files, and we didn't accept a session's output until types, tests, and a production build passed.
That same strength made working as a team easier. We split the project across parallel tracks, so each of us regularly had to pick up code the other had written days earlier. Instead of reading a big merge cold, we'd have Codex walk through what actually changed and how it connected to the contracts before touching anything near it. At one point a 65-file, nine-migration chunk of work landed without a log entry; Codex reconstructed what it did from the migrations and source, wrote the missing log entry after the fact, and flagged a stale function overload the commit had left behind. Catching up on your partner's work went from an afternoon of reading to a short conversation.
We also matched the model variant to the job: Luna for high-volume runtime calls like tutor hints, Terra available for heavier drafts like diagnosis explanations and teacher lessons, and Sol for the code review.
What it's not good at is judgment, so the product decisions stayed with us:
- Keep learning decisions deterministic; the model is never the grader.
- Generate practice only through supported, validated problem formats with server-derived answers.
- Make tutoring progressive and answer-safe rather than providing completed solutions.
- Give teachers immediate actions from evidence, then connect shared gaps to a practical mini-lesson.
- Keep the public walkthrough structurally separate from a teacher workspace's learner evidence.
The running app follows the same idea: GPT-5.6 does the language and planning, deterministic server code decides everything that matters. Its outputs are validated, cached when appropriate, rate-limited, and replaced by safe fallbacks if an API key, network call, or schema check is unavailable.
How the AI is used
- GPT-5.6: diagnosis language, nudge/hint/guided-step tutoring, validated student and teacher matched-practice parameters, and mini-lesson drafts.
- Deterministic server code: answer scoring, mastery updates, practice progression, group membership, and answer-format validation.
- Safety boundary: model outputs are schema-validated and answer-leak checked before display. Generated practice is reconstructed and scored from server-derived math data.
- Caching: validated teacher lessons, matched practice, and other eligible AI results are stored in
ai_runs; reopening the same plan uses the cache rather than making another OpenAI call.
Local setup
Prerequisites
- Node.js 20 or later
- npm
- Optional: OpenAI API key for live model responses
- Optional locally, required for a durable/shared demo: a Supabase project
npm install
cp .env.example .env.local
npm run dev
Open http://localhost:3000.
The local walkthrough works with DEMO_MODE=true and deterministic fallbacks. It uses process memory, so restarting the server resets local learner and workspace state.
Environment variables
| Variable | Needed for | Purpose |
|---|---|---|
DEMO_MODE=true | Local demo | Enables temporary learner and teacher-workspace flows. |
OPENAI_API_KEY | Live AI | Enables live GPT-5.6 calls; without it, typed safe fallbacks keep the demo usable. |
NEXT_PUBLIC_SUPABASE_URL | Durable/shared data | Supabase project URL. |
NEXT_PUBLIC_SUPABASE_ANON_KEY | Durable/shared data | Supabase public anon key. |
SUPABASE_SERVICE_ROLE_KEY | Durable/shared data | Server-only Supabase service-role key. Never expose this in browser code. |
ALLOW_DEMO_IN_PROD=true | Explicit fictional hosted demo only | Second opt-in alongside DEMO_MODE=true; never use it for real students. |
Model overrides and cache configuration are documented in .env.example. The committed default model is gpt-5.6-luna; local environment values override it only on your machine.
Optional Supabase seed
For durable learner/workspace data, set the three Supabase variables above, apply every migration in supabase/migrations/ (001–024) in filename order, then run:
npm run seed
This loads the fictional curriculum and sample teacher heatmap and clears temporary demo/runtime data.
Sample data and access
- No passwords or pre-created accounts are required.
- The public demo and teacher workspace both create temporary, cookie-bound identities from the names you enter.
- All names and curriculum data are fictional.
- A temporary session lasts about eight hours. In the same browser profile, a new tab resumes the same learner; incognito/another browser starts a new learner.
Tests
npm test
npx tsc --noEmit
npm run build
The production build, TypeScript check, and focused demo/workspace tests pass in the current workspace (230 tests across 36 files at the latest validation).
Known limitations
- The implemented curriculum is currently fractions, even though the product pattern could extend further.
- Teacher workspaces are fictional temporary demo sessions, not production classroom accounts.
- Production sign-in/onboarding and real teacher authorization are not implemented.
- The current live-AI limiter is process-local; a production multi-instance rollout should use a shared store.
For deeper implementation detail, see architecture.md, contracts.md, and IMPLEMENTATION_LOG.md.
Analysis
View
Metric
- 26
- 18
- 1
Figures cover GitHub contributors during the hackathon window. A co-authored commit counts in full for each author, so per-member totals add up to more than the whole-team figures.
Technology
- CSSIn code
- Next.jsIn code
- OpenAIIn code
- ReactIn code
- SQLIn code
- SupabaseIn code
- Tailwind CSSIn code
- TypeScriptIn code
- PostgreSQLClaimed
8 of 9 appear in the indexed code. 1 claimed on Devpost could not be matched to code, which may simply mean the tool leaves no trace in the repository.
AI coding agents
No AI coding agent signals were found in this repository.
Detected from committed agent config files and commit authorship. Absence of a signal is not proof an agent was unused.
Codebase size
Source size
1.2 MB
Source files
203
Counts recognized source files only; vendored directories, binaries and lockfiles are excluded, so this is smaller than the repository on disk.
Repository
Sravik-Sajja/rung
211 files · 1.3 MB · @ 4cbc9f1
Structure
Interface
63 files · 30%Screens, components and styles rendered to the user.
API & routing
20 files · 9%Request entry points: routes, handlers and controllers.
Application logic
40 files · 19%Domain rules, services and shared utilities.
Data & schema
36 files · 17%Schema definitions, migrations and data access.
Supporting
Layers are inferred from where files sit in the tree, not from reading the code. A project that names its directories unconventionally will read oddly here — open the file browser to check anything the diagram implies.
Languages
- TypeScript73%
- Markdown15%
- SQL12%
- CSS1%
Share of indexed source by file size. Binary and vendored files are excluded.
Dependencies
package.json
npm · 15- @supabase/supabase-js
- @vercel/analytics
- next
- openai
- react
- react-dom
- zod
- +8 more
Declared in the repository’s manifests at the indexed commit. A declared package is not proof it is used, and runtime dependencies are listed first.
This project’s features have not been analysed yet.
Export this project's context (description, README, evidence, key source files) to chat with an AI agent elsewhere.