The engineering problem hiding inside "AI writes a book"

When people hear "an app that writes books with AI," they picture one giant prompt and a wall of purple prose. That's the demo version. The moment you try to ship a real reading-and-writing product, you find out the generation step is the easy part. The hard part is everything wrapped around it - and it's a genuinely interesting systems problem.

A book is a state machine, not a prompt

The first thing that breaks the naive approach is length. Ask a model for "a novel" and you get a vibe: a strong opening, a soggy middle, and an ending that forgot how it started. What actually works is decomposition. You split the job into:

• An outline pass
• A character and world bible
• Chapter-by-chapter drafting
• Reconciliation passes that check every new chapter against everything written before it

Each of those is a smaller, tightly constrained task, and constraint is where quality comes from. A model is dramatically better at "write chapter 12 given this outline and these established facts" than at "write a good book." The interesting engineering is in the orchestration layer that decides what context each step gets, not in the call to the model itself.

Continuity is the real cost center

Readers forgive an ordinary sentence. They do not forgive a character whose eye color changes between chapters or a subplot that quietly evaporates. So most of the effort goes into state management: carrying forward names, relationships, timelines, and unresolved threads so chapter 20 still agrees with chapter 2.

A pattern that works well is to treat the "story bible" as a structured, append-only record that every drafting step reads from and writes back to. Before a chapter is accepted, a validation pass diffs the new facts against the canonical state and flags contradictions for a rewrite. It's closer to database integrity checking than to creative writing, and it's where a naive pipeline goes from "impressive" to "actually usable."

The delivery format shapes the prompt

Here's the lesson that surprised me most: what you're building for changes how you generate. A product built around short, serialized chapters - the kind meant to be read in 20 to 30 minutes on a phone - optimizes for hooks and clean chapter breaks, not sprawling literary arcs. The reading surface reaches back up the stack and rewrites your generation constraints. If you ignore that, you get technically-correct chapters that nobody wants to keep tapping through.

Where it lands for readers and writers

The reason to solve all of this is that it opens up a genuinely new product shape: an app where the same person can read fiction and write and publish their own with AI assistance, all in one place. That's the bet behind NanoReads, a personalized reading-and-writing app and book marketplace on web, iOS, and Android - the reader-facing side of exactly the pipeline described above.

If you're building anything that generates long-form structured content - legal drafts, course material, documentation, fiction - the takeaway generalizes: stop hunting for the perfect prompt and start engineering the stages and the state around it. The prompt is maybe 20% of the system. The other 80% is orchestration and consistency, and that's the part that's fun to build.

Happy to go deeper on the consistency-diffing approach in the comments if anyone's wrestling with the same problem.