How I AI: 3 Advanced Codex Workflows for Faster, Smarter Development with OpenAI's Alex Embiricos
Unlock the full potential of OpenAI's Codex with these practical workflows from product lead Alex Embiricos. Learn how to manage parallel development with Git worktrees, architect complex projects using the Plans.md technique, and automate code reviews in GitHub to massively accelerate your engineering velocity.
Claire Vo
Full episode
Watch or listen
Workflows from this episode
- How to Architect Complex Software Projects with OpenAI's Plans.md Technique
- How to Manage Parallel Development with AI using Git Worktrees and Codex
- How to Use OpenAI Codex to Understand and Modify a New Codebase
Episode outline
In this episode of How I AI, OpenAI Codex product lead Alexander Embiricos demonstrates how to understand an unfamiliar repository, run parallel changes with Git worktrees, plan a larger implementation in Plans.md, and use Codex for pull-request review.
The workflows move from a small natural-language change to parallel branches and then a structured implementation plan. Each one keeps a review surface visible to the person using the agent.
Alex also explains how four engineers built the Sora Android app in 28 days and how the team uses high-confidence automated review comments in GitHub.
The examples include the prompts, files, and terminal operations behind each handoff.
Start in an unfamiliar repository
Before changing a new project, Alex asks Codex how it runs and where the relevant behavior lives.
Install Codex and inspect the project
Alex uses the Codex extension in VS Code. It is included with paid ChatGPT plans. After sign-in, the Codex icon appears in the sidebar and can be moved to the secondary sidebar.

With the repository open, Alex begins with a plain question:
How do I play this game?
Codex explains the project and provides the command for the local development server.
npm run devThis gives a product manager, designer, or engineer a quick way to orient before proposing a change.
Request a small change in natural language
In the demo game, the character jumped too high. Alex described the desired result without first locating the implementation.
He wrote:
jump is way too big, lower please.

Codex found the jump logic, proposed a smaller value, made the change, and presented the diff for review.
Isolate parallel work with Git worktrees
How to Manage Parallel Development with AI using Git Worktrees and Codex: Give parallel Codex tasks separate Git worktrees so each agent has its own branch and directory. Alex creates French and German variants, runs both at once, and keeps their changes independently testable.
Worktrees let Alex run two changes against the same repository without putting both in one working directory or branch.
Ask Codex to create the worktrees
A Git worktree checks out another branch into its own directory while sharing the repository's Git metadata. Alex asks Codex to create the directories instead of recalling each command.
He passes the request when launching Codex:
Codex in here, create two new work trees off the main branch, one called French and one called German.
Codex runs the git worktree add commands and creates French and German directories on separate branches.
Run one agent in each worktree
Alex opens a terminal in each directory and gives each Codex instance a separate task:
- French worktree: Change the input placeholder strings to French.
cd French
# Then runs Codex with the prompt:
translate the input field placeholder strings to French- German worktree: Change the input placeholder string to German.
cd German
# Then runs Codex with the prompt:
translate the input placeholder string to German
The two agents work in separate directories and branches. Alex can review, test, and merge each change independently.
Plan larger work with Plans.md
How to Architect Complex Software Projects with OpenAI's Plans.md Technique: Use a reusable Plans.md rubric to make Codex produce a self-contained, milestone based implementation plan for a complex change. Alex plans a Python SDK from an existing TypeScript SDK before asking Codex to build it.
For larger projects, the team uses a written planning process before implementation rather than beginning with an open-ended coding request.
Plans.md contains instructions for what a useful implementation plan should include. It acts as a plan for producing the plan.
Add Plans.md to the repository
Copy the Plans.md template from the OpenAI guidance into the repository. It asks for self-contained milestones, edge cases, and updates as the work progresses.

Generate sdk_plan.md
Alex demonstrated the method by asking for a Python SDK based on an existing TypeScript SDK:
using Plans.md make a plan to build a Python SDK based off our TypeScript SDK. put it in sdk_plan.md
Codex produced a roughly 120-line plan covering naming conventions, milestones, and implementation tasks. The engineer can revise that plan before code is written.

Refine and implement the plan
Refine sdk_plan.md in the same planning chat until it is approved. Implementation can then begin in a new chat with the approved file as context:
implement the plan in sdk_plan.md
Codex follows the milestones and verification steps in sdk_plan.md. Alex estimated that this example could run for 30 minutes to an hour.
Bonus workflow: review pull requests with Codex
How to Use OpenAI Codex to Understand and Modify a New Codebase: Open an unfamiliar repository in Codex, ask how to run it, launch the app with the returned command, and make a small behavior change in plain language while Codex traces the relevant code.
OpenAI also runs Codex on pull requests so code generation does not simply move the bottleneck into human review.
Codex scans a new pull request and is tuned to comment only when confidence is high, protecting reviewer attention from low-value suggestions.

If Codex identifies an issue, a reviewer can reply to its GitHub comment:
Hey, codex, can you fix it?
Codex can create and push a follow-up commit. When it finds nothing to flag, it records approval without adding a review thread.
What makes this work
Match the workflow to the size of the change. Ask for orientation and a diff on a small fix. Use worktrees when tasks need separate branches and directories. Require a written plan and verification steps for larger work.
Keep the review artifact visible at every stage: a file diff, an isolated branch, sdk_plan.md, or a pull-request comment. That makes parallelism useful without hiding the decision from the engineer.
Start with one unfamiliar repository and one bounded change. Add worktrees or Plans.md only when the task actually needs isolation or architectural planning.
Ask for Setup Instructions Inspect this repository and tell me how to run it locally. Identify the package manager, required setup, environment files, and exact development command from the files in this repo. Then explain how I use the app once it starts.
Request a Change with Natural Language The character jumps much too high. Trace the code that controls jump height, lower it to a reasonable value without changing other movement behavior, and run the relevant checks. Summarize the file and value you changed.
Generate the Implementation Plan Using Plans.md, create a self-contained plan for building a Python SDK based on the TypeScript SDK in this repository. Identify the current API surface, naming and error conventions, package structure, tests, documentation, and release setup. Break the work into testable milestones and save the plan to sdk-plan.md.
Review and Iterate on the Plan Revise sdk-plan.md so each milestone names the source TypeScript files, target Python modules, compatibility decisions, and commands that prove the milestone works. Add an explicit decisions section and unresolved questions. Keep the existing repository conventions.
Execute the Approved Plan Implement sdk-plan.md milestone by milestone. Keep its progress and decisions sections current as you work. Run the validation commands for each milestone before moving on, and finish with a summary of completed work and any unresolved items.
The Python SDK example also shows why planning needs repository evidence. Codex is not starting from a blank language spec; it can inspect the existing TypeScript SDK, identify its public surface and tests, and turn those concrete constraints into milestones before implementation begins.
Open an unfamiliar repository in Codex, ask how to run it, launch the app with the returned command, and make a small behavior change in plain language while Codex traces the relevant code.
Use a reusable Plans.md rubric to make Codex produce a self-contained, milestone based implementation plan for a complex change. Alex plans a Python SDK from an existing TypeScript SDK before asking Codex to build it.
Watch or listen
Sponsors
Thanks for supporting How I AI
Build your next product with ChatPRD
Turn an idea into a PRD, user stories, and a plan.


