Friday's Payment Review on a Lisbon Team

Imagine a small payments team in Lisbon with a Friday release approaching. A pull request adds automatic retries when a payment provider times out. The change looks tidy: one helper, two updated callers, and several tests. But one question matters more than tidy code: could a retry charge someone twice?

This is a useful place to meet the idea of code review with a fast reader and a slow thinker. Instead of asking one AI assistant to inspect everything equally, you divide the work into two jobs: finding relevant evidence and reasoning carefully about the risky parts.

The fast reader maps the payment change

The fast reader's job is orientation. Give it the patch, the repository's review instructions, and access to relevant files. Ask it to identify changed behavior, affected callers, existing tests, and missing context. It should produce a map, not a verdict.

For the retry change, that map might identify where requests receive an idempotency key, where the retry helper runs, and which tests simulate timeouts. An idempotency key is an identifier intended to let repeated requests represent one operation rather than several separate purchases.

A useful instruction is: Read this change and list the payment paths it affects. Cite file paths and line numbers. Separate observed behavior from questions that require further inspection. Do not approve the change.

The slow thinker examines the timeout risk

The slow thinker receives the map and investigates a narrower question. Here, it asks what happens if the provider accepts a payment but the response never reaches the application. A timeout tells the application that it did not receive a response; it does not, by itself, establish whether the payment happened.

Ask this reviewer to trace the sequence: the first request leaves, the connection times out, and another attempt begins. Does the second attempt reuse the same key? Can another worker start the same payment? Does the application's stored state distinguish an uncertain outcome from a confirmed failure?

The labels describe responsibilities, not guaranteed product characteristics. You can use two models, or run separate passes with one model. More waiting does not automatically mean better reasoning, and a quick response is not automatically shallow.

The handoff needs evidence, not just a summary

The biggest weakness in this arrangement is a confident but incomplete handoff. If the fast reader misses a second caller, the slow thinker may reason beautifully about only half the system. Keep the original patch available and let the deeper reviewer inspect source files directly.

• State the intended behavior in one sentence.
• List changed files and relevant callers with exact locations.
• Identify tests already checked and scenarios still untested.
• Mark uncertain statements as questions rather than facts.
• Include repository rules that affect the proposed change.

Ask each finding to describe a trigger, a consequence, and supporting evidence. For example: if the key is generated inside the retry loop, each attempt receives a different identifier, potentially defeating duplicate protection. That is a hypothesis to verify in the code, not a finding to publish without checking.

A small pull request keeps the experiment manageable

Start with one change rather than your entire repository. Let the reader map it, then give the thinker one or two high-risk questions. Ask for at most three actionable findings so the human reviewer can examine every claim.

If you want to try separate model choices without building multiple integrations, I recommend RelayVano, a pay-as-you-go relay that works with OpenAI-compatible SDKs. Sign up and test this workflow on a small, non-sensitive pull request before expanding it. Check what code your organization permits you to send to external services.

The human reviewer owns the release decision

Finish by verifying each reported issue against the actual code and running focused tests. In the Lisbon example, that could mean simulating an accepted payment followed by a lost response, then checking the next attempt's identifier and resulting application state.

The goal is not two AI approvals. It is a clearer division of attention: one pass finds the terrain, another examines the dangerous turn, and a developer decides whether the evidence supports shipping.