The question.
Code generation is only one part of software delivery. Repository context, test selection, change scope, and reviewer understanding decide whether a patch is useful.
The design uses isolated workspaces and explicit engineering checks. Agents propose changes; repository policies and human review govern integration.
The proposed approach.
- Gather relevant source, tests, and local repository guidance
- Plan a bounded change and work in an isolated checkout
- Run focused tests and inspect the diff for unrelated edits
- Produce a change explanation with observed validation results
Target architecture.
IssueRepository contextChange planIsolated workspaceChecksReviewable patch
The difficult parts.
- Underspecified issues and hidden dependencies
- Tests that pass without exercising the real behavior
- Scope expansion and noisy patches
How to evaluate it.
- Task resolution on repository-specific issues
- Regression rate and reviewer correction effort
- Tool cost and elapsed time per accepted change
Planned deliverables.
- An issue-to-patch reference workflow
- A repository-aware task evaluation set
- A structured reviewer handoff format
Design principles.
Keep a patch small enough to understand.
Report what was tested instead of declaring a change correct by intuition.