Research idea

Executable controls for code optimization and generated tests

Day · 2026-07-22 · Software Intelligence

Performance and test-generation workflows can make model output more dependable by combining complementary executable signals: runtime profiles to prioritize static optimization matches, semantic mutations to challenge acceptance tests, and deterministic project scaffolding before behavior-level validation.

3 ideas

Profiler-weighted ranking of static optimization matches

Performance engineers could run MoST-style validated Semgrep rules across a repository, then rank the matches by the runtime share and call context reported by a sampling profiler. MoST supplies reusable candidate transformations across languages and architectures, but a static match does not show whether a location matters for the deployed workload; PerfAgent shows that profiler feedback helps agents cross abstraction boundaries and reach expert-level speedups more often. The concrete change is to give the coding agent only the highest-impact rule matches, re-profile every correct patch, and retain the fastest result rather than the last one. A low-cost check is to compare profiler-ranked and unranked rule matches on the same optimization tasks, measuring successful speedup per attempted edit and validation cost.

Mutation-hardened acceptance tests for performance patches

Maintainers accepting agent-generated optimizations should challenge the affected-test set with plausible incorrect performance patches before labeling the fastest candidate correct. PerfAgent efficiently selects the fastest patch that passes targeted tests, but its own failure analysis notes that narrow testing can miss edge cases. CoHarden shows why a passing test is not necessarily discriminating: rigorous reproduction tests improved repair resolution by 8.5 points, lax tests produced no gain, and misaligned tests reduced it. An optimization loop could generate semantic mutants such as removed bounds checks, altered fallback paths, or unsafe cache reuse, then expand the selective test set until it rejects those mutants. Replaying previously accepted patches with and without this hardening would reveal whether the extra mutation step catches regressions that selective dependency-based testing misses.

Compilation and mutation checks for generated BDD glue code

Teams maintaining Java BDD suites could separate glue-code acceptance into three gates: deterministic framework scaffolding, compilation and static repair, then mutation-based behavior checks. AutoGlue retrieves scenario and repository context, yet only 46.1% of generated implementations were directly usable and execution validation was limited by weak step-level oracles. CATGen shows that fixed skeletons and static-analysis repairs can remove many project-integration failures cheaply; CoHarden shows that an executable test can still accept a plausible but wrong implementation. For each generated step definition, the pipeline should mutate API calls, parameters, or omitted actions and require the enclosing scenario to reject those variants. The first evaluation can compare compilation rate, direct usability, and surviving mutants against AutoGlue’s current generation workflow.