Editing 80,000 words: volume in parallel, correctness by machine, judgment by me
How I ran a full reader-first edit of a 17-chapter technical book with AI agents, without losing a code sample or a diagram. One brief, nine batches, a validator that compares every file against the original, and a human read at the end.
My book is about letting AI author engineering models while people review and sign. When it needed a full edit, I ran the edit the same way. The interesting part is not that AI agents did the editing. It is what kept their work safe to accept.
The manuscript is 78 source files across 17 chapters, about 80,000 words. It is written in a structured text format: every paragraph, box, list, table, code sample and diagram is a named block with an id. That structure is what made the method possible.
Figure 1. Split the manuscript, edit in parallel against one brief, check every file against the original, render every chapter. A failed check goes back to the edit step.
Step 1: measure before touching anything
I wrote the validator first and ran it against the untouched manuscript. The baseline was 27 errors and 673 warnings. Most warnings were style: 645 dashes and 28 uses of the author. The errors were real bugs in the source, mostly unbalanced bold markers that rendered as stray asterisks.
A baseline tells you two things. What the edit has to fix, and what “no worse” means.
Step 2: write one brief
Every editor got the same brief, about 770 words. It covered:
- Voice: address the reader as you, say I when I mean me, short sentences, active voice, no dashes.
- Evidence: do not add numbers or claims; cut or soften ones that cannot be sourced.
- Boxes: at most sixty words, with a short title.
- What must not change: code, diagrams, charts and maths, block ids, block types and every non-text property.
- What to add: Key takeaways and Check yourself questions at the end of each chapter.
- Self-check: run the validator before reporting back.
The brief is the most important artefact in the process. Every inconsistency I found later traced back to a rule that the brief left vague.
Step 3: split, and edit in parallel
The 17 chapters went into nine batches of roughly equal size, each edited by a separate agent with the brief and nothing else. Parallel editing is where the time saving comes from. It is also where the risk comes from: nine editors drift in nine directions unless something holds them to the same standard.
Step 4: let the validator decide what is accepted
The validator parses each edited file and the original side by side and compares them block by block.
| Check | Fails when |
|---|---|
| Parse | The file is no longer valid |
| Structure | A heading, table, list, figure or other structural block disappeared |
| Type | A block changed type, for example a box became a paragraph |
| Properties | Anything other than text changed: ids, variants, sources, sizes |
| Frozen blocks | Code, diagrams, charts or maths differ by a single byte |
| Ids | Two blocks share an id |
| Markup | Bold markers are unbalanced or nested |
| Style | A dash or the author appears in prose (warning) |
Nothing reached the book until its file passed. When a file failed, it went back with the exact error lines. Most failures were small and mechanical, which is the point: a machine is better than I am at noticing a changed diagram attribute on page 412.
Step 5: render every chapter
Passing the validator does not mean the page looks right. The import step renders every chapter to HTML and a browser test opens each one. This caught problems no text check could see. A checklist rendered one word per line because of how its markup nested. Some bold text inside bold text left stray markers. These were fixes to the renderer, not to the prose.
Step 6: read it myself
The last step was mine. I read for judgment, which no check can do: does this example still make the point, is this tone right for a leader, is a softened claim now too vague. I kept a review notes file of decisions, so the next edit starts from them.
The result
| Measure | Before | After |
|---|---|---|
| Validator errors | 27 | 0 |
| Validator warnings | 673 | 5 |
| Frozen blocks changed (58 code samples, 7 diagrams, all charts) | n/a | 0 |
| Takeaways added | 0 | 83 |
| Check questions added | 0 | 68 |
The five remaining warnings are dashes inside code samples, which are frozen on purpose. The prose changes themselves are in Write for the reader, not the auditor.
What I would tell anyone doing this
- Give your text a structure before you give it to an editor. Named blocks with ids are what make a mechanical comparison possible.
- Write the checker before the brief. The checker defines “safe to accept”. The brief only asks nicely.
- Freeze what has no business changing. Code and diagrams are evidence. Treat them like evidence.
- Keep judgment for the end, and keep it human. Parallel editors give you volume. The validator gives you correctness. Neither gives you taste.
This is the same split of work the book argues for in engineering: AI writes, a deterministic validator checks, and a person signs.