How I over-engineered my book
TL;DR
Ben Balter wrote his 576-page book in Markdown in a Git repo and built it like software. The setup has about 30 custom prose validators, 20 LLM audit lenses and 2,204 test cases. Fourteen parallel CI jobs turn one source into five store-ready formats.
The article
- Each chapter is a Markdown file, ordered by one index.yml. He wrote mostly on an iPad through Codespaces. Six prose linters, including Vale, Harper and LanguageTool, flagged problems as he typed.
- Every mistake he caught once became a build-failing rule. About 30 Node validators check things like the hyphenation of "open source" and any sentence implying he still works at GitHub. One validator flagged an AI-sounding opener that he had in fact written himself.
- Three layers of duplication detection ran in turn: jscpd, word n-grams, then an LLM pass over TL;DRs and extracted claims. The LLM pass found the same argument repeated in five chapters, plus 166 smaller self-restatements. A separate LLM "Claims" lens caught a wrong statistic about GitHub all-hands meetings.
- Ebooks are HTML and CSS. So one Tailwind stylesheet drives EPUB, Kindle, web and print. Pandoc Lua filters handle per-format changes. WeasyPrint and Ghostscript produce the PDF/X-1a that IngramSpark requires.
- The print PDF is pinned to exactly 576 pages, because the cover spine depends on that count. That gate caught a CSS leak that had shrunk the book to 567 pages. A separate Twemoji transparency bug needed opposite fixes for Kindle and for print.
- Publishing itself meant manual uploads to KDP, IngramSpark and Draft2Digital, under his own LLC and ISBNs. The metadata lives in the repo. Translation and audiobook pipelines already run on the same setup, though he hasn't committed to publishing either.
Why it matters
Anyone self-publishing technical or nonfiction writing gets the concrete toolchain here. That includes the validator roster, the Lua filters, the CSS pitfalls between screen and print, and the store validators to run before upload day. The footnotes list every tool and check by name, which the summary can't reproduce.
The discussion
The thread mostly ignored the build pipeline and argued about whether the post, the book's landing page and possibly the book itself read as AI-written. Balter answered in the thread with the book's blog-post origins and an admission that Copilot drafted an early version of the post. A smaller set of commenters shared their own doc-automation tricks and book toolchains.
The prose reads as AI-written
Most of the discussion said the post's style matches AI output, with its reversals, punchy setups and "here's the X" signposts. One commenter called the book's landing page vibe-written marketing. Others pushed back hard, saying nobody can reliably detect AI text and that these accusations drive human writers away. The original critic clarified she was naming recognizable patterns, not claiming proof.
In this article alone there are three "here's the X" rhetorical signposts, well over a dozen neatly constructed reversals/antitheses ("not X but Y," "solved X and created Y"), repeated setup->complication->punchline paragraph structures, rhetorical questions used as transitions, and a high density of anthropomorphized technical metaphors.
The most alarming part is it appears Ben either did not bother to review and edit the content, or was not adept enough to recognize it as deficient.
Where the book and post came from
Balter said most chapters descend from blog posts going back to 2012 and listed about twenty of them by title. He also said Copilot drafted a first version of this post, which he then rewrote by hand, using Claude only for line edits. Skeptics weren't satisfied. One misread the rewrite claim as covering the whole book, and another said even his replies sounded generated.
I did a full (human) blank page rewrite three days ago and then only used Claude for line edits like adding links or fixing failing lints.
most of the book's chapters began as blog posts that I've published for over a decade, well before AI slop came into the picture.
Did the linters train him to sound like a model?
Some commenters suspected the tooling itself shaped the voice. The rules that flag passive voice and weak phrasing push toward the same punchy style AI models are tuned for. Another found it absurd that a writer needed an "AI tells" lens to check his own voice.
It makes sense that a lot of what the linters would red squiggly on (e.g. weak passive voice) would also be the type of prose that gets trained out of LLMs as not "punchy" enough. So, basically, did you accidentally RLHF yourself into sounding like an LLM?
Having an "AI tells" linter to catch "Phrasing that reads as machine-generated rather than my voice" has a real echo of "What does God need with a starship?".
Automating the boring parts pays off
Those who engaged with the engineering liked it, and one recalled Bruce Eckel's tooling for extracting tested code into Thinking in Java. He later used jcite, a FOSS tool built on that idea, to cut a week of doc work per release to under an hour. Others noted custom lint hooks now take a minute to set up with an agent. Some shared their own stacks: Org-mode with a homemade Go converter and WeasyPrint, Astro for short stories, and EPUB tools.
With that done, it took less an hour per release to fix the developer documentation, and half of that hour I got one of our tech writers to take off my plate
Markdown could not seem to meet the third point. For instance, progress-related comments that would be stripped from final output were essential, but Markdown's HTML-style comments are intolerably unergonomic, and editors know how to de-emphasize no other syntax.
Is over-engineering a virtue or procrastination?
A few questioned why "over-engineered" now reads as a boast. Replies split. One said it was more an admission than a boast, and another argued over-engineered products leave margin that consumers benefit from. Several joked it was structured procrastination, and Balter agreed with a wink.
In an over engineered thing margin is left on the table which the consumer gets to take advantage of.
Consensus
Most commenters who addressed the writing found the post's style read as AI-written, whatever its actual origin. Balter accepted the point and promised to rewrite the flagged passages.
Dissent
A minority said AI detection by eye is unreliable, and that calling human authors AI discourages them from writing at all. The engineering-minded commenters simply praised the pipeline.