Although most arts make extensive use of automation tools, from textures in comic to automatic motion generation tools in 2 or 3-d animation, writing a book, whatever its class, technical or fiction, gives the word manuscript its full meaning, since the most advanced tool used is the spell and maybe grammar checker. This leads to long development cycles, with new editions published after long rewriting-edition-production cycles. Nowadays, authors can publish directly using a variety of places, from Leanpub to Kindle Direct Publishing, and there are all kind of tools available for doing that kind of thing. Still, this has not lead to fast production cycles where new editions are produced as soon as "bugs" are found and fixed and all formats are published at the same time. My personal history in this area started when I decided to write a book from the first line using GitHub. That lead to using continuous integration, and it kind of ballooned from here. Nowadays I have created a full automation suite, in Perl6 and Python, that produces "printed" versions (shortening and expanding URLs), checks for line bleeds, and produces several high-quality formats from a Markdown source; time from change to new publication-ready version takes a few seconds. The only thing missing is an API for publication sites that would allow to make an automatic deployment. However, even without that final steps, the LitOps concept that codifies book production pipelines using scripts, including error checks and the rest, actually might mean a sea change in how fiction and non-fiction is produced, using LitOps teams and adopting the rest of the patterns of the software industry: forking, hackathons and linting, and finally taking manuscripting to this century.