AI Python Mentor: Building an AI Programming Learning Platform with FastAPI and RAG

Building a chat interface with an LLM API isn't hard. What's hard is building a complete learning platform around AI—integrating structured courses, programming exercises, personalized learning, and an AI mentor into a single full-stack system. The open-source project AI Python Mentor is a systematic answer to this problem.

The project was open-sourced on GitHub by developer coffee1337, with the goal of helping users learn Python and backend development. Unlike the common approach of "letting AI directly generate explanations," AI Python Mentor's core philosophy is: AI should support structured learning, not replace it.

Why We Need "AI + Courses" Instead of "AI + Chat"

A general-purpose LLM can explain Python concepts, but it doesn't know which lesson the student is currently on, or what the latest version of the course material is. This leads to AI responses that may be technically correct but completely unsuited to the learner's current level.

AI Python Mentor solves this problem by combining multiple learning mechanisms:

• Structured courses covering Python and backend concepts
• Programming exercises and knowledge checks
• An AI mentor with access to course context
• Personalized learning roadmaps
• Progress tracking and spaced repetition
• Career-oriented skill gap analysis
• Hands-on portfolio projects

This multi-mechanism design approach gives the platform both the flexibility of AI and the rigor of a structured curriculum.

Technology Stack Choices

The project's technology stack reflects clear layered thinking:

Backend uses Python 3.12 + FastAPI + PostgreSQL, with SQLAlchemy and Alembic managing data access and schema evolution, Pydantic handling data validation, and an AsyncIO-based asynchronous model throughout. The developer chose FastAPI for its strong support for async API development, explicit validation, and modular backend design.

Frontend uses Next.js 15 + React 19 + TypeScript, keeping with mainstream modern React ecosystem configurations.

AI layer includes an LLM Gateway, retrieval-augmented generation (RAG), course-based knowledge indexing, and token usage and cost accounting.

Infrastructure includes Docker and Docker Compose, GitHub Actions, background Workers, and database migration tools.

As a detail worth noting, the project specifically supports native Windows development environments, without requiring Docker for every local workflow—a pragmatic consideration for developer experience.

System Architecture: Modular Monolith with AI Decoupling

AI Python Mentor adopts a modular monolith architecture rather than splitting into microservices right away. The core API handles authentication, learning progress, courses, exercises, and integrations, while specialized tasks are handled by separate processes.

A key design goal of the architecture is: core learning functionality does not depend on the availability of external AI services. If the AI Gateway is unavailable, users can still access courses and other non-AI features. This decoupling makes the application easier to maintain and evolve, and avoids the problem of "the whole platform goes down when AI goes down."

Modular Monolith is an architectural style that sits between traditional monolithic applications and microservices. It still runs as a single deployment unit, but at the code level it divides into clearly bounded modules by business capability (such as authentication, courses, exercises, AI integration), with modules communicating through explicit interfaces rather than arbitrary cross-calls. Compared to microservices, it avoids the complexity and operational costs of distributed transactions, network calls, and service discovery; compared to a "big ball of mud" monolith, it retains the ability to split services on demand in the future. For early-stage projects or small teams, this architecture lets the team first clarify business logic and boundaries, and then extract a module once it truly needs independent scaling or deployment. AI Python Mentor uses this structure to decouple the core learning platform from AI capabilities at the module level, so that when the AI Gateway is unavailable, non-AI features like courses can still be served normally.

Building an AI Mentor with Course Context Using RAG

RAG plays a key role in this project. AI Python Mentor uses a local knowledge index built from immutable snapshots of published course content. The basic flow is:

1. Student asks a question
2. Identify the current course
3. Retrieve relevant course context
4. Build the LLM request
5. Generate a contextually grounded explanation
6. Track usage and cost

By retrieving context from learning materials, the AI mentor's explanations are grounded in what the student is currently studying. The platform also tracks AI usage and cost—a must-consider concern for products relying on paid LLM APIs, not an afterthought.

Core insight: The value of RAG in educational settings isn't about "making AI smarter"—it's about making answers reflect a specific version of the learning materials.

Retrieval-Augmented Generation (RAG) is a technical paradigm that combines "external knowledge retrieval" with "large model generation." Its typical flow is: first split external documents into chunks and convert them into vectors, storing them in a vector database or local index; when a user asks a question, the system first vectorizes the question, then retrieves the most semantically similar chunks; finally, these chunks are used as context, combined with the user's question into a prompt and fed to the LLM to generate an answer. The key value of RAG is that it grounds model responses in retrieved real materials rather than relying solely on parametric knowledge memorized during training, thereby reducing hallucinations and making answers traceable to specific sources. In educational settings, this is especially important: course content may be updated to a specific version, and RAG ensures the AI mentor's explanations align with the currently published materials rather than giving generic responses disconnected from the course.

Security Boundaries for Python Code Execution

Programming exercises require executing user-submitted Python code. Users submit solutions following a simple contract:

def solve(payload):
    # user implementation
    ...

Exercises can define public examples and hidden tests, and the platform stores submission and attempt history. But executing untrusted Python code directly in the main API would introduce serious security risks.

Therefore, the system separates execution scheduling from the main application, defining an independent Python Runner architecture. The production execution model is designed around isolation and resource limits, including container or sandbox boundaries.

Key design decision: The main web API must never become an execution environment for arbitrary user code. The developer also candidly notes that untrusted code execution is disabled by default, and the production Runner still requires appropriate isolated deployment and security configuration.

Sandbox and Container Isolation are core security measures when executing untrusted code. Sandboxes limit the system resources code can access (files, network, processes, system calls, etc.), minimizing potential damage; containers use namespaces and control groups to provide process, filesystem, and network-level isolation. For platforms that need to run user-submitted code, common practices include: executing in isolated one-time containers, disabling or strictly limiting network access, setting CPU and memory limits, restricting execution time, running as non-root, mounting read-only filesystems, and filtering dangerous system calls through mechanisms like seccomp. Even with these measures, risks such as container escape and resource exhaustion remain, so production environments typically need more thorough isolation solutions (such as gVisor, Firecracker microVMs) along with strict quotas and auditing. This explains why the project disables untrusted code execution by default and emphasizes that the main web API never directly runs user code.

Authentication, Background Tasks, and Testing

The backend includes comprehensive account security features: cookie-based sessions, Argon2 password hashing, CSRF protection, email confirmation and password recovery, session revocation, account export and deletion, and admin audit logs. These features remind us that real applications need far more than a working login endpoint.

The architecture also includes background processing for loads such as notifications and execution scheduling, avoiding cramming all operations into HTTP requests.

For testing, the repository includes automated checks for backend functionality, database migrations, frontend builds, Worker logic, and browser flows, driven by GitHub Actions.

Background Jobs and Workers are a common pattern in web applications for handling non-immediate, time-consuming, or retryable work. Unlike completing work synchronously within an HTTP request, background jobs place work into a queue (such as Redis, RabbitMQ, or a database queue) and are consumed asynchronously by independent Worker processes. The benefits are: HTTP endpoints can return quickly, avoiding long user waits; tasks can be retried, rate-limited, or delayed as needed; and compute-intensive or failure-prone operations won't bring down the web service itself. Typical scenarios include sending email notifications, scheduling code evaluation, generating reports, and scheduled data cleanup. In AI Python Mentor, background Workers handle loads such as notifications and execution scheduling, avoiding cramming all operations into the HTTP request cycle—an important engineering practice for system stability and responsiveness.

Current Status and Engineering Lessons Learned

The project is still under active development. The core learning platform, backend, AI integrations, database layer, and CI infrastructure are implemented, and current work focuses on product polish, learning content quality, AI evaluation, and production deployment.

The developer remains transparent: having a production-oriented architecture does not mean all planned production components are deployed.

The project has distilled four engineering lessons:

1. AI should be a component, not the entire architecture—useful AI products still need reliable authentication, data models, application logic, and operational safeguards.
2. Structured context matters—RAG is especially valuable when answers need to reflect a specific version of materials.
3. Security boundaries should be designed early—especially critical when applications accept executable code.
4. Operational concerns are product features—usage quotas, cost tracking, background tasks, and testing all bear on the long-term viability of AI applications.

Conclusion

The value of AI Python Mentor lies not only in being a usable learning platform, but also in demonstrating a way of thinking about building AI products: treat AI as a component within a system, and build complete engineering support around it. For developers working on AI + education, RAG systems, or SaaS MVPs, this open-source project's architectural decisions are worth referencing.

Code and architecture can be viewed in the GitHub repository, and the developer is also seeking collaboration opportunities in Python backend, FastAPI, AI/LLM integration, RAG systems, and SaaS MVP development.

GitHub: https://github.com/coffee1337/ai-python-mentor

One-line Summary

AI Python Mentor builds a full-stack Python learning platform with FastAPI and RAG, where AI is a component and courses are the core.

Paragraph Summary

AI Python Mentor is an open-source full-stack AI programming learning platform released on GitHub by developer coffee1337. Its core philosophy is that AI should support structured learning rather than replace it, integrating structured courses, programming exercises, personalized learning roadmaps, and an AI mentor into a single system. Technically, the backend uses Python 3.12, FastAPI, PostgreSQL, and AsyncIO, the frontend uses Next.js 15 and React 19, and the AI layer includes an LLM Gateway, a RAG knowledge index built from course snapshots, and token cost tracking. Architecturally, it uses a modular monolith so core learning functionality doesn't depend on AI service availability; user code execution is isolated through an independent Python Runner, and the main API never executes arbitrary user code. The project is still under active development, and the developer emphasizes that reliable authentication, data models, background tasks, and testing are the foundation for the long-term viability of AI products.