For the past few months, I’ve been hacking on a side project to generate print-quality cookbooks. At the start of this project, I set three hard requirements for myself:
- Generation Input should be no more than what would fit on a book cover
- Generation Output shouldn’t be slop — it should be good enough to justify printing.
- Generation must be end-to-end automated
So far, that’s produced 53 cookbooks over more than 500 attempts consuming hundreds of millions of tokens. All free on the web and as PDF & EPUB downloads.
The books aren't yet worth printing, in my opinion. But the recipes, and recipe curation, are a pretty darn good, to the point I’d be wiling to defend the “no slop” claim.
I’m currently on a plane over the Pacific, unable to check in with my robot authors, and honestly a bit hungry. So I figured what better time to jot down a few notes about what I’ve learned so far.
In case it’s important to you: while this post is about AI writing, it's written and edited without AI.
First: Why cookbooks?
I love to cook, but I chose to generate cookbooks because I think it's a bit of a cheat. Cookbooks are as close as you can get to a type of long-from content LLMs can generate well, autonomously, at this point in their development cycle.
First, Cookbooks are episodic. LLMs struggle to maintain humanlike pace and cohesion across long-form text generation. But cookbooks minimize these issues because there are few cross-book dependencies to keep track of. It’s like generating a sitcom episode compared to the Game of Thrones finale. Cross-chapter and cross-recipe dependencies are mostly relevant distributionally — avoiding overuse of the same trope over and over throughout the book.
Second Cookbooks are mostly an act of curation and translation, and LLMs are great curators and translators. Writing the next great novel requires layers of creative spark and balance, But even human cookbooks are essentially a curation of existing cultural knowledge, translated into a particular chef’s take on the cuisine. Chili, but vegan. Pizza, but with pesto. Pho, but with American ingredients.
So cookbooks, to me, are akin to the easiest long-form writing eval that you could create for an LLM.
How does it work?
Robot Book Club is organized into different series of books. Each book series is a program that produces a finished book based on a few simple inputs: the book title, the back-cover description, and a few notes on author voice.
Right now there are three cookbook series:
- The Diaspora Series, which contains recipes second generation Americans might learn from their grandparents. (Examples: Japan, Cuba, Spain)
- The At Home Series, which adapts famous restaurant styles into home cooking. (Examples: Jewish Deli, Chinese Takeout ..)
- The Diet Series, which contains recipes for people who maintain specific diets (Examples: Whole 30 Quick Meals)
I hand wrote the very first book series program — The Diaspora Series - through a lot of trial and error. From that series, I extracted an agent skill, and every series program since has been AI-authored through the use of that skill.
While publication goes straight from generation onto website, I do skim through a random selection of book PDFs afterward. This produces a list of change requests, which I feed back into my agent to update both the series program skill and also the existing programs. You can see how regenerations of each book have happened based on the “Edition Number” on the website. Taiwanese is on Edition 13 — though the real number is probably something like 200 since I hand-wrote that one — while some of the other books like Vietnamese are only on Edition 3, since they were generated using the most recent version of the program.
Each book series program is a workflow of agents rather than an agent itself. I might just be resisting our agentic futures, but I’m not yet sold on the idea that the top-level control plane should be yielded to an LLM, at least for something like Robot Book Club. Each series has a very specific research, writing, editing, typesetting, and publishing process that I don't want to veer from. That process includes many, many agents within it, but the overall process itself should, I think, remain rigid.
Having that top-level rigidity also supports a more controlled error handling, error recovery, logging, and observability setup — something that’s really helped scale the output volume.
Workflows help you scale output quality
Workflows have been the biggest factor in scaling quality. I don’t mean Anthropic’s branded Workflow feature, but the generalized idea it represents: encapsulating common patterns of LLM processing and then using them over and over again via a simple invocation. A bit like functional encapsulation, LLM style.
One such workflow I have handles image generation — something that’s been challenging since many regional foods aren’t exactly represented well in training data.
"Model 1" in that image is what output looks like if image generation is merely a prompt. "Model 2" is the same input being run through the current food image workflow.
Another workflow I’ve got aims to reduce repeating the same tropes across chapter introductions using a series of editorial passes that inspect what’s already been written.
It takes a while to figure out what specific workflows are helpful for a particular domain, but you have them, you can refer to them by name when asking your agent to help write a new series program. You can say something like: “make sure chapter images use the regional food and plated food workflows, but the cover should use the atmospheric workflow, and chapter titles should use the cooking chef workflow”.
Version 1 of the resulting program will already benefit from the tricks won by making it to Version 30 of your prior series program.
Caching is essential for steady progress
Each book generation takes many hours to complete, and early on I realized that I wouldn’t make any progress if an error in the final stages of generation destroyed the whole processing run. (And believe me: if you’ve ever tried to layout content in a PDF, let alone have an AI do it for you, you will hit errors at the end of your processing runs.)
Without caching, you’ve got a single iteration per day if this is your side project. And maybe three iterations per day if you’re doing this as your job. With caching, generating a book the second time around takes about ten minutes, significantly changing how many iterations you can go through in a single sitting.
The only catch is that you’ll find yourself adopting a development style that favors appending new data rather than co-generating it up front — to avoid day-over-day cache invalidations. It's not terrible.. but the book series programs end up looking a bit like an append-style log of data creation.
Output stability is hard to manage across editions
In writing they say “kill your darlings” — be willing to delete writing that you love, but that doesn’t survive the editing process. I think we may need a similar maxim for fully-automated writing.. something like “allow menu to change.”
Each book generation involves thousands of autonomous decisions, and changing any one prompt or workflow can cascade into enormous downstream effects. I’ve seen entire cookbook chapters added and destroyed from minor adjustments to the author’s tone of voice.
While I’ve hacked a bunch of strategies to gain some control over consistency across book editions, the only high level one that feels worth sharing is to get clever with your cache keys. Your default LLM cache should be keyed on the inputs to the LLM, but occasionally you want to pin a particular generation across books, or just within a single book, so that it persists even if the true cache key has changed.
Good sandboxing is essential to quality hill-climbing
Persistent versioned sandboxes are critical for reviewing output and hill-climbing book quality.
Each book generation happens within a custom sandbox rig that contains logs, LLM input/output snapshots, and a versioned filesystem.
That means you can rewind to exactly before or after a particular agent fired, inspect the state of the filesystem, and then review exactly what LLM calls got made and what their outputs were.
The whole generation workflow is thousands of nodes per book, and that's added up to almost a quarter terrabyte of logging data already. But it's been an invaluable way to extract post-mortem answers to questions about what went wrong.
I've failed to generate good visual plots of the generation process. Finding a good visualization to help debug is something that feels theoretically possible but perhaps it's a side project all by itself.
What's been more helpful is to take notes about what flaw I'm seeing in the final book output, and then provide those notes to a coding agent along with a reference to the sandbox folders of the related books. A few minutes later, some reasonable debugging threads to pull on often result.
Self-improvement loops don’t have to be recursive
I know RSI is a hot acronym, but self-improvement loops don’t have to be recursive to be awesome.
I've turned my bug-fixing flow into an handful of skills that run automatically after every generation:
- An output critique skill runs automatically after every generation, identifying issues related to performance, resilience, and output quality, and then suggesting where a fix for them might be implemented.
- A bug writing skill curates output critiques into a de-duplicated folder of open bug tickets.
- A bug triage skill suggests what the top five bugs I should work on are.
Just a few months ago, I was hand-reading logs and hand-coding updates based on what I found. But incorporating this improvement loop into the generation itself has automated about 95% of my development process. I just jump in every once in a while to read the top five improvement suggestions, and then I add additional context or constraints and let an agent begin working on them.
You will soon read AI generated fiction.. and like it
OK my final take is spicy.
I think frontier models are already good enough to generate the next great novel. They just need the right harness to maintain a sense of balance and quality across the generation process.
LLMs remain poor at long-form content if all you do is prompt them and let them rip. But working on Robot Book Club makes me confident that you can get at least an order of magnitude output improvement with the right harness surrounding your prompts. Maybe even two orders of magnitude.
I think a good writer, a prolific reader, and an agent whisperer, could build a viable fiction-writing harness in about a year of dedicated, full-time effort with today’s models. It wouldn’t be able to generate every kind of book, but a specific category: like “Emerging Technology Thriller” or “Coming of Age Romance”.
..And I think you’d want to read it.