dian m fay

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 kinds of events. This ability to cast a wider net necessarily incurs the cost of evaluating low-quality opportunistic submissions. I think it's very much worth it, but I also got consensus from the rest of the committee to go through and weed them out myself before voting started.

That left 101 abstracts that at least touch on Postgres from 63 submitters, quite close to that 2x threshold. It's true that the eliminated submitters likely wouldn't have bothered if we'd required a community account; it is still rather disconcerting to find the margin that much smaller than you first expect. But I kept seeing more indications of LLM use as I went on.

In all, thirty-one relevant abstracts from twenty-one submitters had me thinking an LLM was involved. Twenty-three abstracts from fifteen of those submitters weren't subtle. One submitted an abstract entirely in the third person past tense ("Firstname Lastname discussed...."). Another left their prompt in the submission.

Were my good-but-hardly-infallible alertness to generated prose disqualifying, the longlist would have either 78 abstracts from 48 submitters, applied conservatively, or 70 abstracts from 42. Either option is well under that minimum ratio, leaving us without enough material to assemble a schedule that satisfies all our topic, level, and other constraints.

We have to have a conference; for that, we have to have material; this is the material we've got. So obviously, we longlisted, then, after deliberation, accepted several submissions that were clearly assisted to one degree or another by an LLM. An abstract that I guessed had been polished artificially wound up being one of my favorite talks of the event, so it certainly wasn't all to the bad!

What's the Problem?

Or, why would I even bring up disqualifying LLM-assisted submissions?

The program committee aren't evaluating your abstract as a standalone text. Their job is to calculate odds that the future session that abstract represents will be something the conference attendees will find relevant, informative, and engaging. Unless some of the committee happen to know you personally, your abstract, bio, and any attached notes are all they have to go on.

LLMs make that job much, much harder. Once it's clear that an LLM has been employed, any remaining part of the text that doesn't have an obvious "human touch" -- mostly things we would perhaps counterintuitively term sloppy, such as misspellings or grammatical errors, but also idiosyncratic-but-correct stylistic choices -- cannot be trusted fully to evince the human author's knowledge and intent.

Without being able to judge the speaker's own grasp of their topic, the committee is reduced to guessing what will happen when the person whose name is on the abstract eventually gets up in front of a roomful of people. Will they draw on their experience and understanding to share an informed opinion, a useful synthesis, a novel approach to a common problem, a story inflected by their own interactions with people and systems that helps the audience see how patterns they might recognize have succeeded or failed? Or will they make themselves a mere voice for a machine with no experiences, no understanding, no subjectivity to communicate from? Will they land somewhere in between, and risk undermining the parts worth sharing with statistically plausible blather and simulated insights?

This problem remains just as acute no matter why a submitter has resorted to an LLM! There are many possible reasons, all yielding that same result and that same risk to the event, but only one reason that matters to me: when a prospective speaker isn't confident in their writing ability. Developing a good abstract, couching what you want to say in a way that will resonate with evaluators and attendees alike, is its own skill, and one that additionally requires a certain facility not only with the conference's language but with the standards and traditions of writing in it. It takes time and effort to learn that skill; more if you have to learn prerequisites too. From near the foot of that mountain, a machine that transforms a rough beginning into a polished product in an instant can seem like the answer to one's prayers.

It is, unfortunately, too good to be true. The LLM grinds everything into the same inherently untrustable confidently-expressed blandness; as the perjured, so he also that sweareth truth.

You Said You'd Reveal How to Use LLMs Effectively

Yes! I want my life to be easier next time I'm on a program committee and I hate reading prose that tastes like an oil slick. Here's the secret:

Don't use LLMs to write. Don't use LLMs to polish. If you want to produce good prose that communicates competence and relevance, and you aren't sure how best to do that on your own, you need to learn that skill. Devolving the job to an LLM robs you of the opportunity.

What an LLM can do for you is produce a quite adequate simulation of critique very quickly. Tell it "this is a submission for a Postgres conference; don't suggest any modifications, only critique what I have", and give it your draft. See what it says. Make some changes and try again, then again. If there's substantial drift in topic, tone, focus, or anything else, start a new session to reset its context. It will take time. It takes time to learn, and even though they can accelerate the literal feedback loop, LLMs haven't and won't change that fundamental fact.

And when you write, write with your own hands and your own words.