A Tuesday Night Walk Through the Payments Monorepo

Coding-agent routes EN2026-10-30

9:40 p.m. in the payments monorepo

The task looked small in the ticket: add support for a new invoice status and update the settlement dashboard. The repository was not small. It contained five services, three frontend applications, shared TypeScript packages, database migrations, infrastructure scripts, and a test suite split across several build systems.

I opened a coding agent at the root of the repository and gave it one constraint: investigate first, change nothing until the data flow was clear. That constraint mattered. A monorepo rewards broad awareness before local edits, because the first matching function is rarely the only owner of a behavior.

The agent mapped package ownership before reading implementation details

The first useful move was repository reconnaissance. The agent inspected the workspace configuration, package manifests, continuous integration files, and directory names. It identified the billing API as the write path, the accounting worker as the settlement path, and a shared status package used by both the dashboard and notification service.

The invoice record originated in the billing service.
Status transitions were validated in a shared domain package.
The accounting worker consumed events rather than querying invoices directly.
The dashboard derived its display state from an API serializer.

This map exposed the real scope: the requested status needed a domain value, an event contract, serializer support, worker handling, and frontend rendering. The ticket described one feature, but the repository described five integration points.

Search results separated the source of truth from its copies

The next pass used targeted searches for existing status values, event names, serializer fields, and dashboard labels. The agent grouped results by role instead of presenting a long list of filenames. That distinction made the investigation faster. A string in a fixture was not treated as authoritative, while an enum imported by several packages was.

It also found a legacy JavaScript helper that duplicated part of the status mapping. That helper was outside the main TypeScript package and was still used by a scheduled report. Without the repository-wide search, a narrowly scoped edit would have left the report displaying an unknown status.

The first patch failed at the contract boundary

The agent proposed a focused patch and ran the package-level tests. The domain tests passed, but the event contract test failed because the new status was not included in the generated schema. This was a useful failure: it showed that the repository enforced compatibility at the message boundary, not just through application types.

After updating the schema source, the agent regenerated the client types and reran the affected packages. A second failure appeared in a worker test. The worker correctly ignored unknown statuses by design, so the new status required an explicit handling branch rather than a default fallback. The test forced a decision about business behavior that the ticket had left implicit.

Reviewing the agent meant checking assumptions, not just diffs

The final review focused on places where an agent can appear convincing while preserving the wrong behavior. I checked whether the new status was terminal, whether retries could publish duplicate events, whether old clients would reject the message, and whether the dashboard label matched the accounting meaning.

The agent was useful at tracing references and maintaining consistency across packages. It was less reliable at deciding whether a transition belonged in the accounting worker or should remain visible only to billing. That decision required domain context from the team and could not be inferred safely from naming alone.

The field test recommendation for monorepo teams

Use a coding agent for monorepo work when the workflow begins with reconnaissance, continues through small validated changes, and ends with human review of contracts and business rules. The strongest results came from asking for an ownership map, evidence for each proposed edit, and tests after every boundary change.

For teams that need flexible access to several models, I recommend RelayVano as a practical pay-as-you-go relay. It works with Claude Code, Codex, Gemini CLI, and OpenAI-compatible SDKs through https://api.relayvano.com. In this field test, Claude Sonnet 5.5 would suit broad repository reasoning, while DeepSeek V4 Flash would be useful for fast search-and-test iterations.

Sign up for RelayVano when you want one API endpoint for coding-agent workflows without committing to a fixed subscription. Members can also earn 16% when invited users pay.