Top-AI-Conferences-Paper-with-Code: A Markdown Index of Conference Papers That Ship Code

The gap this index fills: papers whose implementation details live outside the PDF

Conference papers are page-limited, and the README states the motivation plainly: a paper's length usually cannot cover every implementation detail, while the accompanying open source code carries more reproducibility information and makes follow-up work easier. That is the problem being addressed. A reader who wants to reproduce a result, or simply wants to know whether a method was ever implemented, otherwise has to check the paper, the supplementary material, the authors' homepages, and a general code search separately.

This repository collapses part of that search into a set of Markdown files, one per conference per year. It is aimed at graduate students and researchers who track specific venues (ACL, EMNLP, NAACL, COLING, AAAI, IJCAI, ICLR, NeurIPS, ICML) and want a browsable list rather than a search engine query. It is also useful to someone entering a subfield who wants to see which recent papers in a venue came with code at all. The scope is deliberately narrow: the repository indexes papers, it does not host, mirror, or vendor the code itself.

Directory layout: one Markdown file per conference per year

The mechanism is a directory tree keyed by conference acronym, then by year, then by a single Markdown file. The README's support table links to paths such as ACL/2024/ACL2024.md, EMNLP/2023/EMNLP2023.md, ICLR/2025/ICLR2025.md and ICLR/2026/ICLR2026.md. Note that the filename casing is not uniform across conferences: NAACL uses naacl-2019.md and naacl-2021.md for the older years and NAACL2022.md, NAACL2024.md, NAACL2025.md for the newer ones. COLING starts at 2018 rather than 2019, and the AAAI 2021 cell points at a different repository path (MLNLP-World/NLP-Conferences-Code) than the rest of the table, which suggests the collection was assembled over time from more than one source tree.

There is no database, no generated site, and no query layer. The data flow is: a contributor edits a year file, opens a pull request, and the change lands on master. Consumption is equally direct: you open the raw Markdown on GitHub, or clone the repository and grep it locally. That flat structure is the whole architecture, and it explains both the project's low maintenance cost and its main weakness, which is that nothing validates whether a listed link still resolves.

Getting the index onto your machine

Because the repository is a set of Markdown files, there is nothing to build. The README does not document an installation step, a package, or a CLI, and no releases are listed for the project. The practical workflow is a clone followed by local search:

git clone https://github.com/MLNLP-World/Top-AI-Conferences-Paper-with-Code.git cd Top-AI-Conferences-Paper-with-Code grep -ri "keyword" ACL/2024/ACL2024.md

That last command is the part the GitHub web interface does not give you well: searching across many year files at once. If you would rather not clone, the README's table is the entry point, and each cell is a direct link to the corresponding year file on the master branch. There are no configuration keys to set, no environment variables, and no dependency manifest in the material provided. Treat the repository as a text corpus, because that is what it is.

Where the index is thin, and the cases it handles badly

The support table is the most honest part of the README, because the gaps are visible. ACL stops at 2025 and has no 2026 column. EMNLP, NAACL, COLING, AAAI and IJCAI likewise have no 2026 entry. NAACL has no 2020 and no 2023 in the table. COLING has no 2021 and no 2023. NeurIPS and ICML appear in the README's prose description of what the repository collects, but the visible portion of the support table does not show rows for them, so their coverage cannot be confirmed from the material at hand.

The second limitation is freshness at the link level. A year file is a static list; when an author moves a repository or a project goes private, the entry does not update itself. Nothing in the repository as described checks link health. The third is selection bias in the other direction: the index only contains papers whose code someone chose to record. A paper with a released implementation that no contributor added will be absent, and absence here is not evidence that no code exists. If your question is "does this specific paper have code," a general code search or the paper's own page answers it faster than a directory that may not have been updated.

Papers with Code and Semantic Scholar: different mechanisms, different freshness

The obvious alternative is Papers with Code, which links papers to implementations through an automated pipeline that associates arXiv entries with repositories. The difference in approach matters. Papers with Code scales by crawling and matching, so coverage is broad and updates continuously, but the association is inferred and can be wrong or noisy. This repository scales by human contribution, so entries are deliberate and venue-scoped, but coverage is only as wide as the contributor base and only as fresh as the last push (the README's update log records edits on 2026.7.1 and 2026.7.2, adding ICLR2025 and ICLR2026).

Semantic Scholar occupies a third position: it is a paper metadata and citation graph, and code links are one attribute among many rather than the organising principle. If you need citation counts, related-paper traversal, or an API, Semantic Scholar is the right tool and this repository is not. If you need a venue-first list where every row was placed by a person who judged the code worth linking, the manual approach has an advantage that automated matching does not: the contributor has usually looked at the repository. The trade is that you cannot tell from the outside how recently they looked.

Maintenance cost and the licence question

The README marks the project version v0.1.0 and carries a Status-building badge, which is a fair description of a collection that is still filling in cells. Contribution is open: the README welcomes issues and pull requests for additions and corrections. For a user, the ongoing cost is near zero, since there is no dependency to upgrade and no service to keep running. For a maintainer, the cost is the recurring labour of adding each new conference cycle and of responding to link rot, and the update log shows that labour happening in bursts rather than continuously.

On licensing, the material provided does not state a licence for the repository. The metadata field is empty and the README does not name one. That matters more here than for a typical code project, because the repository redistributes paper titles and links. Titles and links are generally not the same as the papers themselves, but the repository's own terms of reuse are undefined, so anyone planning to mirror the files, republish the tables, or fold the data into another index should confirm the licence with the maintainers first. This is a factual gap, not legal advice.

What to check before you depend on a year file

The repository is a useful first pass and a poor last word. Before you cite it, build on it, or use it to claim that a venue's code-releasing papers are covered, open the specific year file and inspect it: how many entries it holds, whether the entries carry a consistent format, and whether the papers you already know about are present. If a paper you know shipped code is missing, that tells you the file is incomplete rather than that the code does not exist, and you should fall back to the paper's own page or an automated index.

The project is best understood as a curated reading list with a conference-shaped filing system. Its strongest feature is the same as its weakest: everything is plain Markdown on master, so you can read it, diff it, and grep it without tooling, and nothing guarantees it is complete.

Editorial conclusion

Use this repository if you need a conference-scoped starting list of papers with released code and you are willing to open the individual year file to check its coverage. Do not use it as a citation source, a completeness guarantee, or a substitute for the official proceedings, because the README states the project is still building and several conference-year cells are empty. Before relying on any single year, open that conference's Markdown file and confirm the paper you care about is listed, since the index only reflects what contributors have submitted up to the last push.

Official sources

1. Issues
2. MLNLP-World/Top-AI-Conferences-Paper-with-Code on GitHub
3. README