The Optimal Flowlearn
Artificial intelligence
Claude

Claude for development

Learn to use Claude for development tasks, provide code context and review proposed changes and tests against clear technical criteria.

Intermediate12 h · 6 × 2 hSpanish & English
Contact

Find your starting point

A good fit when you already read and modify code and want to use Claude for analysis and change reviews with technical checks.

Another option to consider

Claude for everyday workIf you need to analyse documents and prepare content without working with code, choose the everyday-use programme.
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

    Describe a development task with context and acceptance criteria.

  2. 02

    Review proposed code and identify assumptions requiring checks.

  3. 03

    Prepare tests and an explanation of the change for technical review.

A proposed programme

Work with Claude Code on a practice repository with existing code, conventions and tests. The case is to fix an inventory CSV importer: reproduce why it accepts invalid quantities, review a focused improvement and check that valid inputs still work. Leave the change explained so another person can review it.

We adapt the selection and depth of the modules to the group's starting point and goals.

01

Context for development

Requirements, code structure and information needed for a focused task.

You will work on

  • Find the importer, its tests and repository instructions; ask for an explanation of the data flow.
  • Provide a minimal CSV, the reproduction command and expected behaviour before proposing changes.
  • Define non-negative integer quantities, required fields and error messages as exercise criteria.
Practice
Reproduce the acceptance of “12x” as a quantity and document what should happen to that row, an empty one and a valid one.
How you will check it
A short report with input, command, observed and expected results, linked to the relevant code.
02

Implement with supervision

Code proposals and Claude Code use where appropriate for the environment and group.

You will work on

  • Request a plan that separates the bug fix from reorganising the code.
  • Review and apply small validation changes, following conventions and the agreed scope.
  • Refactor repeated validation without changing how valid inputs are handled.
Practice
Fix partial quantity conversion and review a reusable validation function through the diff.
How you will check it
A focused change that rejects invalid rows, with an explanation of why each file changed.
03

Review and check

Diffs, tests and documentation to decide what to accept or correct.

You will work on

  • Prepare regression tests that fail on the initial code and pass after the fix.
  • Check valid quantities, zero, empty values, text, negatives and decimals against the case requirements.
  • Review the diff, test output and change limits; write a handover for technical review.
Practice
Find a test that merely confirms the implementation and replace it with behaviour examples; rerun the repository checks.
How you will check it
Useful tests with recorded commands and results, plus an explanation of what was checked and what remains outstanding.

A CSV that accepts an invalid quantity

Teaching example

You will work on a task in a practice repository, check the proposal against requirements and leave a reviewed change with its checks.

Fictional classroom case. A small team maintains an inventory importer in a prepared JavaScript or TypeScript repository. The CSVs contain invented products and quantities; each quantity must be a non-negative integer and an empty value must produce a row error.

Starting point
The code converts “12x” to 12. An import appears correct despite an invalid quantity in the file; existing tests cover only valid inputs.
First attempt
The first proposal changes the conversion and reorganises several files at once. Its new test accepts the proposed code's output without showing that it detects the original bug.
What we review
During the exercise review, the trainer asks participants to separate the fix from refactoring, define zero and empty-value behaviour, and show that the “12x” test fails before the change. They also review error messages.
Result
The intended handover contains a small fix, more readable validation and tests for valid and invalid inputs. The explanation connects the bug, diff and checks; these are exercise outcomes to be reviewed in class.

From a reproducible bug to a reviewable change

  1. Understand

    • Minimal CSV

      “12x”, an empty value and a valid quantity

    • Agreed criteria

      Non-negative integers and row errors

  2. Fix

    • Small change

      Validate before converting

    • Refactoring

      Review repeated code separately

  3. Check

    • Regression

      Fails before and passes after the fix

    • Technical handover

      Diff, commands, results and limits

Teaching illustration of the case. Practice and review take place in a prepared repository.

Before calling it complete

  • The bug can be reproduced on the initial code and the regression test detects it.
  • Zero remains valid; empty, negative, decimal or text-containing quantities are rejected under the agreed criteria.
  • The handover identifies commands, results and limits; the reviewer can explain the change.

Sessions to put it into practice.

Reference edition · 12 h live

Reference edition: 12 live hours across 6 sessions of 2 hours. Practice takes place during the sessions. Repository, language, Claude Code access and any additional preparation are confirmed for each edition.

  1. Session 12 h

    Understand the repository

    Find the importer, conventions and tests; review context and scope with Claude Code.

    By the end

    A short code map and a focused task.

  2. Session 22 h

    Reproduce the bug

    Reduce the CSV to a minimal example and agree the behaviour of valid and invalid inputs.

    By the end

    A reproducible bug and acceptance criteria.

  3. Session 32 h

    Plan and fix

    Review the plan and apply a small fix, checking each change against the bug.

    By the end

    An initial fix reviewed through the diff.

  4. Session 42 h

    Improve validation

    Separate repeated logic and check that the refactoring preserves the agreed behaviour.

    By the end

    Clearer validation with an explainable scope.

  5. Session 52 h

    Test behaviours

    Review regression, boundaries and invalid inputs; read the check outputs.

    By the end

    Tests that distinguish the initial code from the fix.

  6. Session 62 h

    Hand over for review

    Handle a CSV variation and review the diff, tests and explanation with trainer feedback.

    By the end

    A classroom change prepared for technical review.

If your team needs to go further

  • Applying the method to a company repository requires agreement on data, access, conventions and change scope.
  • Large migrations, integrations, a complete security review or production deployment require a separate scope.

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.

Your team carries out the practice. Implementation services are agreed separately. See the scope →

Keep learning

Other options for the task you want to work on. Each link explains what that programme adds.

Artificial intelligence

Codex for development

If you also use Codex, practise scoping tasks and reviewing its changes within the repository workflow.

View course

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.

Contact

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 FlowlearnClaude

Claude for development

Learn to use Claude for development tasks, provide code context and review proposed changes and tests against clear technical criteria.

12 live hours6 sessions of 2 hoursIn Spanish or English

Reference edition: 12 live hours across 6 sessions of 2 hours. Practice takes place during the sessions. Repository, language, Claude Code access and any additional preparation are confirmed for each edition.

Who it is for

Developers and technical professionals using Claude to support code analysis, implementation and review while retaining control over changes.

By the end you will be able to

  • Describe a development task with context and acceptance criteria.
  • Review proposed code and identify assumptions requiring checks.
  • Prepare tests and an explanation of the change for technical review.

Programme sessions

  1. Session 1 · 2 h

    Understand the repository

    Result: A short code map and a focused task.

  2. Session 2 · 2 h

    Reproduce the bug

    Result: A reproducible bug and acceptance criteria.

  3. Session 3 · 2 h

    Plan and fix

    Result: An initial fix reviewed through the diff.

  4. Session 4 · 2 h

    Improve validation

    Result: Clearer validation with an explainable scope.

  5. Session 5 · 2 h

    Test behaviours

    Result: Tests that distinguish the initial code from the fix.

  6. Session 6 · 2 h

    Hand over for review

    Result: A classroom change prepared for technical review.

Before we begin

Experience reading and modifying code. Language, repository and Claude or Claude Code access will be agreed; the exercise does not include a production release.

Experience reading and modifying code is required. Reference setup: a local JavaScript or TypeScript repository with Git, dependencies and test command prepared, plus Claude Code in a terminal or compatible editor. Before each edition, we will check the account, access, version and test execution; the language and any adaptation are agreed beforehand. We use fictional data and a practice copy of the repository.

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.

Course online · theoptimalflow.com/en/learn/courses/claude-developmentinfo@theoptimalflow.comVersion 1 · Document reviewed: 13 October 2026
The Optimal FlowlearnClaude for development

What we will work on

Context for development

  • Find the importer, its tests and repository instructions; ask for an explanation of the data flow.
  • Provide a minimal CSV, the reproduction command and expected behaviour before proposing changes.
  • Define non-negative integer quantities, required fields and error messages as exercise criteria.

Practice: Reproduce the acceptance of “12x” as a quantity and document what should happen to that row, an empty one and a valid one.

Implement with supervision

  • Request a plan that separates the bug fix from reorganising the code.
  • Review and apply small validation changes, following conventions and the agreed scope.
  • Refactor repeated validation without changing how valid inputs are handled.

Practice: Fix partial quantity conversion and review a reusable validation function through the diff.

Review and check

  • Prepare regression tests that fail on the initial code and pass after the fix.
  • Check valid quantities, zero, empty values, text, negatives and decimals against the case requirements.
  • Review the diff, test output and change limits; write a handover for technical review.

Practice: Find a test that merely confirms the implementation and replace it with behaviour examples; rerun the repository checks.

A fictional classroom case

A CSV that accepts an invalid quantity

Fictional classroom case. A small team maintains an inventory importer in a prepared JavaScript or TypeScript repository. The CSVs contain invented products and quantities; each quantity must be a non-negative integer and an empty value must produce a row error.

By the end of the exercise: The intended handover contains a small fix, more readable validation and tests for valid and invalid inputs. The explanation connects the bug, diff and checks; these are exercise outcomes to be reviewed in class.

Extensions agreed separately. Applying the method to a company repository requires agreement on data, access, conventions and change scope. Large migrations, integrations, a complete security review or production deployment require a separate scope.

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
Course online · theoptimalflow.com/en/learn/courses/claude-developmentinfo@theoptimalflow.comVersion 1 · Document reviewed: 13 October 2026