Forem: Jing

LearnMateAI: Building an Intelligent Teaching Assistant Platform

Jing — Tue, 21 Apr 2026 06:10:39 +0000

LearnMateAI Jing Ng & Liuyi · Spring 2026

LearnMateAI: Building an Intelligent Teaching Assistant Platform

LearnMateAI: Making Online Learning Better

The Problem

Online education today is boring. Students scroll through endless PDFs and read flat text. Teachers don't see what students are actually learning—they only find out when they grade hundreds of assignments. It's like there's a wall between teaching and learning. Plus, students need real feedback fast, not days later.

The Solution

LearnMateAI fixes this. It's a smart app that helps both instructors and students:

For Instructors: A live dashboard shows exactly where the class is struggling. You can see patterns in mistakes across all students without invading anyone's privacy. It's like having radar for class confusion.

For Students: You get interactive flashcards that flip in 3D, quizzes that adapt to your speed, and instant feedback from an AI tutor. It's like having a personal teaching assistant grade your work while you're still thinking about it.

How We Built It: Two People, Two Jobs

We split the work so we could code without getting in each other's way.

Jing's Part (Backend):

Set up the server that handles all the data
Built the database that stores courses, students, and quizzes
Created the AI agents that generate study materials
Wrote strict tests to make sure the AI output is correct every time

Liuyi's Part (Frontend):

Built the interface students see
Built the interface instructors see
Made the 3D flashcards and quiz experience feel smooth and fun
Tested the whole system end-to-end

How We Used AI: Two Different Ways

Claude Web Chat — We used this for big-picture thinking:

Designing what the database should look like
Planning our testing strategy
Sketching out how the interface should flow

Antigravity & Claude Code (Terminal) — We used this for actual coding:

Writing and testing code in the IDE
Making sure the AI outputs are reliable
Preventing the AI from making stuff up (hallucinating)

The split was clean: Claude Web for strategy, Terminal Claude for execution.

Part 1: The Foundation

Authentication (Logging In Safely)

The app treats instructors and students completely differently. Once you log in, the system instantly knows what you can and can't see. Students can't peek at teacher dashboards. Teachers can't see individual student passwords. Everything is locked down.

Database Design

We designed the database to store:

User accounts (name, email, role)
Courses and modules
Student quiz submissions and scores
Learning goals for each module

The key insight: We store individual student data separately from class-wide statistics. This way, a teacher can see "the class average on this question is 62%" without knowing which student got it wrong.

Teacher Control: "Audience Customization"

Before the AI generates anything (quiz, flashcard, summary), the teacher sets an "audience profile." This tells the AI who it's writing for. For example:

"High school biology, age 14-15"
"No religious references"
"Use analogies from sports"

This prevents the AI from making weird or inappropriate content.

The Real-Time Dashboard

Instead of showing numbers in a boring table, we built a live dashboard that updates as students submit quizzes. It shows:

Where the class is strongest
Where the class is struggling most
How fast students are improving

The teacher can see this instantly and adjust their next lesson.

Part 2: The Brain (AI Features)

The AI Agents

We built three AI "workers" that each do one job:

Summary Agent — Reads the course material and writes a short study guide
Flashcard Agent — Creates question-and-answer pairs from the material
Quiz Agent — Generates multiple-choice and essay questions

These agents don't just output raw text. They output structured data (JSON) that the app can use immediately.

Keeping AI Honest: Testing

AI can make things up. So we force every AI output through tests before it gets used:

Does the JSON look right?
Are there enough questions?
Is the answer actually in the source material?

If any test fails, the AI tries again. We even set up Git hooks that prevent code changes if tests are broken.

Cool UI: 3D Flashcards & Smart Quizzes

Instead of just showing text, we made:

3D Flashcards — Flip them over with a realistic 3D animation
Smart Quizzes — One question at a time. When you submit, the AI instantly tells you why you got it wrong (not just "that's incorrect")

Part 3: Quality & Testing

Automated Testing Pipeline (CI/CD)

Every time someone pushes code:

Tests run (Pytest for backend, Vitest for frontend)
The code is scanned for bugs (linting)
Browser tests run automatically (Playwright)
Security checks run (scan for passwords accidentally committed)
The app deploys automatically to the live server

All 9 stages run in parallel. If any stage fails, the deployment stops.

Checking if AI Is Good

When the AI generates a quiz, we ask another AI: "Is this a good quiz?" It scores it on:

Is it related to the lesson?
Is it clear and understandable?
Did the AI make up false information?

We track these scores over time to see if our AI is getting better or worse.

Part 4: How We Actually Used AI (The Workflow That Worked)

How MCP Solved the Context Problem

The biggest waste of time with traditional AI tools is copy-pasting. You paste your database schema into chat. Then your API routes. Then your data models. Back and forth, over and over.

We solved this with MCP (Model Context Protocol). It's a configuration file that lets Claude Code read our project files automatically. Claude could see our database structure, our API routes, and our data models without us having to explain them.

When we asked Claude Code to build the teacher dashboard API, it already knew our database setup. It wrote correct code immediately. This cut our bugs and back-and-forth by about 70%.

Git Hooks: Stopping Bad Code Before It Happens

AI can make mistakes. Code might have bugs, or data might be formatted wrong. We didn't want broken code in our main branch.

So we set up Git hooks. When Claude Code finished writing code, the system automatically ran all tests. If any test failed, the code couldn't be saved. Claude had to read the error message and fix it. This forced Claude to debug itself until everything passed.

We never once merged broken code to main.

The Workflow Pattern That Worked

Instead of just saying "write code," we created a repeatable process: Explore → Plan → Implement → Commit

Here's what that means:

Explore: Claude searches through our project files to understand the structure
Plan: Claude writes out the steps before writing any code
Implement: Claude writes the actual code
Commit: Claude saves the work with clear messages about what changed

This meant Claude Code wasn't just guessing. It followed the same workflow every time, which made the code better and more predictable.

Two Different AI Jobs

We used Claude in two completely different ways:

Claude Web (the browser) handled big-picture thinking: database design, testing strategy, interface wireframes. We didn't need to be super technical with it.

Claude Code (the terminal) handled actual coding: writing functions, running tests, debugging. It worked inside our IDE with access to our actual files.

This separation was crucial. The browser Claude didn't need every detail. The terminal Claude focused only on writing and testing. When you split the work like this, both tools get better at their specific jobs.

Lessons Learned

The biggest one: AI doesn't fix bad architecture. If your database design is messy, or your tests are weak, AI code will be messy too. We won the game by building strong foundations first, then using AI to fill in the details.

The key insight: Don't use AI like a chatbot. Use it like a tool in your development pipeline. When you give it clear context (MCP), a repeatable process (the Explore → Plan → Implement → Commit pattern), and automatic quality checks (Git hooks), AI can move incredibly fast while staying reliable.

For a two-person team, this made the difference between a 12-week project being impossible and being doable.

Tech Used

Frontend: React, Vite, Tailwind CSS
Backend: FastAPI, Python
Database: PostgreSQL
AI: Claude API with structured outputs
Hosting: Vercel (frontend), Render (backend)

Links

Code: https://github.com/MelanieLLY/LearnMateAI
Live App: https://learn-mate-ai-zeta.vercel.app
API: https://learnmate-api.onrender.com

Key Features

✅ Teachers see live class confusion radar (no privacy invasion)
✅ Students get AI tutors that give instant feedback
✅ 3D interactive flashcards and quizzes
✅ AI-generated study materials tested for accuracy
✅ Automatic testing pipeline for every code change

SkillGap: Building an AI-Powered Career Assistant

Jing — Fri, 13 Mar 2026 22:09:56 +0000

SkillGap: Building an AI-Powered Career Assistant

Jing Ng & Liuyi · Spring 2026

Introduction: The Vision of SkillGap

The Problem

Job descriptions are hard to read. They are long, full of buzzwords, and it is genuinely difficult to know if you qualify. Most people either talk themselves out of jobs they could get, or apply to roles they are not ready for.

There is no quick, honest way to compare your skills to what a job actually needs. That is the problem we wanted to solve.

The Solution

SkillGap does the comparison for you. Paste a job description into the app. It checks it against your saved skill profile and gives you a match score, a breakdown of your skills into three groups (Have / Missing / Bonus), and a personalized AI learning roadmap.

You get a clear, actionable plan instead of a guess. As you learn and update your profile, your results improve too.

A Two-Person, Two-Tier Approach

We divided the work so both of us could build at the same time without conflicts.

Jing built the foundation: JWT authentication, skill profile CRUD, the keyword extraction engine, and the animated match ring.

Liuyi built the smarter layer: Claude API integration for the learning roadmap, the TDD testing framework, framer-motion UI animations, Skeleton UI loading states, and the AI evaluation suite.

Two Ways We Used AI

We used two AI tools in different roles throughout the project.

Claude Web handled planning and artifacts. Jing used it to turn early ideas into a prioritized plan. Liuyi used it to convert a hand-drawn wireframe into a proper UI reference, and later to generate the evaluation results webpage from real test data.

Antigravity handled coding inside the IDE. Both of us used it to write, refactor, and debug code across the frontend and backend.

The split was simple: Claude Web for planning, Antigravity for building.

Part I: The Foundation: Building the Core

JWT Authentication and User Accounts

Everything in SkillGap depends on knowing who the user is. We built JWT-based authentication first: signup, login, logout, and protected routes that reject unauthenticated requests at the API boundary.

Passwords are salted and hashed before they reach the database. JWT tokens are validated on every protected request. We built this first because every other feature depends on it.

On top of auth, we built full CRUD operations for the skill profile. Users can add, edit, and delete skills at any time. Changes persist immediately, so every new analysis uses the latest version of the profile.

Data Modeling with SQLAlchemy

We designed the SQLAlchemy schema to support the full app from the start. The core tables cover users, skill profiles, and analysis history. The history table lets users look back at past analyses and track how their match scores improve over time.

We used Alembic for migrations. Any schema change is a migration file that can be reviewed, tested, and rolled back cleanly instead of a risky manual database edit.

The Keyword Extraction Engine

This is the core algorithm of the product. The engine takes a job description and a user's skill profile, compares both against a curated list of tech skills, and produces three outputs: skills the user has that the job wants, skills the job wants that the user does not have, and bonus skills the user brings that the job did not ask for.

The matching uses keyword normalization so common variations map to the same skill. "React," "ReactJS," and "React.js" all resolve to the same entry. The vocabulary covers frontend, backend, infrastructure, and data tools.

The engine lives in its own module, separate from the auth and profile modules. That made it straightforward to unit test in isolation and easy to extend later.

The Animated Match Ring

A raw percentage is hard to read at a glance. We built an animated SVG ring that shows the match score visually: green for a strong match, yellow for partial, red for a significant gap. The ring draws progressively on page load so the result feels like it is being calculated rather than just appearing.

Below the ring, the three-column view shows the exact skills behind the score so users can see what drove the number.

Claude Web for Early Product Definition

Before writing any code, Jing used Claude Web to work through the project design in plain language. The conversations helped pin down the core user flow, figure out which features to build first, and surface questions that the PRD did not answer yet. For example, what should the app do when a job description mentions a skill that is not in the curated list? What should a new user see before they have set up a profile?

Getting those decisions made before touching the code saved significant debugging time later.

Part II: The Brain: AI and Engineering

Claude API Integration for Learning Roadmaps

The extraction engine tells you what skills you are missing. The Claude API tells you what to do about it.

After the engine produces a list of missing skills, the FastAPI backend sends those skills and the original job description to the Claude API. Claude returns a structured JSON roadmap. Each step in the roadmap has a skill focus, recommended resources, estimated time, and a short explanation of why that skill appears at that point in the sequence.

The React frontend parses the JSON and renders it as a row of cards, one per topic, so the plan is easy to read and act on. It is not a generic list of links. It is a personalized, ordered plan built around what the specific job needs.

TDD for the Engine, AI Evaluation for the Roadmap

AI features are harder to test than deterministic code because the output changes every time. We handled the two parts with different approaches.

For the extraction engine, we used strict TDD. Tests were written before any implementation code. Every module in server/tests/ has a corresponding test_<module_name>.py file, and the CI pipeline blocks any merge that drops pytest coverage below 80%.

For the Claude roadmap, we built an AI Assessment Test Suite that scores each response on three dimensions: Relevance (do the resources match the missing skill?), Specificity (does it give concrete next steps rather than vague advice?), and Completeness (does it cover every missing skill?). These scores feed into the eval dashboard.

Backend Security

Two security issues came up during development that were not in the original plan.

The first was client-side score spoofing. The match score was being calculated on the React frontend and sent to the FastAPI backend for storage, which meant a user could manipulate the value before it was saved. We moved the calculation entirely to the server so any client-provided score is ignored.

The second was unhandled SQLAlchemy exceptions. Database errors were returning 500 responses that included full stack traces, which exposes internal implementation details. We added a global error handler that logs the full detail server-side and returns a clean, safe error message to the client.

Both issues were caught in code review before they reached production.

UI Polish with framer-motion and Skeleton UI

We did a focused UI pass to make the app feel responsive, especially during the Claude API call which takes a few seconds.

We used framer-motion to add staggered animations to the skill columns and roadmap cards. Results animate in one after another rather than all appearing at once, which makes the page feel like it is presenting information rather than dumping it.

While the Claude API call is in flight, the results panel shows a Skeleton UI placeholder that matches the shape of the real content. Users see the layout of what is coming instead of a blank screen, which makes the wait feel much shorter.

Wireframe to Production: Liuyi's UI Workflow

Liuyi started with a hand-drawn sketch of the dashboard layout. That sketch went into Claude Web, which generated a detailed wireframe with component suggestions and layout reasoning. The wireframe became the design spec for the production implementation, which was then built with Antigravity inside the IDE.

The workflow was: sketch to Claude Web wireframe to production build. Having a concrete reference before writing any React code meant fewer design guesses and fewer rewrites.

Part III: Quality and Evaluation

CI/CD with GitHub Actions

Every pull request goes through a multi-stage GitHub Actions pipeline before it can merge: lint (ruff and ESLint), security scan, pytest, and build. The coverage check is a hard gate. If backend coverage drops below 80%, the pipeline fails and the PR is blocked.

No secrets live in the codebase. API keys, JWT secrets, and database connection strings are stored in GitHub Secrets and injected at runtime. The app deploys to Render automatically when a PR merges to main.

The pipeline enforces the quality standards that are easy to skip when they only live in a document. A rule wired into CI runs every single time.

AI-as-a-Judge Evaluation

To evaluate the roadmaps Claude generates, we used a second AI call as the judge. After Claude produces a roadmap, a batch evaluation job sends that roadmap plus the original missing skills and job description to an LLM evaluator. The evaluator scores the response on Relevance, Specificity, and Completeness using a fixed rubric.

Using AI to evaluate AI output is the practical approach for testing non-deterministic results at scale. It does not replace human review, but it makes it possible to run evaluations across many test cases and get consistent, structured scores that can be tracked over time.

The Evaluation Webpage Artifact

Liuyi ran the full evaluation suite on real test data and passed the results into Claude Web. Claude Web generated an evaluation webpage artifact: a clean, readable summary of all the scores with notes explaining what drove the high and low marks.

The page served two purposes. It gave us a concrete quality signal on the Claude API integration. And it produced shareable documentation that shows exactly how the AI output was measured and what the results were.

Conclusion

Efficiency Gains from an AI-First Workflow

Using Claude Web for planning and Antigravity for implementation made the whole development process significantly faster. The biggest gains came from two places: early planning conversations that cleared up ambiguity before any code was written, and in-IDE acceleration that handled boilerplate and caught errors during implementation rather than after.

Why the Two AI Roles Needed to Stay Separate

Claude Web is a conversation. It works well for open-ended thinking, generating artifacts, and working through decisions that are not well-defined yet. Antigravity operates directly on your files. It works well for writing, refactoring, and debugging real code.

Mixing the two roles would have been slower. Copying code from a chat window into a file adds friction. Using a conversational tool for planning loses the iterative loop that surfaces better decisions. Keeping each tool in its role made both more effective.

Future Roadmap

The most valuable technical upgrade from here would be replacing keyword extraction with sentence-transformer embeddings for semantic skill matching. The current engine only matches exact keywords. It cannot recognize that "component-based UI development" means React. Semantic matching would make the app useful for a much wider range of job descriptions, including ones written in plain English rather than keyword lists.

Other ideas include resume parsing so users can build their skill profile from an uploaded document, and a reverse analysis mode where an employer checks a candidate's profile against a job posting.

Final Thoughts

SkillGap started as a class project and became something we are proud to show. The modular architecture meant both of us could work independently without stepping on each other's code. A shared .antigravityrules file meant we agreed on conventions before they became conflicts. And splitting AI responsibilities cleanly between planning and building gave us speed without losing control of the output quality.

The biggest thing we learned: AI tools make a good engineering process faster. They do not replace the need for one.

Tech Stack Skill Gap Analyzer · Jing Ng & Liuyi · Spring 2026

MelanieLLY / SkillGap

SkillGap — Tech Stack Skill Gap Analyzer

A web app that helps job seekers identify skill gaps from job descriptions Paste a JD, see your match score, and get an AI-generated learning roadmap.

Team 7: Jing Ng · Liuyi Yang

Project links

GitHub repository link: https://github.com/MelanieLLY/SkillGap
Frontend production URL: https://skillgapweb.netlify.app
Backend API base URL (optional): https://skillgap-api-hrsc.onrender.com
Eval Dashboard document link or repo path:
- docs/skillgap_eval_dashboard.html or docs/skillgap_eval_dashboard.pdf if prefer pdf.
- docs/eval_roadmaps/ai_eval_results.pdf
Blog post link:
- Jing: https://dev.to/jing_2026/skillgap-building-an-ai-powered-career-assistant-2985
- Liuyi: https://www.melanieyang.info/post/skillgap-building-an-ai-powered-career-assistant
Video link: https://youtu.be/MdN4UXqrERU
Relative paths for key documentation package artifacts: docs/

Tech Stack

Frontend: React 18, TypeScript, Vite, Tailwind CSS, Zustand
Backend: FastAPI, Python 3.11, SQLAlchemy, PostgreSQL
AI: Claude API (claude-sonnet-4-20250514)

Features

Screenshots

Login page

Sign up page

Profile Setup Page

Main Dashboard - Skill Match Analysis

System Architecture

Request flow when user submits a job description

The user pastes a job description, our server compares it against their saved skill profile, calculates…

View on GitHub