ase-related-work

ASE Related Work

Position the paper against prior automation, not against a topic. At ASE the question a reviewer holds is "what does this tool/technique do that the existing automated approaches do not?" — so related work is a delta argument, and the strongest deltas are stated against named, runnable prior tools you can (and often must) compare against empirically.

Cover the ASE literature lanes

An automated-SE paper usually sits at the intersection of several lanes; name your position in each that applies:

• Program analysis — static/dynamic analysis, symbolic/concolic execution, abstract interpretation, invariant inference.
• Test generation and testing — search-based, specification-based, fuzzing, regression and flaky-test handling.
• Fault localization, debugging, and repair — spectrum-based localization, automated program repair, patch synthesis.
• Synthesis and recommendation — program/code synthesis, API recommendation, refactoring automation.
• Comprehension and documentation — summarization, code search, clone and change analysis.
• Learning-based / AI4SE — learned code representations, models applied to SE tasks, LLM-based automation — and SE4AI, applying SE automation to ML systems.

Delta-first positioning

Write each related-work cluster as: prior automation X does A; it cannot do B because C; we do B. Then, where B is comparable, compare against X empirically — ASE reviewers expect a head-to-head against the closest runnable baseline, not just a prose distinction.

[Cluster] spectrum-based fault localization
  Prior: ranks statements by suspiciousness from pass/fail spectra.
  Gap: assumes a fixed test suite; degrades when tests are flaky.
  Delta: our technique estimates and corrects for flakiness before ranking.
  Evidence of delta: head-to-head on the same faulty subjects, §5.2, Table 3.

Fair head-to-head framing (the ASE credibility test)

• Compare against the strongest, most recent automated baseline you can run, at an equal, documented budget (time, iterations, tuning). An under-configured baseline is the classic soundness objection and a Revision criterion waiting to happen.
• If a baseline tool cannot run on your subjects, say why explicitly and choose the nearest viable alternative — do not quietly omit the obvious competitor.
• Distinguish reimplementation from the original tool, and note version/commit — reviewers who built the baseline will check.