Architecture-aware automated program repair shows feasibility without success
ArchGuard-APR: Architecture-Constraint-Aware Multi-Agent Program Repair Using Repository Graphs and Execution Feedback
Software Engineering
Summary
Fixing computer programs automatically can be tricky when changes might break important connections within a whole project. The authors built a system to help repairs follow the project's structure and use feedback from tests, but their early tests showed no successful fixes. The study mostly proves it’s possible to combine these ideas in one tool and points out where improvements are needed. It’s a first step, not a finished solution.
What this means in practice
- •For software maintenance teams: Use architecture-aware tools to guide automated patches that respect project-wide dependencies and context.
- •For software infrastructure engineers: Develop more robust program repair systems by integrating isolated execution feedback and repository structure analysis.
Authors
Majid Feiz Deilami
Abstract
Repository-level automated program repair must reason about more than a localized failing statement. A candidate change can satisfy a narrow test while violating dependency boundaries, modifying an unsafe path, or relying on context that omits relevant repository structure. ArchGuard-APR is an architecture-aware repair prototype that integrates deterministic repository analysis, immutable repository graphs, explicit architecture profiles, graph-guided context retrieval, role-based repair orchestration, patch-policy enforcement, isolated execution feedback, provider cost controls, and canonical source-free evidence. We evaluate the implemented pipeline through an exploratory paired feasibility study, not a confirmatory effectiveness experiment. Six executions were planned; four completed, and two black-4 conditions ended in pre-provider infrastructure attrition. Across two valid paired tasks, baseline and ArchGuard conditions each produced 0/2 successful repairs, and all four completed outputs were classified as invalid patches. The completed executions consumed 35,431 input tokens and 2,737 output tokens, for a total of 38,168 tokens, at a total cost of USD 0.1296325. No effectiveness advantage was observed, and the sample provides no useful inferential basis. The study instead establishes the engineering feasibility of composing architecture constraints with a reproducible repair pipeline and identifies patch validity and infrastructure robustness as the principal targets for future work.