From a repository issue to a reviewed change

This worked application uses explicit planning assumptions to demonstrate FIELD. Quantities below are inputs, calculated implications or proposed targets; they are not reported customer results. The engagement decision remains conditional on the evidence described.

Planning basis and engagement boundary

F — Frame the outcome

Reduce maintenance effort by delivering reviewable patches while the repository owner retains merge authority.

Value measure: Maintainer time per accepted patch and post-merge regression rate.

I — Investigate the workflow

Observe issue types, review bottlenecks, flaky tests, environment setup and what evidence reviewers need to trust a change.

First evidence task: Cancel a test run, alter the base revision and verify stale evidence is rejected.

E — Engineer the solution

Preserve isolated workspaces, base/patch identity, bounded execution and test provenance; size sandbox CPU/RAM/disk and native threads.

The implementation assessment below makes the authority, workload, resource and failure assumptions concrete. Its numbers are calculations from the stated scenario, not a vendor performance guarantee.

Contract

Limit initial tasks to bounded maintenance changes with reproducible builds and independent acceptance criteria. The agent may inspect, edit and test in isolation; a human retains merge authority. Repository files, issue text and tool output are untrusted inputs for authority purposes.

Implementation plan

Task intake freezes base revision and scope→repository/code retrieval→plan→ephemeral workspace→patch/test loop→independent verification→reviewable diff/evidence. Record commands, test results, dependencies and artifact hashes. Give the sandbox only required files/network, no ambient production secrets and bounded process/resource lifetime.

Sizing

At 100 concurrent jobs with an illustrative reservation of 2 logical CPUs and 4GiB RAM each, reserve 200 logical CPU units and 400GiB RAM, plus orchestration/storage overhead. These are workload envelopes to profile, not performance guarantees. If every build launches eight threads, CPU quotas and nested parallelism still control actual execution; thread count does not create 800 cores. Budget disk per workspace, package-cache traffic and model quotas independently.

Failure/control

A repository instruction cannot authorize exfiltration or broaden filesystem access. Flaky tests require rerun history and an explicit uncertain result, not arbitrary repeated attempts until green. Reject attempts to weaken tests or change unrelated acceptance criteria without authorized scope; independent hidden checks run outside agent access. On cancellation, kill the process tree and clean temporary credentials/artifacts.

Evaluation

Measure correctly accepted changes, regression/escaped-defect rate, reviewer minutes and end-to-end cycle time. Compare against ordinary human/AI-assisted baseline with comparable issues. Passing agent-written tests is supporting evidence only. Include dependency/build failures and incomplete tasks in denominators.

Rollout

Begin with low-risk repositories/task classes, require human review and expand based on observed defect and review burden. A platform should produce auditable patches even when it cannot complete the issue.

L — Launch with evidence

Pilot bounded issue classes and compare accepted patches, reviewer effort and regressions with current maintenance. Report unrun tests honestly.

Critical decision condition: Unauthorized workspace access or false claims of executed tests block release.

Attach raw artifacts, the tested configuration, population, denominator, date and limitations to the release record. Missing or stale evidence holds the dependent decision. A favorable value forecast cannot offset a failed critical condition.

D — Develop ownership and reuse

Maintainers own acceptance and the platform owner owns sandboxes; hand over reproducible execution and cleanup procedures.

Candidate reusable asset: Patch-bound evidence bundle and sandbox recipe.

Commercial decision and next commitment

Accountable decision owner: Repository maintainer with execution-platform owner.

The initial commitment is the bounded journey above, with the stated exclusions. Confirm access, customer staffing and acceptance ownership during discovery; price and schedule unresolved dependencies explicitly. A new source, tenant class, language, action or operating envelope requires an impact review rather than silent scope growth.

Approve only the next exposure level supported by the evidence. The next useful investment is: cancel a test run, alter the base revision and verify stale evidence is rejected.

Method and references

Apply the FIELD method, economic model and evidence rules. Methodological and technical influences are listed in the source register.