OpenAI Codex Full Course

Learn Codex by shipping a real Python application.

Generating a code snippet is easy. The harder and more useful skill is taking a feature from an idea to a tested, reviewed, and deployed change. That is the focus of my free OpenAI Codex course.

Across roughly three hours, we build a randomizer wheel application from scratch. The project starts with a FastAPI backend, grows into a full-stack application, and ends with automated testing, containerization, infrastructure as code, continuous deployment, and AI-assisted pull request reviews. Codex is part of the entire process, including planning, implementation, debugging, refactoring, tests, documentation, and delivery.

This is a practical course for Python developers and beginners who want to understand how an AI coding agent fits into real software engineering. You do not need an existing Codex workflow. We start with the architecture and the first prompt, then add more advanced capabilities as the project creates a reason to use them.

By the end of the course, you will have worked through the complete loop:

1. 01
   Understand how Codex combines models, instructions, tools, and project context.
2. 02
   Build and test a Python API with FastAPI, uv, and pytest.
3. 03
   Plan a frontend implementation before changing the code.
4. 04
   Encode repository rules in AGENTS.md.
5. 05
   Package a repeatable workflow as an Agent Skill.
6. 06
   Connect external tools and current documentation through MCP.
7. 07
   Deploy with Terraform, Google Cloud Run, and GitHub Actions.
8. 08
   Add automated Codex reviews to the pull request workflow.

You can follow the finished implementation in the Codex course repository, or clone it and compare each lesson with your own version.

Continue through the embedded lessons below, or watch the complete OpenAI Codex course playlist on YouTube.

See what makes Codex an agent instead of an autocomplete tool.

The first lesson builds the mental model for the rest of the course. Codex does more than predict the next line in an editor. You give it a goal and repository context, and it can inspect files, reason about a change, use tools, run commands, and evaluate the result.

We trace that workflow across the interfaces where developers use Codex: the CLI, IDE integrations, web and cloud workflows, and repository automation. The important idea is that the model is only one layer. Project guidance shapes the task, tools connect the agent to the development environment, and verification tells us whether the change actually works.

This architecture explains why prompt quality matters, but it also explains why a prompt alone is not enough. A useful agentic workflow needs clear instructions, access to the right tools, a constrained execution environment, and feedback from tests or other checks. Function calling connects the model’s reasoning to concrete actions, while the developer remains responsible for scope, review, and acceptance.

This lesson gives you the vocabulary to understand every later step, from planning and AGENTS.md to MCP servers and automated reviews.

Turn a natural-language request into a tested FastAPI feature.

The second lesson moves from concepts to a live coding workflow. We ask Codex to help build the backend for a spinning wheel randomizer, then refine the result until the API has a clear contract and automated tests.

The main endpoint is POST /api/pick-winner. It accepts a list of participants and returns the selected winner. That small requirement is enough to practice several habits that scale to larger projects: explain the expected behavior, inspect the generated design, question ambiguous decisions, run the application, and use test failures as feedback.

We set up the Python project with uv, build the API with FastAPI, and write behavioral tests with pytest. The point is not to see how much code Codex can produce in one pass. The point is to establish a tight loop in which every change is understandable and verifiable.

The lesson also takes the project from a local idea to a GitHub repository. This creates the foundation for the CI/CD and code review workflows later in the course.

If you want to go deeper on test design after this lesson, my pytest course covers fixtures, parametrization, mocking, and test automation in more detail.

Review the plan before Codex changes the frontend.

Once a task touches several files or architectural decisions, the fastest route is not always to start coding immediately. In this lesson, we use Agentic Planning Mode to define how the frontend should fit the system before Codex implements it.

We continue the randomizer wheel application with a browser interface that talks to the FastAPI backend. Codex first explores the repository and proposes an implementation plan. We review that plan, correct assumptions, and make the module boundaries and data flow explicit.

This is where human supervision has the most leverage. A weak plan can produce technically valid code that does not fit the project. A focused review can catch unnecessary dependencies, confused ownership, missing error states, and coupling between the interface and API before those choices spread across the codebase.

The workflow is straightforward:

1. 01
   State the user-visible outcome and constraints.
2. 02
   Let Codex inspect the existing system before proposing changes.
3. 03
   Review the plan for missing behavior and architectural fit.
4. 04
   Refine the plan until each step is testable and scoped.
5. 05
   Implement, run checks, and compare the diff with the approved plan.

Planning does not replace iteration. It makes the first implementation more deliberate and gives both you and the agent a shared definition of the work.

Put repository rules where Codex can use them on every task.

Repeatedly explaining the same commands, quality gates, and architecture rules wastes time and creates inconsistent results. The fourth lesson shows how AGENTS.md turns those expectations into durable project guidance.

We use /init as a starting point, then shape the file around rules that matter to the randomizer project. Codex can read layered guidance before it begins work, and a closer AGENTS.override.md can provide more specific instructions for a subtree. The official AGENTS.md documentation explains how that instruction chain is discovered and combined.

The project then adds engineering controls around that guidance. We build GitHub Actions workflows, enforce branch coverage, create reusable workflow pieces, and report coverage on pull requests. The agent instructions describe how work should be done; CI independently verifies the requirements that must hold before merge.

That distinction matters. AGENTS.md is a strong place for repository commands, architectural boundaries, testing expectations, and operational constraints. It is not a substitute for executable checks. Formatting, tests, coverage thresholds, and deployment validation still belong in automation.

By the end of the lesson, the repository is ready to grow without every new Codex task starting from zero context.

Package a repeatable Docker workflow as an Agent Skill.

Project instructions describe the rules for a repository. A skill packages a focused workflow that Codex can reuse when the same kind of task appears again. In lesson five, we build a fastapi-dockerizer skill instead of leaving the Docker setup as a one-off conversation.

The skill teaches Codex how this workflow should be performed: build the FastAPI application with uv, keep the Docker context clean with .dockerignore, expose repeatable commands through a justfile, and verify the running container through a /health smoke check. We create it with Skill Creator and examine how its instructions and supporting resources fit together.

You will also see the difference between explicit invocation with $skill-name and implicit triggering from a matching request. Progressive disclosure keeps the skill focused: Codex loads the core instructions first and reaches for detailed references or scripts only when the task needs them.

A useful skill should encode a stable workflow, not a vague wish list. It needs a narrow trigger, clear boundaries, and a verification step that proves the result works. The OpenAI guide to building skills provides the current format and authoring guidance.

Resources used in this lesson:

• Install Docker Desktop
• Install Just
• Read the OpenAI Agent Skills documentation

Connect Codex to current documentation, then deploy the application.

A model cannot contain every current library detail or directly access every service you use. The Model Context Protocol, or MCP, gives Codex a standard way to work with external tools and context. The official MCP documentation describes how Codex clients connect to local or remote MCP servers.

We configure Context7 so Codex can fetch current documentation while it works with Python libraries and infrastructure tools. This is a practical example of using external context to reduce stale assumptions during implementation.

Then we apply that workflow to production delivery. Codex helps us provision infrastructure with Terraform, deploy the containerized application to Google Cloud Run, and automate updates through GitHub Actions. The lesson connects application code, infrastructure code, and repository automation into one continuous deployment path.

This is where verification becomes especially important. Infrastructure changes can affect permissions, costs, and availability. Review the generated Terraform, inspect the planned changes, protect credentials, and make deployment health checks part of the workflow. Codex can help produce and troubleshoot the pipeline, but the cloud account and release policy remain under your control.

Resources used in this lesson:

• Install Terraform
• Install the Google Cloud CLI
• Explore the complete deployment code

Make Codex an active reviewer in the pull request workflow.

The final lesson adds Codex to GitHub so pull requests can receive an automated AI review as part of continuous integration. The goal is not to replace human reviewers. It is to catch plausible regressions, missing tests, risky assumptions, and maintainability problems before a person spends time on the change.

We configure the repository workflow, provide focused review instructions, and make the result visible on the pull request. This creates a repeatable feedback loop for feature branches and releases instead of relying on someone to remember to request an ad hoc review.

Review quality depends on context. Codex needs the relevant diff, repository guidance, and clear criteria. CI should continue to own deterministic checks such as formatting, tests, and coverage. The AI review is most valuable when it looks for problems that require reasoning across the change. The official Codex code review guide also shows how reviews work across Codex clients.

With this step, the project has a complete engineering path: plan the feature, implement it, test it, package it, deploy it, and review changes through automation.

Start with lesson one if you are new to Codex, or use the full YouTube playlist as a reference while you build your own project. Clone the course repository, reproduce the workflow, and replace one project decision at a time with a requirement from your own application.