The Literary CI/CD Pipeline

In Software “Engineering” (This is a well and truly lost battle, but I’ve always cringed at calling ourselves ‘engineers’ despite most of us barely knowing how to change a tire) there is a methodology known as CI/CD. It stands for Continuous Integration and Continues Delivery (and Deployment). This methodology has become so ubiquitous that many developers may not even remember the issues that CI/CD was created to solve. The old way of doing things was for a developer to take a copy of the codebase, or a branch, and to complete their work in that branch. When finished, they would use specialized tools to merge that branch back into the main branch that all developers pull from and push to. Developers would get into the habit of making a large number of changes in their branch and only attempting the merge once a deadline neared. At this point, they would typically find that there were a variety of conflicts as different developers had modified the same files. Merge conflicts often require tedious manual resolution. In CI/CD changes are merged more frequently (continuous integration), and automated tests are run and automated processes deploy the code to a testing environment for human testers to work with (continuous deployment). This allows teams to identify issues quickly and to (hopefully) avoid a difficult knot of spaghetti code that needs to be untangled at the last minute. Now, I know what you might be wondering. How does this apply to literature?

Literature is not immune to market forces and corporate influence. For the last 50 years or so, computing and digital services have been the main drivers of economic growth. As a result, many business people have come to view the various practices and methodologies of the software industry as a kind of semi-spiritual philosophy that can be applied to all aspects of life. You can hear it in their speech as they ask one another if they have “the bandwidth” to tackle a certain issue. I’ve even heard some of them refer to their available time in units of “cycles.” A person going on LinkedIn for the first time could be excused for thinking that Agile and Kanban were something akin to Stoicism and Zen. Embracing these methodologies as rules to live by is an attempt by FOMO-addled business people to channel the explosive growth of the computing industry into other aspects of life.

“Art is never finished, only abandoned”
– Some dude

With that said, I don’t think that applying software development methodology to literature is as big a stretch as it may seem at first. We call CI/CD processes “pipelines” because, like a water line, they maintain a constant flow of work products to market. This can mean new features and fixes in the case of software, but this can also mean new “content” in the case of digital entertainment. When it comes to literature, we actually have a precedent for this: the magazine. Once we understand that the subscription model is the golden monetization system for CI/CD, it’s obvious that literature is a prime candidate for optimization.

Fans of Beware of Chicken, Dungeon Crawler Carl, or any of the rest of the big web serials are quick to point out that what these authors are doing is nothing new. After all, weren’t many of the great Victorian authors originally published in serial fashion in newspapers? What about all the sci-fi greats who were published in literary magazines? Readers are already on board. Now all we need to do is get authors out of the dark ages with regard to content generation.

Getting Started With Literary CI/CD

Writing a book isn’t really that different from writing a program, at least from a project management perspective. The story is the code base. The writer is the developer. The reader is the user. To get our CI/CD pipeline going, we’re going to make use of another methodology that I’ve already referenced: Agile. “Agile” refers to a system of practices that facilitate getting new work products in front of users as fast as possible.

Our ultimate project goal is to write a book, but writing a book is a big task. A traditional “waterfall” approach to writing a book would involve gathering ideas (requirements), designing the plot and characters (system design), actually sitting down to write the damn thing (coding), reviewing and editing the book (testing), and finally having the story printed and put on a shelf. But what if we get all the way to editing only to find out that all of our ideas suck or the plot doesn’t make sense? That’s where Agile comes in.

Let’s say, for sake of argument, that our fundamental unit of work is a “chapter.” We could compare this with a “screen” in a web application. Let’s divide our work into “sprints,” or miniature development life cycles. Let’s gather ideas, design the plot and characters, write, and edit one chapter and then release that to readers to see if there’s any potential before we waste all that time (remember time = money) on writing the whole book. We can even leverage the reader feedback to make our next chapter more engaging (remember engagement = time = money). And I’m not saying you have to, but you can easily see how an extra writer might fit in here to produce multiple chapters per sprint.

Let’s build out our tech stack, or the tools we’re going to use to make this as efficient as possible. Now me, I like to use Scrivener to create big complicated documents with lots of moving parts and research. So we’ll set up the document there, and why not go all the way with this and just check that into a git repository? If that’s a little too technical, maybe a shared drive would suffice.

After everything is edited and ready for the readers, we’ll need to publish it. Now I publish these stupid posts on this stupid blog, but you’re an author, so you’re going to want to go somewhere like Royal Road. Now we have a system that we can continuously integrate new chapters into and a platform that we can continuously deploy to.

I think there’s only one thing missing to round off our agile process (no it’s not a stand-up, I hate stand-ups) and that’s a backlog. We threw all this together pretty quick because we’re fancy Silicon Valley entrepreneurs and we like to move fast and break things, so there’s going to be bugs. In the case of a story, this means language errors, plot holes, etc. We’ll want to record those things as readers report them and plan on fixing at least a few of them each sprint. We’ll also want to record ideas for new chapters or characters to integrate in the future. Once we start to bring some revenue in we can hire on some people to help with the quality assurance and organization, or hell, it’s 2026! Let’s get Agentic! Have the AI do that stuff.

I can’t tell if you’re serious

I can’t tell if I’m serious. I mean, I’m not serious about using AI. I don’t think AI has any place in the creative process. Hire a real editor. But the rest of it, that might not actually be a bad strategy. I want to be clear. I don’t think this process will produce good literature. But I also don’t think that book 7 of Dungeon Crawler Carl, Book 5 of Beware of Chicken, or whatever number Brigands and Breadknives is of Legends and Lattes are good literature. But they are good products with consistent output that keeps readers engaged. I don’t mean that as a slight. These authors are making a living writing books that people enjoy. I’m not so cynical as to not see the real value in that.

At the same time, I don’t love that it has to be this way. From my own experience, I know not every episode of Words About Books is gold. There are projects that I am more passionate about, that I know would be better if only I could spend the time on them. I don’t spend the time on them though, because the algorithm is a fickle mistress. Once you get an audience, even an audience as small as mine, if you don’t maintain a consistent output then you will find yourself fighting that uphill battle all over again. Very few creatives have the luxury of working only on those projects that they care deeply about.

It’s a mixed bag with pro’s and con’s. I participate in the content mill, but I also think that it’s damaging society. We’re flooding the culture with mediocrity and we’re becoming mediocre in return. At the same time, these creatives would never have had access to publication and distribution in a pre-internet world. I don’t think that things were better before, but I do think that there is room for improvement.

I don’t really want to make writers more efficient at producing content. The true art often lies in the inefficiencies. But maybe, and I’m struggling really hard to indulge in optimism here, maybe there is a future in which this desire for optimization can be turned towards new recommendation algorithms that are capable of solving for both quality and consistency. Maybe there is a future in which we optimize for intellectual enrichment and not just passive engagement. But until then, turn that mindset into a grindset or whatever…