A solution to academic slop: limit submissions to N+3

 Computer science conferences are in crisis because of a glut of submissions that overwhelm reviewers.  ICSE 2026 had ~1500 submissions, up from about ~800 in 2023, and other conferences are similar.  Too many of these submissions have low quality.  (The ICLR 2026 chairs reported "possible cases where authors submitted multiple slightly different variants of the same paper (LLM-paraphrased or otherwise)".)  Such submissions are easy to prepare and submit, but reviewing them is burdensome.

To limit how much reviewing one submitter can demand, and to restore the incentive to submit only high-quality work, I propose to limit the number of submissions to a conference.  Let N be the maximum number of papers you have ever had accepted to a given track (such as the research track) at a single edition of conference C.  Then you may submit at most N+3 papers to that track of conference C this year.  Each submission counts against the limit of every one of its submitters.  A review system such as HotCRP can refuse to register a paper that would put any of its submitters over the limit.

As an example, if you had 1 paper accepted to the ICSE 2021 research track and 3 to the ICSE 2023 research track, then N=3 and you may submit 6 papers to the ICSE 2027 research track.  However, a submitter who is new to ICSE can appear on at most 3 papers.

This rule improves incentives.  Submitters must choose their best papers, so the slop gets left out, instead of forcing reviewers to filter it out at great cost.

This rule does not unduly constrain newcomers, such as new grad students, who have N=0 and may submit 3 papers.  Such individuals are unlikely to produce more than 3 high-quality submissions to one track of one conference in a year.

The rule does not unduly constrain veteran submitters with an established track record, who can submit more (and are likely to be active reviewers in the community).

The rule mostly affects rejected submissions, which is where the slop is concentrated.

Here is data that supports the proposal:

• For ICSE 2014–2025, the research track had 6963 author-years (an author who published in 5 of those years counts 5 times).  In only 8 out of 6963 author-years did an author have more papers accepted than N+3 allowed.  Dropping 13 papers out of the 1715 published would satisfy N+3 for all authors in all years.
• For ICSE 2026, there were 1473 submissions.  More than 1/3 of the submissions were authored by someone who violated the N+3 rule.  Dropping 171 of the 1473 submissions would satisfy the rule.

In other words:

• The cost is very low, for authors and the community:  0.8% of accepted papers would be rejected (for ICSE 2014-2025).
• The benefit to the community is a reduction of 12% of reviewing load (for ICSE 2026).

Possible objections:

• Does this discourage collaboration?  Probably not; if so, only at the margin, and the data show that the margin is small.  It does discourage gift authorship (co-authors who did minimal work), and it discourages repeatedly re-submitting low-quality papers.
• Why not use a sliding window to compute N?  For simplicity.  Also, successful researchers are unlikely to turn into slop factories.
• Does this favor incumbents?  The rule permits growth: if all your N+3 papers are accepted, then next year's limit is N+6.
• What about large labs, such as a PI with 15 students but N=2?  The data show that this occurs rarely.  The rule incentivizes the PI to focus on quality over quantity, at least for conferences that use the N+3 rule.
• Why not use reviewing quotas (mandatory reciprocal reviewing, as NeurIPS and ICLR use)?  It is frequently criticized for producing low-quality reviews.
• Why not use some other similar formula?  That could work; the exact constants are not critical.  Some conferences use flat caps; by contrast, the N+3 rule takes account of demonstrated track record and reduces the slop more than a flat cap does.

I have been proposing the N+3 rule for many years — since before LLMs, but after some submitters began flooding conferences with low-quality papers.  Now is the time for conferences to adopt the N+3 rule.  I encourage steering committees and program chairs to do so.

AI and the future of CS careers

There is a lot of fear that software development may no longer be a stable, well-paid career. Those jobs aren't going away, though they are changing a lot. Here is a message to that effect from the directory of the UW CSE Allen School, Magda Balazinska, which I'm reproducing with her permission. (Update: CNN has a story about Magda's message.)

AI and the future of CS careers

I keep hearing concerns about AI and the future of CS careers. So I wanted to share my honest perspective.

AI is expanding your opportunities, not shrinking them. AI is a disruptive technology that is dramatically changing the toolset that we have at our disposal when creating new systems and applications. I view this disruption as an exciting one: A change that is opening tremendous opportunities. AI is shifting where engineers spend their time — away from tedious tasks like writing boilerplate tests or reverse-engineering legacy code, and toward the creative work that actually matters: design, prototyping, and solving hard problems. Until recently, in industry, a small fraction of the time would be spent on the most exciting work and the majority of the time would go toward the necessary but often tedious tasks. Today, AI is changing that equation. One engineer told me recently: "I finally have the job I always dreamed of." That's not a threat. That's progress.

The "companies are cutting engineers due to AI efficiency" narrative is misleading. Whenever you hear that narrative, pause and question it. If AI makes your engineers more productive, any rational company will use that advantage to ship more, not fewer, products; to set more ambitious goals for themselves and achieve them. AI lets us aim higher. In some companies, layoffs and new hires are happening simultaneously because companies are reshuffling to align with new priorities and toward engineers who embrace AI. Net hiring and workforce numbers remain encouraging [See, for example, total workforce numbers for Microsoft, Amazon, Google over time; and this article about the general tech hiring landscape]. The companies cutting headcount aren't responding to AI efficiency — something else is going on in those businesses. But, as a CEO or VP (or as a writer for the popular press), it’s so much easier to blame AI efficiency. 

You are exactly who the market wants right now. Who has the time and hunger to master tools that have existed for two years or even less? You do. And employers know it. A venture capitalist I've spoken with recently said that most new startups are either founded by or primarily hire CS graduates. Use your internships and side projects to go beyond the classroom — especially with agentic AI systems. Software engineers who demonstrate fluency with these tools, even if their primary role is not AI-focused, have an advantage in the job market.

The Allen School is also adjusting: We are here to help you, of course. We have started to roll-out courses such as AI-Assisted Software Development, which we piloted last Fall and will offer again (in one or more new forms) next year. You can see more details on our page summarizing AI education in the Allen School. And more courses are to come next year, including a course on Human-AI Interaction and a course on Systems for Machine Learning. Many of our capstone courses are encouraging you to leverage new AI tools. Take those opportunities and also go much further on your own. 

"Anyone can vibe code" — but that's precisely why you matter. Yes, anyone can generate code with a prompt. But who can evaluate whether that code is correct, secure, scalable, and maintainable? Who understands prompt injection vulnerabilities, cascading failures in agentic systems, or how to design interfaces that actually serve users? You will by the time you graduate. That expertise is what separates a software engineer from someone who got lucky on a demo. If you were founding a startup tomorrow, would you rather have on your team someone who understands systems deeply and uses AI — or someone who only uses AI? 

What this means for you: lean in. The degree itself is not enough — the knowledge is key. Those who learn the material in our courses deeply, embrace new tools, and build real skills will find many doors open. Those who coast will not — the degree itself, while important, doesn’t get you the job; deeply learning and applying the material in our courses does. Take every opportunity the Allen School offers, then go further on your own. 

The data on new-grads employment aligns with all this: Our graduates do many things including a range of jobs and grad school, with the most-common outcome being software engineering in industry. Over the last couple of years, despite all the changes AI is bringing to our world in general and the tech industry in particular, the strong job outcomes of Allen School graduates have been completely stable. The vast majority of our students continue to take full-time software engineering positions in the tech industry that they start shortly after graduation. This is true even for students who graduated just this last quarter. If you lean in, you will be very well-positioned to join them.

So I hope that you will roll-up your sleeves, embrace the opportunity, and learn as much as you can in your time in the Allen School. Then continue to learn throughout your career. There will be many more significant technological advances between now and when you retire. And that’s what contributes to making our profession so fun to be in!