I Don't Fear AI Slop. I Fear Untold Stories - Zack Proser, WorkOS

After a particularly brutal bedtime with his two toddlers, Zack Proser sat down and wrote a post about keeping a technical blog going for 15 years. In 23 minutes he went from a blank page to a published post written in Markdown. It became one of his best-performing pieces. This was before LLMs.

Friends and colleagues wanted to know where he found the time. The 23 minutes counted the part at the keyboard. He had been writing since his early teens, first in notebooks, then on a word processor. As an engineer, he regularly turned things he figured out into tutorials and essays for startup blogs and his own site. Between posts he would try out titles in his head, turn a sentence around or reconsider where a story should start. By the time he had a quiet moment to type, some of the writing was already done.

His colleagues had material he could never supply from his own experience. Some were reluctant to share it because they thought of themselves as people who couldn't write. A poor draft could be read, challenged and improved. A discovery that never made it onto the page gave readers nothing to learn from and its author little chance of getting credit. That loss worried Proser more than AI slop.

At WorkOS, several teams were doing work worth explaining, and the company struggled to tell those stories consistently. On the Applied AI team, Proser built Blogbot on Cloudflare. Years of publishing had given him opinions about what holds a reader's interest and what helps a reader understand a technical idea. He built those preferences into a tool his colleagues could reach from Slack.

Take an event recap. A colleague can mention @Blogbot, point it to the event transcript and ask for a post in the WorkOS voice. The transcript supplies what people said. Other pieces of the story live in Granola recordings, event photos and the Slack conversations where the team prepared for the event and discussed its angle. Blogbot gathers that context through connectors. It can ask a human to confirm a fact and call a separate image-generation endpoint for artwork in the design team's style.

What comes back from that short request? The colleague gets a recap they can already read as a post. Proser puts the first draft at 85–90% of the way to publication. The colleague can now spend their time deciding whether the recap tells the right story.

This is what Proser calls “asymmetric leverage.” One Slack request sets a distributed system to work, and the person who made the request can steer the next revision without waiting for Proser to edit it. Someone still has to read the whole thing, make the remaining changes and decide to publish it under their name. WorkOS describes how the bot checks claims and leaves the result in the CMS as a draft in its engineering write-up.

WorkOS founder Michael Grinich showed Proser a video of cymbals moving rapidly down a production line. To Grinich, the line suggested craft. Proser flinched at the comparison to publishing. He could see why a company would want to turn out articles faster. What did speed have to do with whether any one of them was good?

The telling detail was what happened to each cymbal. A musician who had worked at the company for years played it, listened and decided whether it could carry the company's name. Machines did much of the physical work. The musician knew the sound they were trying to produce and heard the particular instrument in front of him. Proser came around to the analogy. His colleagues could use machines to assemble a draft and still give each post that kind of attention.

Publication rates rose across WorkOS. What Proser noticed personally was who had started publishing regularly. Colleagues who seldom shared their work were explaining what they had built, how it worked and what it did. Then an early commenter on the team's recap described a different experience of reading online. Every sentence now made them flinch as they tried to decide whether a person or a model had written it. The musician analogy explained who could vouch for a finished piece. The comment pushed Proser to ask what part of writing it was still his.

Proser worked out his answer by writing. He estimated that with an LLM he could get to a piece he wanted to publish about six times faster, while trying more revisions along the way. Borrowing from blacksmithing, he gave names to three jobs he still did himself.

• The spark. Someone has the frustrating experience, discovers the interesting behavior or feels the joy that makes a story worth telling. The author decides which of those experiences has something in it for a reader.
• The bellows. As the draft develops, the author directs effort where it matters. Keep this passage. Drop that whole section because it's irrelevant. Expand this point in a particular direction and correct the claim that went wrong.
• The quench. At some point the author stops revising and puts the piece at a URL. Signing it means standing behind the links, specifications and performance figures as well as the sentences.

Consider the comparison from the reader's side. Proser could type every word himself. He could also spend two and a half to three hours on 14 iterations with an LLM, requesting changes down to individual words, then edit the last sentences by hand. If the reader can't distinguish the finished pieces, he thinks the same questions should decide whether they'll come back next week. Is it true? Is it useful? Is it beautiful? Does it help anybody else?

Turning that judgment into a tool takes two trials. Start with a task you know well enough to recognize a good result, even if it's an obscure internal process. Get the tool to produce something you would use yourself. Then give it to someone else with their own material. Can they finish the work they came to do? Blogbot passed that second test when colleagues could tell stories Proser couldn't have supplied. It made him wonder how small an audience could justify building another one.

Proser's next audience was the two toddlers from the 23-minute-post story. He had done enough bedtimes to have opinions about what makes a good story, and with AI assistance he had a working app in four hours. How would the children recognize a story as theirs? The app looks through photos of their day, picks out things the family did and suggests a story that casts the children in it. Animation and narration let them revisit an experience together at bedtime.

The first playtest produced the next feature request in words the app could use directly. The children wanted the story again. Proser added real-time voice control so that saying “again” at the end replayed it. They could also ask for a new story of their own choosing. His example was Captain America Night at the Zoo. About a minute and a half after the request, they had a full story with themselves in it.

As someone who liked to draw, Proser had wondered why he would ever draw again. Writing and software brought on the same doubt. Part of what changed his mind was getting to enjoy what other people made. At work, colleagues were getting credit for technical deep dives, announcements and patterns they'd discovered. At home, a story could bring back the day's lesson about using soft hands with a sister. He reckoned the children asked for about three repeats per story.

His closing invitation starts with a person you care about and something you know by heart. Think of the thing friends or colleagues already come to you for. Put the choices you've learned to make into a tool, with an agent's help if you need it, and hand it to someone who wouldn't ordinarily make that kind of thing. Let them bring their own material and tell you what they wish it could do. In Proser's house, they only needed one word.