AI Writing Tools Can Help More People Publish Work Worth Reading

Zack Proser has spent 15 years writing: first in notebooks, then on word processors, and throughout his career at startups and on his own site. He showed a grid of 184 essays, tutorials, and reflections, alongside examples from his work at Cloudflare, Gruntwork, Pinecone, and WorkOS. One post about running a tech blog took him 23 minutes to write and publish—after putting his toddlers to bed, before large language models were part of his process.

When colleagues asked how he could write so quickly, Proser’s answer was that he was always writing. He rehearsed titles, sentences, and arguments in his head while walking, showering, or doing other things. Years of making and revising had left him with a practiced sense of what a piece needed to become worth publishing. He had become, as he put it, the only “content factory” he knew personally.

That experience shaped what he worried about in the era of AI. Proser said he was less concerned about AI-generated slop than about the stories that remain untold. He had worked with talented colleagues who doubted they could write, or feared their work was not good enough to share. Their self-conception could keep explanations of what they had built and learned from reaching other people.

His wager was that thoughtful, rigorous use of AI could help make stories better and allow more people to tell stories worth sharing. The human role, as he framed it, was to bring intention, shape the work, judge the result, and remain accountable for it.

“I'm not as worried about AI slop as I am about how many stories go untold.”

Zack Proser is an engineer on the Applied AI team at WorkOS. The immediate problem there was that teams were doing interesting work but not consistently writing about it. The goal was to increase publishing velocity—not to “slop cannon” the internet, but to bring more of the company’s work and technical insight to its audience.

Proser built Blogbot, a Slack-based tool that puts his accumulated ideas about a good post into a workflow colleagues could use themselves. A colleague can provide a brief and source material, such as an event transcript, and ask the bot to produce an on-brand draft. In the example he showed, a request for an editorial recap and a transcript returned a draft of about 2,200 words.

The resulting draft is typically 85–90% of the way there, according to Proser. It saves colleagues from manually gathering details from recordings, event images, Slack discussions, and other context. The person still reads the draft through, makes further changes, and puts their name on it.

The interface is deliberately familiar—Slack—but the machinery behind it is not. The diagram showed Slack connecting to a Cloudflare Worker and Durable Objects, with model APIs, an image service, D1 storage for drafts, versions, and sources, and Webflow. It labeled steps for deduplicating a request, returning an acknowledgment in the same thread, drafting and revising, and saving the artifact. The system can also connect to company sources, ask a human to approve or confirm facts, and generate images. The request is small; the system supporting it is distributed across multiple services.

What makes the leverage “asymmetric” is that a colleague supplies the purpose while the system takes on much of the assembly. The colleague can then shape the returned draft without needing a writing specialist to prepare it first.

An event recap made the distinction visible. The initial draft described Gergely Orosz and Michael Grinich as being “on stage.” Noelle, the colleague directing the post, wanted the framing to make clear it was a fireside chat, not an onstage presentation. Her instruction changed the language in the description and article. The slide showed that Maria reviewed and published the post, which appeared under Noelle’s byline. The result was not a finished article requiring no attention, but a substantial draft its author could correct, direct, and take responsibility for.

Zack Proser initially flinched at the prospect of producing writing much faster with AI. A conversation with WorkOS founder Michael Grinich helped him think through that discomfort. Grinich showed him a video of cymbals being made on a production line and described the process as something that “screams craft.”

As Proser recounted it, the cymbals were shaped through a process involving people and machines, then inspected one by one by an experienced musician. The musician played each cymbal, listened, and decided whether it met the quality bar. Production could move at a speed an individual could not match, while judgment remained part of the process.

Proser came to see his own role in AI-assisted writing through an extended blacksmithing metaphor: the spark, the bellows, and the quench. As the spark, he decides what is worth making. As the bellows, he steers the work—cutting irrelevant sections, identifying what needs development, and pushing a draft toward what he means. As the quench, he decides when it is ready to publish and accepts responsibility for the finished work.

“The finished work still has to earn my name.”

He compared two ways to produce a short piece about documenting a difficult bug fix: drafting and revising by hand, or working through 14 LLM-assisted iterations before hand-editing and reading the result. The examples differed in wording, but both met his standard. The question was whether he would publish either version under his name—not whether the process had been identical. From the finished work, a reader might not be able to tell which process produced it.

His rubric was direct: Is it true? Is it useful? Is it beautiful? Does it help anyone? Those are the questions that matter, in his account, when the work is intended for people to read and use.

Zack Proser sees the writing workflow as one example of a wider pattern. People in any field may have an artifact or process they know deeply, even if they do not think of themselves as experts. A support-handoff example shown on screen made the pattern concrete: a teammate asks for help mapping a process, and a first version represents a handoff among Support, triage, and Engineering. The teammate adds that routine questions should stay with Support, while bugs should reach Engineering. That context changes the routing logic and makes the branches explicit for future use.

The tool does not have to settle every decision on its own. The person who knows the process can identify which distinctions matter, test the result against a real request, and improve what the next user receives. Proser’s suggestion is to start with a process you know well, make a tool that produces something recognizable, and let other people test it against their actual work.

Zack Proser’s second example narrowed the audience from colleagues to his two toddlers. Using a language model, he said, he built a working bedtime-story app in about four hours, from idea to an initial app and family playtest.

The app uses photos from the children’s day to suggest a story based on what they did. A visit to an aquarium, for example, could become a story about Pip and Wren meeting a gentle octopus. The children can see familiar parts of their day reflected in the story and hear it narrated. The app also lets them revise a particular page without changing pages they leave alone: a prompt such as “make the ending sleepier” creates a new version, while the current one remains in the history.

The app draws on saved preferences and reference photos, so stories can include the children’s interests and depict characters based on them. They might ask for a story about Captain America and themselves at the zoo; Proser said a full story could be generated in about a minute and a half. Their response was to ask for the stories again—on average, he said, about three times per story.

The app reflects Proser’s accumulated opinions about what makes a good bedtime story, while the children bring the material and direction. He described it as the fastest successful playtest of his career: a working version that could be tried, revised, and enjoyed within hours. The point was not scale. An audience of two was enough to make the tool worth building.

He connected that experience to his broader feelings about AI. He had felt uncertainty about AI and drawing, writing, and software development, but making tools with it had become a source of satisfaction. He enjoyed seeing colleagues who did not necessarily think of themselves as writers share their work, and seeing his children turn their own experiences into stories.

Zack Proser built one tool to help colleagues share technical work and another to turn his children’s days into bedtime stories. In both cases, the tools gave people a way to contribute their own material and shape what came out. The return was not only a finished artifact: he also got to read what they made and hear what they wanted to change.

His closing question was who, in the audience’s life or team, might benefit from a tool built around a process or craft they know well. What do you know by heart? What makes its output good—or better? Put that practical knowledge into a tool, with an agent’s help if necessary, and hand it to someone who does not normally produce that kind of work. Then see what they make.