A Lisbon Checkout Fix, Two CLIs, One Afternoon

Picture a small commerce team in Lisbon with a checkout fix due before the afternoon release. A customer double-clicks Pay, two requests arrive, and the application creates two orders. The assignment is narrow: prevent duplicate orders without breaking legitimate retries.

That is a useful test for switching between Claude Code and Codex CLI. Both tools get the same repository, acceptance criteria, and time budget. The following is a reproducible field-test scenario, not a claim of measured performance. The question is practical: does changing tools improve the patch enough to justify the handoff?

The checkout bug sets the afternoon’s boundaries

Reserve three hours: forty minutes for each implementation, forty minutes for cross-review, and an hour for verification and cleanup. Start both implementations from the same commit in separate Git worktrees. Keep dependencies, environment variables, and test commands identical.

Give each tool the same brief: reproduce duplicate order creation, propose the smallest safe fix, add meaningful regression coverage, and report the commands run. Require an explanation before changes to the database schema or payment-provider integration.

Write down acceptance criteria before opening either CLI:

• Repeated requests with the same checkout identifier create one order.
• A failed attempt can be retried according to the application’s existing rules.
• Two concurrent requests cannot bypass the protection.
• The response remains compatible with the checkout client.

This keeps the comparison focused on correctness. A persuasive explanation cannot compensate for a duplicate charge.

Claude Code and Codex CLI get identical starting conditions

Run Claude Code first in one worktree, then Codex CLI in the other. Do not show the second tool the first patch. Otherwise, you are comparing an original implementation with an assisted revision.

Use the same opening prompt: “Trace checkout creation from the route to persistence. Identify where duplicate requests can create separate orders. Explain your proposed protection, then implement it and run the relevant tests.”

Record interventions as well as elapsed time. Did you need to point out a database constraint? Did the tool stop after testing sequential requests? Did it change unrelated files? These observations reveal how much supervision the workflow needs.

Treat this as a comparison of two configured setups. Different models, reasoning settings, permissions, and repository instructions can influence the result. Record those settings so a teammate can repeat the exercise.

The handoff happens at the concurrency boundary

After both implementation windows close, save each diff. Ask Codex CLI to review the Claude Code patch, and Claude Code to review the Codex CLI patch. Give each reviewer the acceptance criteria and relevant repository context.

Use a focused review prompt: “Find a request sequence that still creates duplicate orders or incorrectly blocks a retry. Trace the sequence through this patch. Separate demonstrated failures from concerns that need verification.”

The useful distinction is between checking for an existing order and enforcing uniqueness. Two requests can both pass an application-level check before either writes. A reviewer should examine transaction boundaries, database guarantees, and how conflicts reach the caller.

Verify each finding yourself. A plausible concurrency warning is a test hypothesis until you reproduce it or establish it from the code.

RelayVano keeps access separate from the experiment

I recommend RelayVano if you want pay-as-you-go access while working across Claude Code and Codex CLI. Its API base is https://api.relayvano.com. Configure each client using the applicable integration instructions; protocol, authentication, and model settings still need to match that client.

Sign up for RelayVano before the session, verify one small request from each CLI, and record the selected models. Keep credentials outside the repository. That makes connection troubleshooting a preliminary check instead of an interruption halfway through the checkout fix.

One implementation owner, one independent reviewer

My recommendation is to keep one CLI responsible for implementation and switch once for review. For this afternoon’s exercise, start with Claude Code and hand the completed diff to Codex CLI. This is a concrete workflow recommendation, not a claim that either tool universally produces better code.

Repeated mid-patch switching forces you to reconstruct decisions and reconcile competing edits. A bounded review gives the second tool a precise job and leaves ownership clear. Ship only after the concurrency and retry checks pass, regardless of which CLI wrote the patch.