Zack Proser: Build a Factory to Help Others Tell Their Stories

If you care about somebody, I think you should build that person a factory. I've been an open-source developer for 15 years, but I've also written obsessively since my teens: essays, tutorials, startup blog posts and pieces on my own site. I like to explore an idea that interests me and then publish it for others.

One of my most consistently successful posts went from nothing to a published Markdown article in 23 minutes, before large language models. It followed a brutal bedtime routine with my two toddlers. People ask how I write so fast; the answer is that I'm always writing in my head, trying titles, sentences and ways to make a story more compelling.

I'm less worried about AI slop than about stories that go untold. Many talented colleagues tell themselves they aren't writers, or feel fear and shame that keep them from sharing important work. I believe AI can improve stories and make storytelling more consistent if we bring intention, judge the result and hold one another accountable.

I'm an engineer on WorkOS's applied AI team. We wanted to increase publishing because teams were doing innovative work without consistently telling people about it. So I built Blog Bot on Cloudflare. I encoded the lessons I'd learned about engaging, educational writing into an automated system and handed that system to my colleagues.

A colleague can use a familiar Slack interface to ask Blog Bot to turn an event transcript into a WorkOS-quality recap. It gathers context from recordings, event images and Slack discussions. In my experience the result can be 85–90% of the way to a draft, but a person must still iterate, read the entire piece, put their name on it and publish it.

I call this asymmetric leverage: a simple interface can hide a complex distributed system with data connectors, custom tools and requests for human approval or fact confirmation. Our system can also generate images in our design team's style. A small request returns substantial work, and the colleague can adjust it independently rather than relying on a writer to make every change.

WorkOS founder Michael Grinich and I discussed the public anxiety about AI writing alongside the speed developers were gaining. He showed me a cymbal factory: machines produced cymbals quickly, but a skilled musician inspected and played every one. He said the line screamed craft to him. At first I flinched at calling accelerated production craftsmanship.

His point was that craft can run through the entire line. The machinery does work at a speed people cannot match, but an experienced person plays, listens and decides whether each cymbal earns the brand. Quality hasn't left the process. Likewise, our publishing rate rose and I saw colleagues who rarely shared their excellent work begin to explain it regularly.

One reader said they now flinch at every sentence online, wondering whether AI or a human wrote it. I understood that concern, but the factory example made me examine my own process. To clarify my thinking I wrote about it, borrowing an extended metaphor from blacksmithing: the human is the spark, the bellows and the quench.

As the spark, I'm the person who experiences the world and decides which story is worth telling. As the bellows, I watch the work develop, remove irrelevant sections, correct errors and direct how the remaining ideas should be developed. Even when a model handles tedious details, I'm continually shaping the artifact toward the result I want.

Finally, I'm the quench: I decide a piece is ready and publish it under my name. That means standing behind its words, claims, links, specifications and performance data. The finished work has to earn my name. That is how I think we can keep a quality bar even when the pace increases.

Consider one piece written entirely by hand and another developed over 14 iterations with a model, then hand-edited. If readers cannot tell the difference, I think the relevant questions are about the work itself: Is it true? Is it useful? Is it beautiful? Does it help someone? Readers can decide whether they want to return based on what they received.

Most of us have a workflow or artifact we know unusually well, even if we don't call ourselves experts. Turn that experience into a tool, get it to produce something you recognize, and let others try it. Ask whether it helps them reach their own goals more completely and effectively. I see that as a broadly applicable pattern.

My first factory helped colleagues share work. Then I wondered whether an audience of just two people could justify another one. I used an AI model to build an app for my two toddlers in four hours: it looks at photos from their day and suggests a bedtime story with them in it, including experiences and lessons we shared.

The first playtest went from zero to 'again, again, again' in four hours—the fastest successful playtest of my career. I added voice control so the story would replay when they asked. The system encodes my opinions about good bedtime stories, while the children bring the content: they can request an adventure featuring themselves and a favorite character.

This moment brings potential and progress, but also anxiety and uncertainty. I've felt that myself as a visual artist, writer and developer. Building tools that help people create has become one answer to that uncertainty: I enjoy seeing colleagues get credit for their insights and my children see their own days reflected in stories.

Both factories improve when the people using them bring ideas and feedback. So my question is: who do you care about, and what are you especially good at? Put what you've learned and your strong opinions about quality into a tool, give it to someone who doesn't normally make that kind of thing, and see what they create.