There Is No Right Way to Automate a Novel

I have written books five different ways.

Not five different genres — five different setups. A chat window. A coding agent running in a terminal. Somebody else’s writing app. An extension bolted into a code editor. And eventually software I built myself, because nothing on the market fit the shape of what I was doing.

People want me to tell them which one won.

None of them won. That is the real answer, and I have come to think it is far more useful than a winner would be — because the moment you stop looking for the best setup, you can start looking for yours, which is a question that actually has an answer.

The question that has no answer

“Which AI should I use?” is the most common question I get, and it is two questions wearing one coat.

The first question is which model — Claude, GPT, Gemini, one of the open-weights families you can download and run on your own machine. The second question is what you run it inside. A chat tab. A terminal. An app someone sold you. And these two choices are almost completely independent of each other. You can put nearly any model into nearly any container.

Almost every argument about AI writing tools collapses these two into one axis, and that is why the advice you find is so wildly contradictory. Someone tells you a model is useless for fiction. Someone else says the same model wrote their best chapter. They are both being honest. They were running it in setups so different that they were, functionally, using two different tools.

So before the five ways, the thing that makes the five ways make sense.

Two dials, not one ladder

Picture two dials on a desk.

Dial one is the brain. Which model does the actual writing. This dial decides prose quality, default voice, what it will and will not refuse, and what it costs per word.

Dial two is the harness. What sits between you and that brain. This dial decides something entirely different: whether the machine can open your files, whether it can repeat itself, whether it can run six checks on one chapter at the same time, and whether you can use it from your phone in a school pickup line.

Here is the part that matters, and the part I wish someone had told me two years ago:

The dials multiply. They do not add.

Your output is never produced by a model. It is produced by a specific model at a specific setting of the harness, and moving either one changes the page.

Same model, different harness

Two authors using the exact same model can get results so different that neither would believe the other.

The harness decides what the model can see. In a chat window, it sees whatever paragraphs you remembered to paste, and nothing else. In an agentic setup with access to your folders, it opens the actual chapter, the actual continuity notes, and the actual style guide — because it can read the files itself, without you copying anything.

The harness also decides how many chances the model gets. One shot in a chat box, versus draft → critique its own draft → revise → check continuity → revise again. Same brain. Four extra passes.

Most of the quality difference people credit to “a better AI” is actually those two things — better information and more passes — and neither is a property of the model.

And harnesses inject their own hidden instructions. Every third-party writing app has a system prompt you never see, shaping tone before you type a single word. That is not sinister; it is how the product works. But it means the voice you get is partly theirs.

Same harness, different model

Swap the brain and keep everything else, and you still get a different book.

Models differ on things no harness can fix. Their default register — cadence, how densely they reach for metaphor, how dialogue sits on the page. How tightly they hold your rules across four thousand words, versus drifting back to their own habits by the third scene. Where they start forgetting what happened in chapter three. And what they will refuse, which is not a minor footnote if you write heat, violence, or genuinely dark material. For a lot of romance authors that single factor decides everything.

Price differs by an order of magnitude too — and that loops right back to the other dial, because a cheaper model buys you more passes. A modest model taking four careful runs at a scene very often beats a brilliant one taking a single swing.

The diagnostic

This is the practical payoff, and it is the single most useful thing in this post:

When the output is wrong, ask which dial is broken.

• Wrong facts. Contradicts chapter three. Ignored a rule you clearly established. Forgot a character’s sister exists. → That is almost always the harness. The model never saw the information. No amount of better prompting fixes a context problem.
• Right facts, but the voice is flat. Wrong register. Overwrought. Refuses a scene you need. → That is the model.

I have watched writers spend months rewriting prompts to fix a harness problem, and other writers tear down an entire working system over what was, in the end, a model problem. Ask which dial first. It will save you a season.

The five ways

I am deliberately not numbering these, because numbering implies a ladder and there is no ladder. Nobody graduates from one to the next. I still use the first one every week, and I built the fifth one.

A chat window

Claude Projects, ChatGPT Projects, Gemini Gems. The tab you already have open.

What it is genuinely good at: thinking. Not producing — thinking. It is still the best surface anyone has built for arguing with yourself about a story. Is this chapter opening on the wrong beat? Is this romance actually a friendship? Is this scene cosy or have I quietly written something bleak? Chat is superb at that, and nothing further down this page replaced it for me.

The other strengths are real and get dismissed far too easily. Setup is minutes, not months. You see every single token it produces, which matters more than people admit — voice drift cannot hide from you in a chat window the way it can hide inside an automated pipeline. Project knowledge genuinely works as a series bible for one book. Nothing breaks at midnight. And it runs on your phone, in a waiting room, on a plane.

What it costs you. Chat has no access to your files. It cannot open chapter fourteen and check it against your timeline, because it cannot open anything. Consistency across a novel is on you, by hand, forever.

The context window is a hard ceiling. An eighty-six-thousand-word manuscript does not fit alongside the bible and the style guide, no matter how good your prompt is. Past a certain length, drift stops being a prompting failure and becomes structural.

Nothing is repeatable. The prompt that worked brilliantly last Tuesday is gone, buried in a thread you will never find. You cannot run it forty times. You cannot hand it to anyone.

And the real cost, the one that actually caps your output, is the copy-paste tax. Every chapter out. Every note back in. Every time. That tax — not the writing — is what holds people at one book a year instead of three.

If your work never needs the machine to open a file you did not paste in, chat is not the beginner option. It is the correct option, and it is faster and cheaper than everything below it.

I mean that. If chat is doing the job, you are finished. Go and write.

A coding agent

Claude Code, Codex, and the rest of the terminal-based agents. This is where most of my production work happens, and it is the biggest single jump on this page — but not for the reason people assume.

What it is genuinely good at: doing the same complicated thing correctly, over and over, against files it opens itself.

Two things change here, and they are enormous.

The first is that the file system becomes the memory. The context problem does not get bigger — it dissolves. The agent does not need the whole book in its head. It opens chapter thirteen, chapter fourteen, the continuity ledger and the style guide, does the work, and closes them. There is no manuscript length at which this stops working. That is a genuinely different category of thing from a chat window, and it is why my folder structure — dull, rigid, identical across every book — is load-bearing infrastructure rather than tidiness.

The second is that a prompt becomes an asset. A workflow that worked once gets saved as a command. I can run it on any book, edit it when it is wrong, and hand it to a student. This, not speed, is the actual win. Speed is what you notice first. Repeatability is what changes your career.

And then there is the thing chat simply cannot do: run several passes at once. After a chapter is drafted, I can send a continuity checker, a timeline auditor, a drift referee and a dialogue pass at it simultaneously, each reporting separately. The clearest demonstration I have is a novel drafted at thirty-six chapters and about eighty-six thousand words, where every finished chapter rippled backwards to re-seed earlier setups so the payoffs landed as inevitable, and forwards to revise the plans of chapters not yet written. That shape of work is impossible in every other setup on this page.

What it costs you. The terminal-literacy tax is real, and I am not going to pretend otherwise. Most authors bounce off it in the first week. Anyone telling you it is easy is selling something. Budget weeks, not an afternoon.

The cost is metered rather than flat, which means it can stop you mid-book. Mine did, halfway through a two-series run, when I hit a monthly spend cap. A subscription does not do that to you.

Your workflows breed. I have dozens of saved commands now, duplicated across two different agents, and a decent fraction of them are stale. Governing the collection has become its own recurring chore.

The whole thing is also only as good as your own conventions. If your folders and your metadata drift, the machine drifts right along with them — confidently, at scale.

And there is no glanceability at all. A terminal cannot show you your publishing slate. That absence is precisely what pushes people into the last two ways.

But the honest cost is the one further down, in the section about bottlenecks, and it is not what I expected.

Somebody else’s app

NovelCrafter, Sudowrite, and the broader family of harnesses that let you bring your own key — LibreChat, Open WebUI, and the local-model tools people run against models on their own machines. I used Typing Mind for a good while, back before one interface for many models was standard.

What it is genuinely good at: handing you a finished interface for nothing.

Somebody already built the story codex, the chapter list, the model switcher, the prompt library. For most authors that is the entire value proposition, and it is a good one. A story codex with a proper interface is, functionally, the same thing as my structured notes folder — except I designed mine over months and you can have theirs this afternoon.

Bring-your-own-key is genuinely useful too. One interface, any brain, which makes it easy to hear the same scene in four different voices and pick. You inherit prompt craft from a community that has been tuning it for a year. And commitment is low: try it for a month, and if it is wrong you have lost a month, not a year of building.

The local-model route deserves its own mention, because it answers real problems rather than theoretical ones. Nothing leaves your machine. There is no per-word cost. And there is no content policy standing between you and the genre you actually write, which for a lot of authors is not a footnote — it is the deciding factor.

What it costs you. Their data model quietly becomes your process. You will find yourself writing the way the tool’s schema expects, because that is the path of least resistance. If your method does not fit their idea of what a story bible is, your method is the thing that gives way.

Your bible lives in their database. Leaving is a migration project, not a decision.

You are a tenant. Prices change, features get removed, and account-wide policies can break things you did not think were connected. I once disqualified an entire email platform because unsubscribing from one pen name would have unsubscribed that reader from all of them — the same class of risk, in a different room.

There is also an agentic ceiling. Nearly every author-facing tool is a one-shot generator: prompt in, prose out. No self-critique loop, no parallel checks, no rippling a revelation backwards through fourteen chapters.

And it cannot reach the rest of your business. It will not fix your metadata, rebuild your website, or reconcile your catalogue.

Renting is not the embarrassing option. Renting is what you do while you find out whether your process is stable enough to be worth building. Most processes are not, and finding that out cheaply is a win.

Typing Mind was not a bad product. I hit its ceiling. That is a different thing, and worth saying out loud.

An editor extension

This is the one almost nobody talks about, and I think it is the best value on the whole page.

An extension lives inside a code editor — VS Code, most commonly — and gives you panels, buttons, trees and forms on top of files that stay yours. Your manuscript is still plain text in your own folder. Nothing is held in anyone’s database. But you get an actual interface instead of a blinking cursor.

What it is genuinely good at: an interface without custody.

You also inherit an entire application for free — window management, a text editor, a file tree, settings, themes, an update mechanism. Building those yourself is roughly six months you get to skip. And it is shippable: package it up, hand it to a student, sell it. It is the cheapest way I know to turn a personal workflow into something another person can actually use.

It sits in the same window as a coding agent, too, so this is not a choice against the previous section. They compose.

What it costs you. VS Code is a programmer’s application, and asking a cosy-fantasy author to install it is a genuine cliff. No amount of theming fully hides what it is.

Packaging traps are brutal and invisible. I audited one of my own extension builds and found it shipped without its own content bundled — flawless on my machine, which already had the files, and useless to every single person who would have bought it. That entire class of bug is undetectable by the person who made it.

You are living inside somebody else’s API, and its lifecycle changes without consulting you. Interface real estate turns out to be politics: an early build of mine claimed eight sidebar icons, and the rule that replaced it was one extension, one icon. Restraint is a feature.

And there is no phone. No tablet. No away-from-the-desk.

Software you build yourself

I did this. I want to be extremely careful about how I recommend it.

What it is genuinely good at: fitting a business that nothing on the market models.

Nine fiction pen names. A book that exists simultaneously in five different systems that disagree with each other. Separate websites per pen name. There is no product that models that, and I do not think there ever will be, because there are not enough of us to build one for.

When it works, it is wonderful. Every capability becomes a button — which is the rule that separates a system you have from a system you actually use, because a capability that only runs from a command line does not really exist. It follows you off the desk: my own site, my own login, usable from a phone. Modules compound, so each new piece is cheaper than the last. And nobody can deprecate you.

What it costs you. You are now running a software company. Deploys, version numbers, authentication, scheduled jobs, documentation. That is a second job, and it competes directly with the writing — not theoretically, but for the same hours on the same Tuesday.

The maintenance tail never ends. Hosts change, tokens expire, things fall over on the morning you meant to draft.

Scope creep is the default failure, not an occasional one. I had twelve interface themes before the writing surface — the thing the entire system exists for — was finished. I am not proud of that, but it is the most useful thing I can tell you about this option.

You are also the only quality assurance there will ever be. No community finds your bugs. And sunk cost has gravity: walking away from something you built is far harder than cancelling a subscription.

Build your own only if two things are true: nothing on the market fits the shape of your business, and you enjoy building. If only the first is true, you will burn out. If only the second is true, be honest that it is a hobby — a very good one, but a hobby.

Seven questions instead of a recommendation

Here is what I would actually ask you, if you sat down across from me and asked which one to use. Each should take about five seconds, and together they point somewhere far more reliably than any feature comparison.

1. Does the machine need to open files you did not paste in? If no — stop at chat. Genuinely, stop there.
2. Will you do this same task more than about five times? If yes, you need a saved workflow: an agent, an extension, or at minimum a tool with a real prompt library.
3. Do you need several different checks run on one chapter at once? If yes, a coding agent. Nothing else does it.
4. Do you need to see your whole slate at a glance, or work away from your desk? If yes, you need an app — theirs first, and yours only if theirs cannot be made to fit.
5. Do you need to sell, teach, or hand this workflow to another person? If yes, an extension or your own software.
6. Does your genre get refused, or does your material need to stay on your own machine? If yes, a local model inside a third-party harness.
7. Is your bottleneck actually drafting at all? Be honest. This one matters most, and it leads directly into the last section.

The thing nobody warns you about

Every one of these setups moves your bottleneck. Not one of them removes it.

In a chat window, drafting is slow. So you go looking for something faster, and you find an agent.

With an agent, drafting is fast — gloriously, alarmingly fast. And now reading what it drafted is slow. That is the wall I hit, and I did not see it coming at all. I have around three million words of drafted manuscript sitting on my drives and a queue of finished books waiting on nothing but me to read them properly and decide. The machinery worked exactly as designed. It solved drafting so completely that drafting stopped being the problem, and the actual problem — reading, judging, finishing, shipping — had been standing quietly behind it the entire time.

So you build tools to organise the reading. And then deciding what to publish is slow. And no harness ever built has made that decision for anybody.

Find the step that is genuinely slow for you, and buy or build the smallest thing that fixes that one step. Then look again — because it will have moved.

That is the whole method. It is much less exciting than a tool recommendation, and it is worth considerably more.

You do not have to build what I built

I want to end here, because this is the part I care about most.

I have a large, strange, homemade system, and I like it. It is not a model for anyone else, and I would be doing you a disservice if I presented it as an aspiration. It exists because my business has an unusual shape and because I genuinely enjoy building things at eleven at night. Both of those are facts about me, not standards for you.

If you are writing beautiful books in a chat window, you are not behind. You are not doing it the amateur way, and you have not failed to graduate to something. You are using the setup that fits your work, which is the entire goal, and you got there without spending a season learning a terminal.

There is no right way to automate a novel. There is only the way that fits the book you are actually writing, the business you are actually running, and the amount of infrastructure you actually want to be responsible for on a Tuesday night.

Pick that one. Change it when it stops fitting. That is allowed.