Co-Writing a Novel With an Agent: Style Engineering

LLM-generated text has some well-documented tics you’ve probably noticed. You might just understand them subconsciously, although nowadays there are memes that call them out. By default, the prose is passable, if not inspiring. It’s also weirdly uniform, and it has habits.

This is the third post in a series about co-writing a “meganovel” (targeting 1,000,000 words or more) with an AI agent. The first covers the context management infrastructure. The second covers the collaboration model and planning process. This one is about the output itself: what’s wrong with the robot’s prose defaults, and the system I’ve built to fight them.

The Tics#

Some of these you’ll recognize immediately.

“Not” constructions. The model loves defining things by what they aren’t. “Not anger, exactly, but something quieter.” “Not a request.” “Not quite a smile.” One or two of these in a piece is fine. The model will do twenty per thousand words if you let it. The effect is a kind of permanent hedging where nothing is ever stated directly.

Em-dashes. The model’s favorite punctuation mark. It uses em-dashes the way a nervous speaker uses “um”: as a pause, a pivot, a parenthetical, an interruption, a dramatic beat. I’ve seen drafts hit 20+ em-dashes per thousand words. At that density, the rhythm flattens. Everything has the same breathless, interrupted cadence. Nothing lands because everything is landing.

Staccato dramatic paragraphs. The model treats white space as emphasis. A character does something important and it gets its own paragraph. Then the reaction. Then the consequence. The page reads like a screenplay:

The room went still.

He stopped mid-sentence.

For a long moment, no one moved.

This is three sentences that should be one paragraph. Sentence rhythm should carry the drama, not line breaks.

These are universal. Anyone generating extended text with an LLM has seen them. I have a revision pipeline that catches all three mechanically, and I’ll get to how below. But they’re surface-level problems. The deeper issues are domain-specific.

The Anti-Patterns That Matter for Fiction#

When you’re generating sustained narrative prose, the model has failure modes that go beyond formatting tics. These are tendencies baked into its training that actively undermine literary fiction.

Therapy-speak. The most persistent one. Left to its nature, the robot has characters talk like therapists. “You don’t have to hide anymore.” “I’ve got you.” “You’re safe.” Characters cleanly diagnose their own emotions, articulate relationship dynamics with clinical precision, resolve conflict through verbal breakthrough. Real people don’t talk this way. Interesting characters certainly do not.

The narrator as therapist. Related but distinct. The narrator closes the interpretive gap, explaining what a scene means so the reader doesn’t have to do any work. “He’d never considered the guilt they might carry, the weight of watching someone you love suffer and not knowing how to help.” The reader’s inference has been replaced. The unresolved meanings of fiction get very much resolved and trumpeted. There’s nothing left to feel or think about, because the narrator already did it for you.

Abstract interiority. When the model writes a character’s inner experience, it defaults to summary. “He remembered so many memories and felt overwhelmed.” Memory can be grounded in concrete sensory detail: a specific room, a specific smell, a physical gesture that triggers the recollection. The model names emotions. Good fiction creates them through accumulated physical evidence.

Scene-coda overreach. Drafts consistently run two or three paragraphs past their natural ending. The scene has resolved, characters are at rest, and then the robot adds paragraphs explaining what the scene meant, what the character learned, what this implies for the future. And so on. And so on. The reader already knows. The robot doesn’t trust them, or just doesn’t want to stop.

Hedging. “Seemed.” “Felt like.” “As if.” “Almost.” The model cushions strangeness instead of stating it as fact, which is not great for genre fiction. Hedging kills the voice. “The kiss was cold” lands harder than “The kiss seemed cold to him.”

Why a Style Guide Doesn’t Fix This#

My first instinct was to write a better style guide. I spent days on it. The robot was enthusiastic about helping me improve the style guide. We iterated on it together. It got longer, more detailed, more precise. The prose didn’t get better.

This was the most frustrating phase of the project, because the solution seemed obvious (write better rules) and I kept refining the obvious solution and it kept not working. The robot would read the style guide, agree with every point, and then generate therapy-speak in the next scene.

The problem is a technical limitation around LLM generation: positive and negative constraints can’t be enforced simultaneously with equal effectiveness. During generation, the model responds well to constructive instructions. “Use this vocabulary.” “Structure paragraphs this way.” “This character speaks in short sentences.” It can hold these patterns while producing text. But “don’t use hedging language” and “don’t write therapy-speak” are harder to enforce mid-generation, because the model has to both produce text and monitor itself for forbidden patterns at the same time. It’s like asking someone to tell a story while also making sure they never say the word “the.” The answer was to stop trying to do everything at once.

The Pipeline#

I built a four-prompt pipeline that separates constraints by when they can be effectively enforced. The robot loads this pipeline as a skill before every writing session.

Prompts 1 and 2 are about building and generating. The model gets constructive constraints: use this vocabulary, follow this rhythm, these are the character’s speech patterns. Prompt 3 checks specific vocabulary against character reference material. Prompt 4 is where all the negative constraints live: strip the therapy-speak, merge the staccato paragraphs, cut the hedging, kill the coda.

The separation is the insight. Generate with positive constraints. Revise with negative constraints. No prose reaches me without passing through revision. I tried enforcing everything at once for weeks before I figured this out, and the difference was immediate.

The Constitution and Registers#

As the project grew, a single set of style rules wasn’t enough. Some rules needed to be universal: bodies grounded in character-specific physical detail, no interpretive explanations from the narrator, no therapy-speak in dialogue, the impossible stated as fact and never hedged, interiority grounded in concrete sensory detail. These had to hold regardless of anything else. I separated them into what I call the Constitution: 17 invariant principles that apply to every writing session. The Constitution is loaded before any generation. It’s the floor, the non-negotiable contract.

Beyond the constitution, I wanted to play around with style. Any robot-generated single style starts to get boring once you get to 500,000 words. I wanted to play around to keep it interesting. I wanted to take a break from my punchy, heavily-Nordic-influenced style and spend chapters doing something very different. The robot and I went through style analysis and generation exercises, thinking about different approaches, and developed what I call registers: pluggable style configurations that define how a specific section of the novel should sound. Each register is self-contained. It defines:

• Generation rules. How to write: POV mode, sentence structure, dialogue conventions, pacing targets.
• Revision rules. What to check: register-specific anti-patterns, rhythm targets, density thresholds.
• A changelog. Patterns learned from my hand-edits, with confidence levels. (More on this below.)
• Exemplars. Curated prose passages that embody the register’s voice. (More on this below too.)

One register might use em-dash dialogue (no quotation marks, which is how some literary fiction handles dialogue). Another uses standard quotation marks with sparse, weighted exchanges. One targets dense naturalistic conversation. Another targets long tracking sentences that follow sensation through subordinate clauses in real time. They’re completely different prose textures, but they all obey the same 17 constitutional principles.

The engineering parallel: each register composes the Constitution’s invariant rules with its own constraints. The constitutional rules run first; the register’s rules layer on top. You can swap registers without losing the shared foundation.

How the System Learns#

Post-pipeline, the robot and I have a collaborative revision process. The robot generates a draft. I edit it by hand: cutting a phrase, tightening a transition, replacing a word choice. These edits contain information. If I consistently cut lines where the robot has inserted fake histories into the narrative, that’s a pattern. If the robot keeps going guardrail-to-guardrail with a character’s voice instead of modulating, that’s a pattern. If I tell the robot to remove the “Not a-” structure that it maintained, even though it insists that this one is really cool and dramatically necessary (it does this), that’s a pattern.

I built a process I call the cybernetic loop that extracts these patterns automatically. After I edit a draft, the robot diffs my changes against its original output, groups similar edits, identifies recurring patterns, and records them in the active register’s changelog. Each pattern gets tagged with frequency, context (does this happen mostly in dialogue? in action scenes? everywhere?), and a confidence level: LOW, MEDIUM, HIGH, or CRITICAL.

The confidence levels matter because they determine what happens next. A LOW-confidence pattern is a note. A HIGH-confidence pattern gets applied automatically during future revision passes. A CRITICAL pattern, one I correct 100% of the time it appears, gets proposed for promotion from the changelog into the register’s permanent revision rules. Once promoted, it’s a standing rule that applies to every future draft in that register.

The loop closes: my hand-edits today become revision rules tomorrow become absorbed generation patterns over time. The robot’s first drafts have gotten measurably better over the course of the project, and the revision pass catches fewer violations because the generation pass has internalized the patterns.

Exemplars#

Rules tell the robot what to avoid, but they don’t help it know what to produce. So each register maintains a curated library of prose passages drawn from the project’s own output: scenes that worked, paragraphs that captured the register’s voice, moments where the prose did something I wanted to keep. These are the exemplars.

An MCP tool (get_exemplars) serves these during generation. It takes the scene plan’s content, runs semantic similarity against the exemplar library, and returns the passages that are most relevant to what the robot is about to write. The robot reads them before generating. It’s style anchoring through retrieval: the project’s own best output, indexed and served back at generation time.

The exemplar library also includes “drift” exemplars: passages that show what the register should avoid. Positive and negative reference points, matched by semantic similarity to the current scene. The robot sees both “this is what good looks like” and “this is what drift looks like” before it writes.

I built this because I noticed that rules alone produce compliance without character. The robot would follow every rule and still produce prose that felt generic. It also wants to fulfill corrections by just deleting, butchering paragraphs instead of revising. Exemplars give it a target to aim at, not just a list of things to avoid. This is new, but I’m hoping the combination of rules and exemplars is more effective.

Verification as Testing#

The last piece of the pipeline is mechanical verification. I’ve encoded the project’s known anti-patterns as testable patterns: regular expressions and grep commands that scan revised prose for specific violations. Many to most of the anti-patterns we’ve talked about - therapy-speak phrases, hedging language, scaffolding terms that leaked into prose, euphemisms, overused psychology words, “Not a question” narrator glosses, timeline errors - are filterable by string literals.

The robot runs these checks as the final step of revision and reports results in a table: pattern name, count, line numbers, and whether the violation should be fixed automatically or flagged for my review. Obvious mechanical violations get fixed on the spot. Context-dependent ones come to me.

These can also be run as a sweep over the whole corpus. It’s not red-green testing for prose: fiction isn’t reducible to regex, and I don’t set targets for the robot as a threshold of “good chapter.” It’s maybe more like a code coverage report: an automated check that provides a general indicator of health. The system assigns scores, and a “clean” chapter’s going to score higher than weaker chapters in terms of accumulated failure modes. Similar principle to CI for code as a complement to code review: automate the checks you know about, and devote your human attention to higher-order concerns.

The Hard Problem Keeps Moving#

The pipeline separates concerns: be creative during planning and generation, be mechanical during revision. But calibrating the boundary between those two modes is the ongoing work.

Too much constraint produces prose that is consistent and dead. Technically correct, emotionally flat. The robot follows every rule and the output reads like it was assembled from approved components. Too little constraint and it drifts back to therapy-speak and staccato paragraphs within a session. The interesting problem is the space between: enough structure for consistency, enough freedom for surprise.

The planning prompt tells the robot to be bold. The revision pipeline tells it to be precise. The register system lets me tune the knobs per section. The exemplars anchor what “good” sounds like. The cybernetic loop ensures the system keeps learning from my corrections. And I’m still experimenting with factors outside the prompt layer entirely: model temperature, context window allocation, how much exemplar material is sufficient to generalize from.

The hard problem keeps shifting. First it was memory. Then retrieval. Then style. Now it’s taste: understanding when the robot does something genuinely interesting, and figuring out how to create conditions where it happens more often. The technical infrastructure enables each phase, but the frontier keeps moving toward increasingly human concerns. The interesting work is always at the boundary of what the robot isn’t doing yet and understanding those boundaries as engineering problems that can be solved.

This series was written using the process it describes. I planned the structure with Claude Code in an interview-style session, provided editorial direction and personal detail, and edited each draft. The agent drafted from the shared plan and incorporated my feedback across revision passes.