NYU's university-wide generative AI platform — built on a fork of Open WebUI, extended with course-aware features, deployed across departments serving students, faculty, and researchers.

I joined to build AI Tutor: an intelligent system that analyzes student homework conversations, maps topic-level performance, generates personalized practice problems, and distributes them automatically.

Role: Product-aware full-stack engineer — data model, system architecture, full instructor-facing frontend, and integration documentation.

Pilot GenAI is NYU's institutional AI workspace — one platform serving students, faculty, administrators, and researchers across dozens of departments, with NYU-specific access controls and course-managed LLM access layered on top of Open WebUI.

The AI Tutor feature closes the loop between LLM-assisted learning and instructor oversight:

1. Instructor uploads a homework PDF and answer key
2. System parses the PDF, maps questions to topics, evaluates each student's conversation history against the assignment using GPT-4o
3. Instructor sees class-wide and per-student topic performance breakdowns
4. AI generates a practice problem set; instructor reviews and approves
5. System distributes personalized subsets to each student based on their specific topic gaps

When I joined, the relationship between instructors, students, assignments, conversations, and LLM models was undefined across the codebase. Different people were building different abstractions, accumulating cross-team misalignment.

I defined the canonical data model the entire product now operates on:

• Instructor = platform admin — leverages Open WebUI's existing admin role; no new role type needed
• Student = group member — maps naturally onto the existing group/membership model
• Homework = workspace model — a configured LLM model instance is the "homework object"; its chat history is the source data for analysis
• Group = context root — all instructor and student views are scoped to a group; ensures course isolation and simplifies every query

I documented and socialized this model as the shared language for frontend-backend integration, which reduced the misaligned implementations accumulating across the team.

I documented and refined the two-service architecture where AI Tutor runs as an independent microservice alongside Open WebUI:

• AI Tutor reads the Open WebUI main database read-only (users, groups, conversation history)
• AI Tutor writes to its own isolated database (analysis results, practice problems, assignments)
• The Open WebUI backend acts as a reverse proxy to AI Tutor — centralizing authentication and eliminating CORS complexity

For all long-running operations (PDF parsing, LLM analysis, practice generation), I designed a job ID polling pattern: operations return a job_id immediately and run asynchronously; the frontend polls GET /pipeline/status/{job_id} until completion; each phase — PDF → markdown → topic mapping → analysis → practice generation — is independently trackable.

I built all AI Tutor dashboard pages in SvelteKit + TypeScript: Instructor Summary, Topic Analysis, Student Analysis, Setup, and Student Dashboard with practice assignment integration. 15+ API endpoints integrated across two backend services.

I designed the group-scoped URL context pattern: group_id is always in the URL as the root context. Tab switching uses sessionStorage as a cache layer — no blank screens on rapid navigation. API failures don't clear existing UI state. A single constants.ts flag controls testing/mock mode across all AI Tutor pages.

I set up and operated the full local development stack using Docker Compose (two PostgreSQL instances, Redis, pipelines service, two FastAPI services) and port-forwarded to production OpenShift services for live testing against real NYU data.

Alongside the engineering work, I contributed to the product's visual and structural design:

• Designed the visual identity: a logo inspired by NYU torch forms, NYU palette adapted for AI-native interactions
• Helped define the group-based access model and product information architecture
• Designed and tested interaction patterns for the instructor dashboard flows
• Contributed to research sessions with instructors and students, turning workshop feedback into product requirements
• Designed testing scenarios for tutoring, file generation, and workflow automation across 20+ use cases and NYU departments

No shared data model at the start. When I read through the frontend code and backend API contracts side by side, "homework" meant a Firestore document in one place, a workspace model configuration in another, and a conversation thread in a third. Nobody had written it down. I drafted the entity mapping as a short document and sent it to the team before writing any code. That document became the de facto spec for backend API design.

The two-service architecture was real but undocumented. The sidecar pattern already existed when I joined. But there was no documentation explaining why it was that way, what the data boundaries were, or how authentication flowed across the two services. I wrote the architecture overview that answered those questions — the most referenced document for onboarding new contributors.

sessionStorage came from a real bug. Rapid tab switching in the instructor dashboard was causing blank screens. URL parameter changes triggered API calls that wiped component state before new data arrived. I added a sessionStorage cache layer: on tab switch, cached data loads instantly while the API call runs in the background; data is only replaced when the new response arrives.

Math Ally as a forcing function. Working with a Linear Algebra instructor to test the dashboard against actual homework showed exactly where the model broke: topic names were too technical to scan quickly, the student list needed sorting by weakness rather than alphabetically, and the "approve practice set" step needed a preview of what students would actually see.

NYU's university-wide generative AI platform — built on a fork of Open WebUI, extended with course-aware features, deployed across departments serving students, faculty, and researchers.

I joined to build AI Tutor: an intelligent system that analyzes student homework conversations, maps topic-level performance, generates personalized practice problems, and distributes them automatically.

Role: Product-aware full-stack engineer — data model, system architecture, full instructor-facing frontend, and integration documentation.

Pilot GenAI is NYU's institutional AI workspace — one platform serving students, faculty, administrators, and researchers across dozens of departments, with NYU-specific access controls and course-managed LLM access layered on top of Open WebUI.

The AI Tutor feature closes the loop between LLM-assisted learning and instructor oversight:

1. Instructor uploads a homework PDF and answer key
2. System parses the PDF, maps questions to topics, evaluates each student's conversation history against the assignment using GPT-4o
3. Instructor sees class-wide and per-student topic performance breakdowns
4. AI generates a practice problem set; instructor reviews and approves
5. System distributes personalized subsets to each student based on their specific topic gaps

When I joined, the relationship between instructors, students, assignments, conversations, and LLM models was undefined across the codebase. Different people were building different abstractions, accumulating cross-team misalignment.

I defined the canonical data model the entire product now operates on:

• Instructor = platform admin — leverages Open WebUI's existing admin role; no new role type needed
• Student = group member — maps naturally onto the existing group/membership model
• Homework = workspace model — a configured LLM model instance is the "homework object"; its chat history is the source data for analysis
• Group = context root — all instructor and student views are scoped to a group; ensures course isolation and simplifies every query

I documented and socialized this model as the shared language for frontend-backend integration, which reduced the misaligned implementations accumulating across the team.

I documented and refined the two-service architecture where AI Tutor runs as an independent microservice alongside Open WebUI:

• AI Tutor reads the Open WebUI main database read-only (users, groups, conversation history)
• AI Tutor writes to its own isolated database (analysis results, practice problems, assignments)
• The Open WebUI backend acts as a reverse proxy to AI Tutor — centralizing authentication and eliminating CORS complexity

For all long-running operations (PDF parsing, LLM analysis, practice generation), I designed a job ID polling pattern: operations return a job_id immediately and run asynchronously; the frontend polls GET /pipeline/status/{job_id} until completion; each phase — PDF → markdown → topic mapping → analysis → practice generation — is independently trackable.

I built all AI Tutor dashboard pages in SvelteKit + TypeScript: Instructor Summary, Topic Analysis, Student Analysis, Setup, and Student Dashboard with practice assignment integration. 15+ API endpoints integrated across two backend services.

I designed the group-scoped URL context pattern: group_id is always in the URL as the root context. Tab switching uses sessionStorage as a cache layer — no blank screens on rapid navigation. API failures don't clear existing UI state. A single constants.ts flag controls testing/mock mode across all AI Tutor pages.

I set up and operated the full local development stack using Docker Compose (two PostgreSQL instances, Redis, pipelines service, two FastAPI services) and port-forwarded to production OpenShift services for live testing against real NYU data.

Alongside the engineering work, I contributed to the product's visual and structural design:

• Designed the visual identity: a logo inspired by NYU torch forms, NYU palette adapted for AI-native interactions
• Helped define the group-based access model and product information architecture
• Designed and tested interaction patterns for the instructor dashboard flows
• Contributed to research sessions with instructors and students, turning workshop feedback into product requirements
• Designed testing scenarios for tutoring, file generation, and workflow automation across 20+ use cases and NYU departments

No shared data model at the start. When I read through the frontend code and backend API contracts side by side, "homework" meant a Firestore document in one place, a workspace model configuration in another, and a conversation thread in a third. Nobody had written it down. I drafted the entity mapping as a short document and sent it to the team before writing any code. That document became the de facto spec for backend API design.

The two-service architecture was real but undocumented. The sidecar pattern already existed when I joined. But there was no documentation explaining why it was that way, what the data boundaries were, or how authentication flowed across the two services. I wrote the architecture overview that answered those questions — the most referenced document for onboarding new contributors.

sessionStorage came from a real bug. Rapid tab switching in the instructor dashboard was causing blank screens. URL parameter changes triggered API calls that wiped component state before new data arrived. I added a sessionStorage cache layer: on tab switch, cached data loads instantly while the API call runs in the background; data is only replaced when the new response arrives.

Math Ally as a forcing function. Working with a Linear Algebra instructor to test the dashboard against actual homework showed exactly where the model broke: topic names were too technical to scan quickly, the student list needed sorting by weakness rather than alphabetically, and the "approve practice set" step needed a preview of what students would actually see.

NYU's university-wide generative AI platform — built on a fork of Open WebUI, extended with course-aware features, deployed across departments serving students, faculty, and researchers.

I joined to build AI Tutor: an intelligent system that analyzes student homework conversations, maps topic-level performance, generates personalized practice problems, and distributes them automatically.

Role: Product-aware full-stack engineer — data model, system architecture, full instructor-facing frontend, and integration documentation.

Pilot GenAI is NYU's institutional AI workspace — one platform serving students, faculty, administrators, and researchers across dozens of departments, with NYU-specific access controls and course-managed LLM access layered on top of Open WebUI.

The AI Tutor feature closes the loop between LLM-assisted learning and instructor oversight:

1. Instructor uploads a homework PDF and answer key
2. System parses the PDF, maps questions to topics, evaluates each student's conversation history against the assignment using GPT-4o
3. Instructor sees class-wide and per-student topic performance breakdowns
4. AI generates a practice problem set; instructor reviews and approves
5. System distributes personalized subsets to each student based on their specific topic gaps

When I joined, the relationship between instructors, students, assignments, conversations, and LLM models was undefined across the codebase. Different people were building different abstractions, accumulating cross-team misalignment.

I defined the canonical data model the entire product now operates on:

• Instructor = platform admin — leverages Open WebUI's existing admin role; no new role type needed
• Student = group member — maps naturally onto the existing group/membership model
• Homework = workspace model — a configured LLM model instance is the "homework object"; its chat history is the source data for analysis
• Group = context root — all instructor and student views are scoped to a group; ensures course isolation and simplifies every query

I documented and socialized this model as the shared language for frontend-backend integration, which reduced the misaligned implementations accumulating across the team.

I documented and refined the two-service architecture where AI Tutor runs as an independent microservice alongside Open WebUI:

• AI Tutor reads the Open WebUI main database read-only (users, groups, conversation history)
• AI Tutor writes to its own isolated database (analysis results, practice problems, assignments)
• The Open WebUI backend acts as a reverse proxy to AI Tutor — centralizing authentication and eliminating CORS complexity

For all long-running operations (PDF parsing, LLM analysis, practice generation), I designed a job ID polling pattern: operations return a job_id immediately and run asynchronously; the frontend polls GET /pipeline/status/{job_id} until completion; each phase — PDF → markdown → topic mapping → analysis → practice generation — is independently trackable.

I built all AI Tutor dashboard pages in SvelteKit + TypeScript: Instructor Summary, Topic Analysis, Student Analysis, Setup, and Student Dashboard with practice assignment integration. 15+ API endpoints integrated across two backend services.

I designed the group-scoped URL context pattern: group_id is always in the URL as the root context. Tab switching uses sessionStorage as a cache layer — no blank screens on rapid navigation. API failures don't clear existing UI state. A single constants.ts flag controls testing/mock mode across all AI Tutor pages.

I set up and operated the full local development stack using Docker Compose (two PostgreSQL instances, Redis, pipelines service, two FastAPI services) and port-forwarded to production OpenShift services for live testing against real NYU data.

Alongside the engineering work, I contributed to the product's visual and structural design:

• Designed the visual identity: a logo inspired by NYU torch forms, NYU palette adapted for AI-native interactions
• Helped define the group-based access model and product information architecture
• Designed and tested interaction patterns for the instructor dashboard flows
• Contributed to research sessions with instructors and students, turning workshop feedback into product requirements
• Designed testing scenarios for tutoring, file generation, and workflow automation across 20+ use cases and NYU departments

No shared data model at the start. When I read through the frontend code and backend API contracts side by side, "homework" meant a Firestore document in one place, a workspace model configuration in another, and a conversation thread in a third. Nobody had written it down. I drafted the entity mapping as a short document and sent it to the team before writing any code. That document became the de facto spec for backend API design.

The two-service architecture was real but undocumented. The sidecar pattern already existed when I joined. But there was no documentation explaining why it was that way, what the data boundaries were, or how authentication flowed across the two services. I wrote the architecture overview that answered those questions — the most referenced document for onboarding new contributors.

sessionStorage came from a real bug. Rapid tab switching in the instructor dashboard was causing blank screens. URL parameter changes triggered API calls that wiped component state before new data arrived. I added a sessionStorage cache layer: on tab switch, cached data loads instantly while the API call runs in the background; data is only replaced when the new response arrives.

Math Ally as a forcing function. Working with a Linear Algebra instructor to test the dashboard against actual homework showed exactly where the model broke: topic names were too technical to scan quickly, the student list needed sorting by weakness rather than alphabetically, and the "approve practice set" step needed a preview of what students would actually see.

NYU's university-wide generative AI platform — built on a fork of Open WebUI, extended with course-aware features, deployed across departments serving students, faculty, and researchers.

I joined to build AI Tutor: an intelligent system that analyzes student homework conversations, maps topic-level performance, generates personalized practice problems, and distributes them automatically.

Role: Product-aware full-stack engineer — data model, system architecture, full instructor-facing frontend, and integration documentation.

Pilot GenAI is NYU's institutional AI workspace — one platform serving students, faculty, administrators, and researchers across dozens of departments, with NYU-specific access controls and course-managed LLM access layered on top of Open WebUI.

The AI Tutor feature closes the loop between LLM-assisted learning and instructor oversight:

1. Instructor uploads a homework PDF and answer key
2. System parses the PDF, maps questions to topics, evaluates each student's conversation history against the assignment using GPT-4o
3. Instructor sees class-wide and per-student topic performance breakdowns
4. AI generates a practice problem set; instructor reviews and approves
5. System distributes personalized subsets to each student based on their specific topic gaps

When I joined, the relationship between instructors, students, assignments, conversations, and LLM models was undefined across the codebase. Different people were building different abstractions, accumulating cross-team misalignment.

I defined the canonical data model the entire product now operates on:

• Instructor = platform admin — leverages Open WebUI's existing admin role; no new role type needed
• Student = group member — maps naturally onto the existing group/membership model
• Homework = workspace model — a configured LLM model instance is the "homework object"; its chat history is the source data for analysis
• Group = context root — all instructor and student views are scoped to a group; ensures course isolation and simplifies every query

I documented and socialized this model as the shared language for frontend-backend integration, which reduced the misaligned implementations accumulating across the team.

I documented and refined the two-service architecture where AI Tutor runs as an independent microservice alongside Open WebUI:

• AI Tutor reads the Open WebUI main database read-only (users, groups, conversation history)
• AI Tutor writes to its own isolated database (analysis results, practice problems, assignments)
• The Open WebUI backend acts as a reverse proxy to AI Tutor — centralizing authentication and eliminating CORS complexity

For all long-running operations (PDF parsing, LLM analysis, practice generation), I designed a job ID polling pattern: operations return a job_id immediately and run asynchronously; the frontend polls GET /pipeline/status/{job_id} until completion; each phase — PDF → markdown → topic mapping → analysis → practice generation — is independently trackable.

I built all AI Tutor dashboard pages in SvelteKit + TypeScript: Instructor Summary, Topic Analysis, Student Analysis, Setup, and Student Dashboard with practice assignment integration. 15+ API endpoints integrated across two backend services.

I designed the group-scoped URL context pattern: group_id is always in the URL as the root context. Tab switching uses sessionStorage as a cache layer — no blank screens on rapid navigation. API failures don't clear existing UI state. A single constants.ts flag controls testing/mock mode across all AI Tutor pages.

I set up and operated the full local development stack using Docker Compose (two PostgreSQL instances, Redis, pipelines service, two FastAPI services) and port-forwarded to production OpenShift services for live testing against real NYU data.

Alongside the engineering work, I contributed to the product's visual and structural design:

• Designed the visual identity: a logo inspired by NYU torch forms, NYU palette adapted for AI-native interactions
• Helped define the group-based access model and product information architecture
• Designed and tested interaction patterns for the instructor dashboard flows
• Contributed to research sessions with instructors and students, turning workshop feedback into product requirements
• Designed testing scenarios for tutoring, file generation, and workflow automation across 20+ use cases and NYU departments

No shared data model at the start. When I read through the frontend code and backend API contracts side by side, "homework" meant a Firestore document in one place, a workspace model configuration in another, and a conversation thread in a third. Nobody had written it down. I drafted the entity mapping as a short document and sent it to the team before writing any code. That document became the de facto spec for backend API design.

The two-service architecture was real but undocumented. The sidecar pattern already existed when I joined. But there was no documentation explaining why it was that way, what the data boundaries were, or how authentication flowed across the two services. I wrote the architecture overview that answered those questions — the most referenced document for onboarding new contributors.

sessionStorage came from a real bug. Rapid tab switching in the instructor dashboard was causing blank screens. URL parameter changes triggered API calls that wiped component state before new data arrived. I added a sessionStorage cache layer: on tab switch, cached data loads instantly while the API call runs in the background; data is only replaced when the new response arrives.

Math Ally as a forcing function. Working with a Linear Algebra instructor to test the dashboard against actual homework showed exactly where the model broke: topic names were too technical to scan quickly, the student list needed sorting by weakness rather than alphabetically, and the "approve practice set" step needed a preview of what students would actually see.