Codex for development
Learn to work with Codex in a repository, define verifiable tasks and review changes and tests before deciding what to incorporate into the project.
Find your starting point
A good fit when you already work with code and version control and want to review Codex changes through technical criteria and checks.
- Hours and sessions
- 12 hours live · 6 sessions of 2 h.
- Group size
- Up to 12 participants per trainer as a reference, adjusted to the practice and feedback.
What you will learn
- 01
Prepare context and acceptance criteria for a development task.
- 02
Review a proposed change against the requested behaviour.
- 03
Run checks and document results and questions for review.
A proposed programme
Work with Codex on a prepared TypeScript and React repository for internal requests. Add a status filter and fix a bug with a regression test. The twelve hours cover context, reproduction, planning, changes, checks and a handover another person can review.
We adapt the selection and depth of the modules to the group's starting point and goals.
01Give the agent context
Repository structure, project instructions and the scope of a focused task.
You will work on
- Explore the structure, project instructions and commands; check the repository’s initial state.
- Reproduce a bug with fictional data and separate observed behaviour from expected behaviour.
- Scope the two tasks and their acceptance criteria before requesting changes from Codex.
- Practice
- Prepare the tracker context and reproduce its acceptance of a subject containing only spaces.
- How you will check it
- A verifiable task with instructions, reproduction and criteria for the filter and fix.
02Work with changes
Code exploration, proposed implementation and supervised diff review.
You will work on
- Request a plan linking each change to the affected files, behaviours and tests.
- Implement All, Open and Closed filters, keeping All as the initial state.
- Fix blank subjects and review the diff for changes outside scope.
- Practice
- Guide implementation in a practice branch and compare the change with the agreed criteria.
- How you will check it
- A focused diff that can be explained through the requested behaviour.
03Verify before integrating
Relevant tests, result documentation and criteria for accepting or correcting changes.
You will work on
- Check that the regression test detects the bug before the fix and passes afterwards.
- Run relevant Vitest and Playwright tests, including empty input, no filter matches and returning to All.
- Review code and results with another person; document commands, limits and questions before integration.
- Practice
- Check normal and edge cases, address findings and prepare a handover for review.
- How you will check it
- Reviewed changes and tests, with reproducible results and explicit outstanding issues.
A useful filter and a fix that tests can verify
Teaching example
You will address a small task in a practice repository, review the generated changes and prepare a handover with documented checks and limitations.
Fictional classroom case. The Faro repository contains a request tracker, invented data and configured tests. We work on a local branch with Codex, TypeScript, React and Vite; Vitest and Playwright are ready before the course.
- Starting point
- We want All, Open and Closed filters, with All selected initially. The app also accepts subjects containing only spaces: we need to reproduce the bug and prevent its return.
- First attempt
- The example’s first proposal starts the filter on Open and tests only the filtering function. The list looks correct, but the initial state has changed and creation still accepts a spaces-only subject.
- What we review
- The trainer asks participants to return to the criteria and show evidence. The group adds a test that detects the blank subject before fixing it, keeps All selected initially and checks no matches and returning to All. It also reviews the modified files.
- Result
- The revised example links the filter and validation with their tests. The handover contains a small diff, commands and results, and explains the teaching repository’s limits. In practice, that evidence is checked before deciding what to accept.
From expected behaviour to evidence
Context
Faro repository
Prepared practice code and data
Two tasks
Status filter and blank subject
Change
All selected initially
Open, Closed and an empty state
A valid subject
Reject inputs containing only spaces
Evidence
Vitest and Playwright
Regression and journey checked
Diff and handover
Commands, results and limits
Teaching illustration of a fictional case. It is not a guaranteed Codex result; each change must be reviewed and checked in the repository.
Before calling it complete
- The diff addresses the two tasks and keeps All as the initial state.
- The regression test detects the previous bug; relevant tests cover empty input, no results and returning to All.
- The handover supports repeating the checks and separates observed results from outstanding questions.
Sessions to put it into practice.
Reference edition · 12 h live
Reference edition: 12 live hours across 6 two-hour sessions. Includes context, reproduction, planning, implementation, regression and diff review. The repository and tools must work before the course starts; the handover is prepared for review.
- Session 12 h
Understand the repository and context
Explore the app, read instructions and locate logic, components and tests; run the initial checks.
By the endA short project map and a documented initial state.
- Session 22 h
Reproduce and define expected behaviour
Reproduce the spaces-only subject, prepare a test that detects it and define the filter criteria.
By the endA reproducible bug and acceptance criteria before modifying the app.
- Session 32 h
Plan a focused change
Review affected files, steps and tests with Codex; question assumptions and exclude unnecessary changes.
By the endA plan linking the two tasks to their implementation and verification.
- Session 42 h
Implement and read the changes
Add the filter and fix validation in the classroom branch; inspect the diff and adjust scope.
By the endAn implementation that can be explained through the agreed criteria.
- Session 52 h
Check regression and edge cases
Run Vitest and Playwright; test empty subjects, no matching results and returning to the full list.
By the endA record of tests and corrections with expected and observed results.
- Session 62 h
Review the diff and prepare the handover
Exchange reviews, address findings and repeat affected tests; document commands and limits.
By the endA handover ready for decisions on what to accept, correct or investigate before integration.
If your team needs to go further
- Adapting the workflow to a team repository requires an advance review of language, dependencies, permissions and authorised data.
- Adding a backend, migrations, deployment or CI automation requires its own objectives and checks.
Learn with someone who develops projects for companies.

Borja Martínez
The Optimal Flow consultant
Over two years of experience developing projects for companies across industries and sizes.
Borja is the planned trainer for this programme. Dates, language and his availability are confirmed when the edition is agreed.
With guidance, practice and support.
Each delivery includes working materials, feedback on practical work and assessment against the agreed objectives.
Materials you can keep
Downloadable, versioned guides, exercises and review criteria for internal use.
To prepare and complete the delivery
A short recommendation, an editable communications kit and a group learning report.
TOF’s own certificate
A certificate of achievement after the agreed assessment. It is not a vendor certification.
A month of email support
On the content covered, up to two accumulated hours for the whole group.
Your team carries out the practice. Implementation services are agreed separately. See the scope →