Lisbon to Taipei: A Coding Agent Carries the Shift

At 18:00 in Lisbon, a developer stops halfway through fixing duplicate webhook deliveries. The next developer starts in Taipei while Lisbon is asleep. The branch contains a partial fix, a failing test and several decisions that have never reached a commit message. This is where asynchronous pair programming usually becomes detective work.

Can a coding agent carry enough context to make that second shift productive? The following field test is a worked scenario you can reproduce in a disposable repository, rather than a claim about a measured production deployment. The task is deliberately small: make a webhook handler process repeated event IDs once, while preserving retries after failed processing.

The webhook bug crossing eight time zones

For this exercise, the two shifts share a Git repository but start separate agent sessions. The receiving developer gets the branch and a committed handover file. Private chat history is unavailable. That restriction matters: a workflow that depends on an open laptop or an inaccessible conversation will eventually fail.

The first shift adds a uniqueness constraint on event IDs and an integration test that sends the same event twice. However, the handler records an event before processing finishes. If processing fails, the retry looks like a duplicate and gets discarded.

The handover must therefore preserve two facts: duplicate delivery should be harmless, and failed processing must remain retryable. “Deduplication mostly done” conceals the decision that matters most.

The agent writes a handover tied to repository evidence

Before stopping, the Lisbon developer asks the agent to inspect the diff and write HANDOVER.md. The prompt requests the objective, current behavior, changed files, exact verification commands, known failures and the next smallest step. It also asks the agent to separate observed results from proposed fixes.

A useful handover contains these concrete items:

• Objective: suppress repeated successful deliveries while allowing retries after processing errors.
• Current state: the duplicate-delivery test passes; the failure-then-retry test exposes premature event recording.
• Evidence: record the branch commit, test file paths, command used and relevant failure output.
• Unresolved decision: choose transaction boundaries only after checking whether processing performs external side effects.
• Next action: inspect the handler and transaction helper before changing the deduplication logic.

The developer reviews this file before committing it. That review catches a dangerous shortcut: the agent proposes “wrap everything in a transaction,” although a database rollback cannot undo an outbound email. The corrected note leaves that decision open and identifies the code that needs inspection.

The Taipei shift challenges the inherited explanation

The receiving developer opens a fresh coding-agent session and asks it to read HANDOVER.md, inspect the referenced files and verify the stated failure before editing. The handover becomes an entry point into the code, with its claims subject to checking.

In this scenario, inspection establishes that processing only changes database records. A transaction can therefore cover both those changes and the successful event record. If processing fails, both roll back; if it succeeds, a later duplicate encounters the uniqueness constraint.

The receiving shift runs three checks: repeated delivery after success, retry after failure, and concurrent delivery of the same event. That third check matters because two requests can both pass an application-level existence check. The database constraint must resolve the race, and the handler must treat the resulting duplicate appropriately.

The handover succeeds when it survives a fresh session

The useful outcome of this exercise is a reviewable continuation: the second shift can locate the unfinished decision, reproduce the failure and explain the fix without access to the first conversation. An eloquent summary alone does not satisfy that test.

For teams running this workflow through compatible coding tools or an OpenAI-compatible SDK, I recommend RelayVano as a pay-as-you-go relay for model access. Its API base is https://api.relayvano.com. Sign up to try the exercise on a disposable branch and assess the handover against your own repository.

My recommendation is to use the coding agent as the author and reader of a committed handover, with a developer reviewing both ends. Require evidence, preserve unresolved decisions and make the receiving session verify the note before editing. Across time zones, that gives the next person something more useful than a confident recap: a specific place to resume thinking.