Auditable Code Change Automation

Performance teams can turn one-off memory investigations into a repeatable agent workflow: load profiler traces, ask the agent to write anti-pattern reports with source examples, generate Clang Static Analyzer checks, and open patch batches with syntax checks and rollback points. MOA reports this pattern on OpenHarmony 5.0, where three profiled services produced 13 validated anti-patterns, then synthesized checkers found 10,067 inefficiency instances across seven services. The system generated 769 optimization patches with 92.5% expert acceptance, plus reported average heap and binary-size reductions.

The practical build is a patch queue tied to profiler evidence, not a free-form optimization bot. Each proposed change should carry the trace symptom, the static checker rule that found the instance, the affected symbols, and the validation result. A small pilot can start with one high-memory service and one recurring allocation or copying pattern, then measure how many generated patches a senior performance engineer accepts without rewriting.

Teams maintaining unfamiliar Java repositories can add a feature map as the first artifact in an agent edit flow. FeatX extracts an epic-feature hierarchy, links features to classes, methods, or files, and asks the user to edit the feature list before the agent plans and generates line-level diffs. Its UI also separates feature editing, mapped code inspection, agent planning, and patch review.

This is most useful for product-facing maintenance work where the hard part is finding the code affected by a feature change. In FeatX’s study, workload fell from 12.5 to 7.4 on NASA-TLX against ChatGPT, and function-level modification localization reached 0.385 F1 across 38 feature-editing commits. A team can test the workflow by replaying recent feature commits, checking whether the map points reviewers to the functions they actually changed, then requiring every agent diff to cite the feature nodes and code entities it touched.

C-to-Rust migration agents should keep a repair table keyed to Rust compiler diagnostics. AdaTrans maps error codes to repair templates and Rust documentation snippets, then runs cargo build, tests the translated Rust, and compares output behavior with the original C program. The repair loop also treats syntax, ownership, behavior, and ambiguous failures differently, including different sampling settings by error type.

The near-term fit is file-level migration of self-contained C modules with clear input and output behavior. AdaTrans reports a 95.51% mean compilation pass rate, 81.09% mean solve rate under fuzz-based tests, and 1.19% unsafe file rate on 104 algorithmic problems. A migration team can start by logging every compiler error, chosen repair template, build result, test result, and unsafe use for a small module set. That log gives reviewers a concrete reason to accept, reject, or improve each automated repair.