Welcome to the course! In this series, we are going to build a complete backend for a movie recommendation platform, similar to services like Netflix or Hulu.

Imagine you have a massive collection of movie data — titles, actors, genres, and descriptions. We have already prepared a repository for you that contains this raw data in CSV files and a database schema to organize it. However, a database sitting on a server is not very useful on its own. Users cannot interact with a database directly.

To make this data accessible, we need to build an API (Application Programming Interface). This API will act as the bridge between our database and the user's screen. It will allow users to log in, browse movies, leave reviews, and, most importantly, receive personalized recommendations.

In this lesson, we will not write Python code just yet. Instead, we will act as architects. We will use Codex to design the blueprint of our system, ensuring we have a clear plan before we start building.

Before we design the API, it is helpful to understand how a recommendation system actually works. At its core, a recommendation engine is a system that filters information to predict what a user might like.

To make these predictions, the system needs data. We call this data User Signals.

There are two main types of signals we need to collect:

1. Explicit Signals: These are direct actions where the user tells us exactly what they think. For example, writing a review or giving a movie a 5-star rating.
2. Implicit Signals: These are indirect actions. For example, if a user clicks "play" on a movie and watches it until the end, that is a strong signal they were interested, even if they didn't leave a review.

Our goal is to build an API that can collect these signals and store them. Later, we will use this data to feed an algorithm that generates the list of "Recommended for You" movies.

To build a robust backend, we need to organize our API endpoints logically. We can group the necessary features into four main categories:

1. Authentication & Users: We need to know who is using the app. We need endpoints for registering new accounts, logging in, and retrieving user profiles.
2. Catalog & Metadata: This is the core of our movie database. We need endpoints to list movies, search for titles, and get details about specific shows, genres, or actors.
3. User Activity: This is where we collect the "signals" mentioned earlier. We need endpoints that allow users to mark a movie as "viewed" or submit a text review.
4. Recommendations: Finally, we need endpoints that return the results. This includes personalized lists based on user history and general lists like "Trending Now."

By breaking the system down into these categories, we make the development process much more manageable.

In this course, we are using Codex as an intelligent assistant. For Codex to be effective, it needs to know what we are building.

We have a file in our repository called AGENTS.md. This file acts as the "long-term memory" for our AI. It contains guidelines, database structures, and project goals.

When we create a new plan, we must update AGENTS.md to include this information. This ensures that when we ask Codex to "write the code for the login endpoint" in a future lesson, it knows exactly what that endpoint should look like because it is defined in the context.

By keeping AGENTS.md updated, we ensure that Codex stays aligned with our architectural vision throughout the entire course.

In this lesson, we laid the foundation for our movie recommendation system.

1. We learned that recommendation systems rely on User Signals (views and reviews).
2. We learned the importance of updating AGENTS.md to keep our AI assistant informed.

In the upcoming practice exercises, you will use Codex to generate a design documents yourself. This planning phase is crucial; a well-designed plan makes writing the actual Python code much easier and faster.