Repository Tests With a Per-PR Token Budget

A coding agent can produce tests faster than a team can review them. Across a large repository, that creates a management problem: deciding which behaviors deserve coverage, what counts as a trustworthy assertion, and how much compute each change should consume. The useful unit of work is a reviewed patch with evidence that its tests detect the intended failure.

For team leads running sustained workloads, test generation needs the same controls as any production pipeline: bounded jobs, explicit acceptance criteria, measurable costs, and someone responsible for the result.

01 · Build a test backlog around failure consequences

Start with a repository map: packages, owners, test commands, shared fixtures, external dependencies, and slow suites. Ask the agent to inspect existing conventions before editing. A test that bypasses the repository’s normal setup can pass locally while adding maintenance work elsewhere.

Prioritize behaviors where a missed defect has a clear consequence. Recent regressions, permission checks, parsing boundaries, and retry logic are useful candidates. Coverage reports can reveal unexplored code, but a higher percentage alone does not establish that important behavior is protected.

• › Specify the behavior: Describe an observable outcome, including relevant boundary and failure cases.
• › Bound the patch: Name the package, permitted files, and test command. Require a separate proposal for production changes.
• › Define completion: Require passing checks, an explanation of the assertions, and evidence that the test catches the targeted defect.

02 · Give the agent an independent source of expected behavior

The central risk is circular reasoning. An agent can read an implementation, reproduce its logic in a test, and confidently preserve the same bug. Give it a stronger basis for expected results: a documented contract, an accepted bug report, a worked example, or a property that must always hold.

For a serialization function, that property might be that decoding an encoded supported value preserves its meaning. For access control, it might be that changing a resource identifier never grants access to another account’s data. Reviewers should be able to explain why each assertion is correct without following the implementation line by line.

Where practical, verify sensitivity by temporarily reintroducing the reported bug or applying a narrow mutation in an isolated workspace. Confirm that the intended assertion fails, then restore the correct code and rerun. A failure caused by broken setup proves little about defect detection.

03 · Schedule bounded jobs with a per-patch spending limit

Repository-wide instructions such as “add missing tests” create unpredictable context growth and overlapping edits. Dispatch smaller jobs against a recorded revision, each with its own workspace, execution timeout, and token budget. Limit concurrency according to runner capacity and provider limits; queued agent work still competes for databases, build caches, and integration environments.

Use staged execution: inspect the target, propose cases, generate a patch, run focused tests, and expand validation when shared behavior warrants it. Stop repeated repair attempts at a defined limit and return the evidence to a maintainer.

Quanta fits teams that want one pay-as-you-go balance across models and compatible coding tools. A team could evaluate Claude Sonnet 5.5 and GPT-6 Astra on the same representative backlog, comparing accepted patches, review effort, and total spend. Quanta meters actual tokens and prices cache writes and reads separately, so repeated repository context deserves explicit accounting. Open a Quanta account to trial that workflow within a capped pilot.

04 · Make generated tests part of ordinary ownership

Require the same review standard as human-written tests. Prefer public behavior over private implementation details, deterministic fixtures over live services, and assertions that explain failures. Check for clock dependence, leaked state, excessive mocking, and snapshots whose size makes meaningful review difficult.

After merge, package owners should maintain generated tests alongside the code they protect. Track flaky failures, runtime growth, reviewer rework, and accepted patches per unit of spend. When behavior changes, update the underlying contract before asking the agent to repair assertions. That prevents automated maintenance from quietly teaching the suite to accept a regression.