Icse Related Work

---
name: icse-related-work
description: Use when building the related-work and positioning sections of an ICSE research-track paper, covering the literature lanes SE reviewers check, searching ACM DL, IEEE Xplore and dblp across the flagship venues, staying current in fast-moving areas like LLM4SE, and keeping self-citations double-anonymous.
---

# ICSE Related Work

Positioning at ICSE is scored twice: once under novelty ("sufficiently
original with respect to the state-of-the-art", per the 2027 criteria read
2026-07-08) and once implicitly when the assigned reviewers — likely authors
of the nearest prior work — check whether they and their neighbors are
represented fairly. Cover the lanes below before writing a word of the section.

## The five lanes an SE reviewer sweeps

| Lane | Where it lives | What missing it costs you |
|---|---|---|
| Flagship conference line | ICSE, FSE, ASE, ISSTA proceedings (ACM DL / IEEE Xplore) | The direct-competitor omission — often the reviewer's own paper |
| Journal line | TSE, TOSEM, EMSE | Mature versions of "your" idea; journals often published it first |
| Specialized venue line | MSR, ICSME, ICPC, SANER, RE, SPLC, ESEM per subfield | Reviewers from that subcommunity notice instantly |
| Preprint line | arXiv cs.SE (critical in LLM4SE, AI-for-SE) | Staleness: in fast lanes, six months of preprints can contain your contribution |
| Adjacent-field line | PL (PLDI/OOPSLA), systems, ML, HCI as relevant | Reinvention accusations from cross-listed reviewers |

Search all three indexes — ACM Digital Library, IEEE Xplore, and dblp —
because ICSE's own proceedings historically alternate between publishers and
no single index has everything; dblp is the neutral spine for coverage
checking, the DLs for full text.

## Currency in fast lanes

LLM4SE and AI-for-SE turn over in months. For a June 30 submission, run a
final sweep in the last two weeks: new arXiv postings, the just-published
ICSE/FSE proceedings, and the accepted-papers lists that venues post before
official publication. Concurrent work (public after your study was designed)
deserves acknowledgment, not competition: cite it, mark it concurrent, and do
not contort your evaluation to beat a paper that appeared last month —
reviewers understand timelines and respect the candor.

## Writing the section as an argument

The section's job is a *delta statement*, not a bibliography. Organize by the
dimensions on which you differ, then place each cluster:

```markdown
## Related Work (delta-first pattern)

**Test-suite-based repair.** [Cluster: GenProg lineage, semantics-based
repair.] These validate candidate patches against the failing suite; all
inherit test-suite overfitting. *We differ:* our oracle is X, so overfitting
of type Y cannot occur by construction (§4).

**LLM-based patch generation.** [Cluster: 2023–2026 line, incl. concurrent
work.] These generate candidates but keep suite-based validation. *We
differ:* evaluation on post-training-cutoff bugs (§5.2) removes the
contamination confound these papers share.

**Empirical studies of overfitting.** [Studies motivating the problem.]
We *build on* their measurement protocol and extend it to Z.
```

Every cluster paragraph ends with the difference stated in your paper's own
technical terms, with a section pointer. If a cluster ends with "...has also
studied this area", it is filler.

## Double-anonymous self-citation

ICSE reviews double-anonymously, and prior-work references must be third
person: "Prior work introduced FOO [12]" rather than "In our earlier paper
[12]". The subtle leaks: citing an unpublished technical report only your
group could know, an artifact URL from your prior paper's repository, and a
tool name unique to your lab used without citation. If the current paper
extends your own published tool, cite it in third person and phrase the
relationship symmetrically ("extends FOO [12] by...") — reviewers may guess,
but the text must not confirm.

## The nearest-neighbor rehearsal

Before freezing the section, run one simulation: pick the three papers a PC
chair would most plausibly assign as reviewer expertise matches — usually
the three you compare against in the evaluation — and reread your section as
each of those authors. For each, answer: is my paper described accurately
(not straw-manned)? is the difference stated in terms I would accept? is my
most recent relevant paper present, or only my old one? A misdescribed
neighbor produces the angriest review in the packet, and it is entirely
preventable at the cost of an hour.

## Verification discipline for the bibliography

- Every citation checked against dblp or the DL record — titles, venues,
  years drift when copied from other papers' bibliographies or generated by
  models; a hallucinated reference discovered by a reviewer poisons trust in
  everything else.
- Cite the archival version over the preprint when both exist; keep arXiv
  IDs for preprint-only work.
- Distinguish venue tiers honestly: a workshop paper and an ICSE paper by the
  same authors are different maturity claims.
- Normalize venue naming (e.g., ESEC/FSE vs FSE across years) so reviewers
  recognize the venues at a glance.

## Output format

```text
[Lane coverage] five lanes -> swept on <date> / gap
[Delta table] nearest neighbors -> difference in our terms -> section pointer
[Currency] last sweep date; concurrent-work items flagged
[Anonymity] self-citation phrasing audit: violations found/fixed
[Bibliography hygiene] unverified entries remaining (must be zero)
```