Artificial intelligence
Codex

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.

Intermediate12 h · 6 × 2 hSpanish & English
Contact

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

  1. 01

    Prepare context and acceptance criteria for a development task.

  2. 02

    Review a proposed change against the requested behaviour.

  3. 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.

01

Give 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.
02

Work 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.
03

Verify 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

  1. Context

    • Faro repository

      Prepared practice code and data

    • Two tasks

      Status filter and blank subject

  2. Change

    • All selected initially

      Open, Closed and an empty state

    • A valid subject

      Reject inputs containing only spaces

  3. 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.

  1. 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 end

    A short project map and a documented initial state.

  2. 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 end

    A reproducible bug and acceptance criteria before modifying the app.

  3. Session 32 h

    Plan a focused change

    Review affected files, steps and tests with Codex; question assumptions and exclude unnecessary changes.

    By the end

    A plan linking the two tasks to their implementation and verification.

  4. 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 end

    An implementation that can be explained through the agreed criteria.

  5. 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 end

    A record of tests and corrections with expected and observed results.

  6. Session 62 h

    Review the diff and prepare the handover

    Exchange reviews, address findings and repeat affected tests; document commands and limits.

    By the end

    A 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

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.

See materials, support and terms

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.

What does your
team need to learn?

Tell us what you want to work on, how many people would take part and where you are based. We will prepare a proposal with scope, sessions and a budget.

Would you like to ask about FUNDAE?

We check eligibility for each company and edition, subject to requirements and available training credit in Spain. Funding is neither automatic nor guaranteed. Official FUNDAE information ↗

Discuss eligibility
The Optimal FlowlearnCodex

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.

12 live hours6 sessions of 2 hoursIn Spanish or English

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.

Who it is for

Developers and technical professionals who read and modify code and want to use Codex with clear review criteria and change control.

By the end you will be able to

  • Prepare context and acceptance criteria for a development task.
  • Review a proposed change against the requested behaviour.
  • Run checks and document results and questions for review.

Before we begin

Experience reading code and using version control. Language, repository, environment and Codex access will be agreed; practice will not use production directly.

Experience reading code and using Git is required. We prepare the TypeScript/React/Vite repository with Vitest and Playwright; account, Codex access, editor, dependencies and startup are checked beforehand. The case uses fictional data and a practice branch. Tool installation is outside the twelve hours; practice uses no production repositories.

Your trainer

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.

The Optimal FlowlearnCodex for development

Programme sessions

  1. Session 1 · 2 h

    Understand the repository and context

    Explore the app, read instructions and locate logic, components and tests; run the initial checks.

    Result: A short project map and a documented initial state.

  2. Session 2 · 2 h

    Reproduce and define expected behaviour

    Reproduce the spaces-only subject, prepare a test that detects it and define the filter criteria.

    Result: A reproducible bug and acceptance criteria before modifying the app.

  3. Session 3 · 2 h

    Plan a focused change

    Review affected files, steps and tests with Codex; question assumptions and exclude unnecessary changes.

    Result: A plan linking the two tasks to their implementation and verification.

  4. Session 4 · 2 h

    Implement and read the changes

    Add the filter and fix validation in the classroom branch; inspect the diff and adjust scope.

    Result: An implementation that can be explained through the agreed criteria.

  5. Session 5 · 2 h

    Check regression and edge cases

    Run Vitest and Playwright; test empty subjects, no matching results and returning to the full list.

    Result: A record of tests and corrections with expected and observed results.

  6. Session 6 · 2 h

    Review the diff and prepare the handover

    Exchange reviews, address findings and repeat affected tests; document commands and limits.

    Result: A handover ready for decisions on what to accept, correct or investigate before integration.

A fictional classroom case

A useful filter and a fix that tests can verify

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.

By the end of the exercise: 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.

The Optimal FlowlearnCodex for development

What we will work on

Give the agent context

  • 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.

Work with changes

  • 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.

Verify before integrating

  • 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.

Extensions agreed separately. 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.

What accompanies the programme

  • A downloadable, versioned guide, exercises and review criteria; keep a copy for internal use.
  • A short recommendation, editable kit and group learning report. Responsibilities, a prior access check, handover and recipients are agreed for each delivery.
  • TOF’s own certificate of achievement after passing the agreed assessment. It is not a vendor certification.
  • Email support on the content covered for one calendar month after the last session. A maximum of two accumulated hours for the whole group, with a response time of up to two working days.

Clients provide licences unless expressly agreed otherwise. Recordings are agreed in advance. Implementation, work carried out independently by TOF, production deployment and ongoing maintenance are quoted separately. Delivery link access is agreed per delivery. Later updates and specific support require agreement. Structured documents and text alternatives; participation needs reviewed before starting.

Full format and terms → theoptimalflow.com/en/learn/how-we-teach