what llms are doing to conference programs, and how to use them effectively if you're going to do it anyway | dian m fayWhat LLMs are Doing to Conference Programs, and How to Use Them Effectively if You're Going to Do It Anyway<br>postgresql<br>speaking<br>I'm lately back from Chicago, where PG DATA 2026 is now in the books! This is the two-day successor to PGDay Chicago, where I've been involved for the past few years volunteering, speaking, and finally organizing (and also volunteering and speaking). Everything went blessedly smoothly with only a few close calls, and we're already starting to plan next year's event.
I've been on program committees for a few years now: besides prior PGDays in Chicago, I participated in the committees for PGConf EU Athens in 2024 and PGDay Armenia earlier this year. PG DATA is my first time chairing the committee, and I am immensely thankful for Karen Jex's tutelage. This is just long enough, just widely enough, at just the right historical moment, to have a front-row seat for a transition that's making talk selection much, much harder.
Fundamentally, assembling a conference program has worked like this: interested speakers submit abstracts that describe briefly their topic and goal. The committee deliberates, usually through some kind of voting mechanism. They rank a longlist, then draw a shortlist from it attempting to balance factors including topic variety, skill level coverage, diversity of speaker affiliation (half your speakers being from a single company doesn't look great at community-run conferences), and more. This makes up the bank of accepted talks and the reserve list in case accepted speakers cancel. Once speakers confirm acceptance, the committee plays schedule Tetris until things look like an event people want to go to.
It still works like that. What's changed, as far as talk selection goes, is that it is now possible to generate a superficially polished abstract with minimal effort and near-zero subject matter knowledge. You can demand an LLM "generate an abstract for an XYZ conference" with no more context than that, and receive a statistically plausible derivative of the conference abstracts and information about XYZ it was trained on. It will flow like a real abstract, it will build up something like sense by alluding to relevant associations, it will list things in threes, just so. You can even tell the model to generate a speaker biography next, and it will need only a name to call you an active member of the XYZ community who is passionate about sharing lessons learned from using XYZ in production and other waffle. You could go further, if you wished.
Maybe, though, you're more judicious. You wouldn't vibe up an entire proposal and send it. Maybe you'd take the generated abstract as a starting point, review it closely, make some edits that bring it more in line with your idea and what you think the program committee are after; LLMs aren't perfect, after all. Maybe you'd go several iterations like this. Maybe you'd take a different tack and draft an abstract yourself, then push it to the LLM for a round of polishing. I'm positive people took every approach possible, and for many different reasons. I'll talk about reasons, but first:
Some Numbers
For PG DATA 2026, we had room on the schedule for 30 talks. Given everything the committee has to balance, I'd guesstimate a 2x ratio of individual speakers on the longlist to slots on the schedule is about the minimum for us to get everything we want, since beyond the previously mentioned constraints, almost everyone prefers to schedule, give, or hear one talk per speaker per conference. In our case, we also needed a healthy reserve list; under the current administration, the risk of speakers from overseas being arbitrarily prevented from entering the US is non-negligible, even if they do everything right and apply for visas well ahead of time. We ended up replacing two accepted talks because of that.
To start with, we had 117 abstracts from 75 speakers, since we allowed up to three submissions per speaker and a few submissions had two speakers. A 2.5x speaker:slot ratio is a pretty good start!
However, sixteen abstracts from twelve speakers didn't even mention Postgres. Some were roughly in the neighborhood -- data- or analytics-flavored LinkedIn thought leadership glurge -- while others proposed fully irrelevant subjects, in the same style. These universally had that subtle slipperiness to the prose that bespeaks LLM-generated text, along with the obvious hallmarks like overworked rhetorical devices, lists, choppy sentences, triples, and key takeaways.
I don't have a good baseline to compare the count of irrelevant abstracts against, since we switched to Sessionize for program management this year. Many Postgres conferences use community-built submission software, which additionally requires a postgresql.org account; Sessionize is a general-purpose system that allows prospective speakers to apply to all...