Tracing a Checkout Bug in a Retail Team’s Monorepo

Imagine a retail team with a checkout bug to fix before Friday’s release: a discount appears correctly in the shopping cart but disappears at payment. The storefront, checkout service, and shared pricing code all live in one repository. A developer asks a coding agent to investigate.

That request starts a walk through a monorepo. Watching the steps makes the agent less mysterious—and shows where human judgment still matters.

The checkout task starts with boundaries

A monorepo is one version-controlled repository containing several applications or packages. Sharing a repository makes related changes easier to coordinate, but it also gives an investigator more places to look.

A coding agent combines an AI model with tools that can inspect files, search text, run commands, and sometimes edit code. It does not automatically understand everything in the repository. It builds a working picture from the material it reads and the results its tools return.

A useful first request is specific: “Investigate why checkout drops the discount shown in the cart. Find the cause, propose the smallest fix, and run relevant tests. Do not change payment-provider integrations.” That gives the agent a target and a boundary.

Repository files become the first map

Before changing anything, the agent should inspect the repository’s layout and local instructions. A root README might describe the applications. Workspace configuration might list packages. An agent instruction file might specify test commands or prohibit editing generated files.

In our example, the first useful landmarks could be:

• apps/storefront: the customer-facing cart and checkout screens.
• services/checkout: the service that prepares payment requests.
• packages/pricing: shared discount calculations.
• packages/contracts: request and response definitions used across applications.

Folder names are clues, not proof. The agent still needs to check which packages import each other and which commands actually run their tests.

The discount travels across package boundaries

The agent searches for the discount field, the checkout endpoint, and references to the pricing package. Searching for a distinctive field name is usually more productive than opening every file.

Suppose the storefront sends a discount identifier, but the checkout service rebuilds the order total without passing that identifier to the pricing function. The agent now has a possible explanation. It should read the surrounding code and the shared contract before treating that explanation as established.

This is the central monorepo challenge: a symptom in one application can originate at a boundary between packages. The job is to follow the data, not simply edit the first file containing the word “discount.”

Selective reading keeps the investigation focused

A model has a limited working context: the instructions, file excerpts, and tool results available for its next decision. A large repository will not all fit there, and reading everything would waste time anyway.

A sensible agent narrows its search, reads relevant functions, and checks nearby tests. It may keep short notes about what it has established. Those notes help maintain direction, but they are not evidence on their own. Important conclusions should remain traceable to actual files or command output.

A regression test separates a theory from a fix

Before patching the service, the agent should add or identify a test that reproduces the missing discount. Ideally, that test fails for the expected reason before the change and passes afterward.

The smallest repair might be forwarding the missing identifier through an existing function call. Afterward, the agent can run the checkout tests, relevant pricing tests, and the workspace’s applicable type checks. It should inspect the final diff for unrelated edits.

A passing narrow test does not prove the entire system is correct. The final report should name the commands run, disclose anything blocked by missing credentials or dependencies, and distinguish local checks from a full payment-flow test.

The developer reviews evidence, not confidence

The useful handoff is a short account of the cause, changed files, test results, and remaining uncertainty. The developer reviews that evidence before merging. Tool permissions still matter: an investigation should not quietly become permission to deploy or access production secrets.

For developers choosing model access for their coding tools, RelayVano is worth considering: its pay-as-you-go relay works with Claude Code, Codex, Gemini CLI, and OpenAI-compatible SDKs, with the API base at https://api.relayvano.com. Sign up to try it with a small, bounded repository task—and judge the agent by the trail it leaves behind.