I recently finished reading Stefan Zweig’s memoir, The World of Yesterday. It’s less a memoir than an elegy for an entire European culture, burned to the ground by two wars and fascism. He finished it in exile in Brazil, 1942, a long way from the Vienna he was mourning, one day before he and his wife took their own lives.

That’s a heavy place to find writing advice. A short, reflective passage on his process caught my attention regardless.

LinkedIn posts, blogs, code, PRs - mine included - are littered with AI-written text these days. Most of it is obvious: a sprinkle of em-dashes, sentences that don’t logic, something that just feels “off”. The worst is the three-beat rhythm that makes it read like a sales pitch.

Have you ever wondered why your cat always seems disgusted?

Here’s a clue — it’s not you.

It’s that abysmally grim cat food you feed it.

Zweig writes in long, winding sentences, with a dusting of introspection, detailed descriptions that form vivid pictures in your head, and personal takes that make you think. Fresh air compared to the factually dense history books I usually endure, and a level of engagement beyond anything LLM-generated that I’ve read or produced.

Good writing has two jobs that pull against each other: say it in as few words as possible, and keep the reader with you until the end. Brevity respects their time, but engagement spends it on literary devices: figures of speech, building tension, a little humour. The techniques that make writing interesting are the ones that make it longer.

LLMs are trained on everything: narratives, documentation, speeches, blogs, tweets and so on. No wonder most AI-generated writing gives my brain a power cut. It lacks a proper structure even though the substance is there, and fails to keep me reading until the end. And no, I’m not just allergic to em-dashes.

So how do we use LLMs to communicate in a way that strikes a balance between engaging enough to hook a reader and concise enough to respect their time?

Zweig’s writing holds part of the answer. The rest lies with our own voice.

The Zweigian Process

An LLM lays track one token at a time, with no way to double back, but did Zweig really write The World of Yesterday word-by-word in a single pass? I think not.

He puts it best in his own words:

I have hardly finished writing the first rough draft of a book before I begin on what to me is the real work, condensing my material and finding the right way to put it. I go on working tirelessly like this from draft to draft. I am constantly throwing ballast overboard, intensifying and clarifying a book’s inner architecture. Most writers cannot bring themselves to leave anything out, and having fallen rather in love with their subject hope to display a greater breadth and depth of knowledge than they really possess in every well-turned line, whereas my own ambition is always to know more than shows on the outside.

Later, at the proof stages, I then repeat this process of intensifying and then enhancing the dramatic effect once, twice, or three times. In the end I find myself enjoying a kind of hunt for another sentence, or just a word, which can be cut without affecting my precise meaning and at the same time might speed up the tempo. I really get my greatest satisfaction in my work from leaving things out. I remember that once, when I rose from my desk feeling pleased with what I had done, my wife said I seemed to be in a cheerful mood today. “Yes,” I replied proudly, “I’ve managed to cut a whole paragraph and make the action move faster.” So if my books are sometimes praised for sweeping readers along at a swift pace, it does not come from any natural heated or agitated approach to the work of writing, but is entirely the result of my system of always cutting unnecessarily slack passages–anything at all that, like radio interference, might distract the reader’s attention. If I have mastered any kind of art, it is the art of leaving things out. I do not mind throwing eight hundred of a thousand written pages into the waste-paper basket, leaving me with only two hundred to convey what I have sifted out as the essence of the work. So if anything at least partly accounts for the success of my books, it is my strict discipline in preferring to confine myself to short works of literate, concentrating on the heart of the matter.

Zweig is a master of refinement. The first pass is merely the start, with each draft expressing more meaning more concisely and drawing the reader further in. Your LLM’s single forward pass is a potato to Zweig’s triple-distilled vodka.

What if we apply this refinement process to an excerpt that I unashamedly ripped from someone’s LinkedIn post?

Everyone is debating whether AI will replace software engineers.

I think that’s yesterday’s argument.

The engineers who are at risk aren’t the ones using AI.

They’re the ones still treating it like a smarter autocomplete.

The biggest shift I’ve seen isn’t AI writing code. It’s AI becoming part of the engineering team.

It shows the classic AI rhythm: short punch after short punch. It’s concise, yes, but my brain disengages as soon as it hits whitespace with no real point made.

Compare to this refinement:

Everyone is debating whether AI will replace software engineers, but that’s yesterday’s argument. The real risk isn’t to the engineers using AI, it’s to the ones still treating it like a smarter autocomplete.

The biggest shift I’ve seen is AI becoming part of the engineering team, not just writing code.

In two refinement passes with Claude, it’s changed from cringe AI LinkedIn post that I won’t read, to a useful and digestible insight.

Two passes and a human paying enough attention to know when to stop is manageable for a single LinkedIn post, but I write far more than that: PR descriptions, commit messages, technical documentation, initiatives, this blog post, and so on. Scaling that is going to need some automation.

Zweig Skills

I’ve created two agent skills inspired by Zweig’s process, zweig-write and zweig-refine, that I’m now using daily to improve the writing coming out of Claude Code.

Get them in rornic/zweig on GitHub.

zweig-write tightens up the first draft. It skips throat-clearers, hedging, repeated points and more advanced punctuation (yes, I did just call semicolons advanced). Very simple, nothing new here.

zweig-refine is where the magic happens. It takes the first draft and runs multiple refinement passes in a loop. Not just a reasoning loop, but a real loop with real edit calls.

  1. Read the working file in full.
  2. Cut: make an Edit call for every sentence, bullet, or word that can be removed without losing precise meaning. Throw ballast overboard, favoring fewer, denser points over breadth, and cut self-descriptive or boilerplate lines.
  3. If step 2 made at least one edit and you’re under 4 passes total, go back to step 1 for a new pass on the updated file. Otherwise, stop.

Telling the agent to make tool calls like this forces refinement passes to happen for real, instead of being simulated through reasoning.

But there’s one more problem: the refinement agent starts with the context of the whole first draft and never discards it. So in its relentless drive to cut slack, it can easily make assumptions that a new reader will not follow.

To solve that, a fresh reader subagent is created once the refinement loop converges. This agent runs on a cheap model like Haiku and is only given the final draft and two questions:

  1. What’s confusing?
  2. What information does it need that’s not there?

If there are complaints, the refinement agent probably cut too much substance. A final edit is allowed to clarify the confusing points.

With that process, we go from a default Claude Sonnet 5 output like:

Observability is cool because it turns “why is this broken?” from a guessing game into a query — instead of adding print statements and redeploying, you ask your existing data and get an answer in seconds. It also rewards curiosity: because wide, high-cardinality events let you slice by any dimension, you often find bugs and perf wins you weren’t even looking for.

To this, from the same “Write two sentences explaining why observability is cool” prompt:

Observability is cool because it turns “something’s wrong” into “here’s the exact request, field, and millisecond it broke.” You stop guessing from dashboards and start asking the system arbitrary questions about its own behavior, closer to debugging with a search engine than a flashlight.

I don’t know about you, but my brain stopped to re-read the first one a few times. In the second, I followed it through to the end in one clean sweep.

Personal Voice

We now have an automated process for writing and refining text that reads well. The final polish is your own flavour.

That leaves two options:

  1. Write the damn thing yourself, then use zweig-refine to clean it up. Slower, but more personal, and how this post was written.
  2. Create your own skill, distilling your personal voice into rules AI can follow. Faster, but it’ll never truly be “you”, though it layers well on top of other writing skills.

I took a stab at option two, creating a personal-voice skill. I went back and forth with Claude, feeding it the human-written posts on rornic.dev and getting it to analyse what makes my writing distinct: the structures and devices that make it sound like me instead of some generic textbook. Once it had that analysis, I had it write the rules straight into a skill file, encapsulating the important bits so it could follow them itself.

In technical writing, I lead with problems, follow with insights, then provide solutions, always stating limitations to avoid overselling. I reach for hard numbers like “5x better” instead of hand-wavy qualifiers like “much better”.

Dry, self-deprecating humour injects some life when used sparingly, even if it’s only me who finds it funny. I write informally, mostly in first and second person, with contractions like “haven’t” and “I’d”. The pace varies between longer sentences and short beats, but never big blocks of text.

I lean on analogies to explain complex topics before the technical detail arrives, without ever deciding to. What is tracing? explains tracing like it’s a restaurant. It’s strange how something so unconscious mirrors exactly how I learn, by mapping new concepts onto something I already understand.

Now let’s see all the skills working together, starting with a short prompt: “Write me a 1-2 sentences about an interesting topic.”

The mantis shrimp sees with 12 to 16 types of photoreceptors, compared to our 3, yet in tests it distinguishes colors worse than we do. Its eye doesn’t sort wavelengths by comparison like ours; it seems to read color almost like a barcode scanner, sacrificing subtlety for speed.

This was just zweig-write doing its thing. It’s a cool fact, readable too, but textbook style. A little boring. So let’s apply my personal-voice skill:

Mantis shrimp eyes pack 12 to 16 types of photoreceptors, against our measly 3. You’d think that means they see colour in some psychedelic superhuman way. They don’t. In tests they’re actually worse than us at telling similar shades apart.

Turns out their eyes don’t compare wavelengths at all, which is how ours pull off the trick. Instead each receptor just checks “is my colour here, yes or no” and fires off the answer straight to the brain, no comparison needed. It’s less a full-colour camera and more a barcode scanner: fast, cheap, and not remotely interested in subtlety.

personal-voice expanded the barcode scanner analogy for clarity, restructured into shorter paragraphs, and added panache with “some psychedelic superhuman way”.

And to finish it off, let’s zweig-refine it:

Mantis shrimp eyes pack 12 to 16 types of photoreceptors, against our measly 3. You’d think that means they see colour in some psychedelic superhuman way. They don’t. In tests they’re worse than us at telling similar shades apart.

Ours work by comparing signals across receptor types against each other, and that comparison is what lets us pick out fine gradations between shades. Their receptors don’t talk to each other like that. Each one just checks “is my colour here, yes or no” and fires the answer straight to the brain, so they can tell categories of colour apart but not shades within a category. It’s less a full-colour camera and more a barcode scanner, fast, cheap, and not remotely interested in subtlety.

zweig-refine tightened it up, cutting “which is how ours pull off the trick”. The fresh reader subagent noticed we never explained why mantis shrimp are worse than us at telling shades apart, so added a bridging sentence to link it up.

The writing works, but I’ll wait for a mantis shrimp expert to tell me if it’s correct.

That’s my process.

It results in writing that’s easy and quick to read, yet still has a bit of life in it. There are alternatives, like caveman if want good simple speak with few token, or humanizer if you just want to make writing that sounds more natural.

After over 5000 years of writing by hand, we’re entering a world where humans no longer have the patience to communicate using their own voice. The question on my mind is whether that even matters, whether writing itself becomes obsolete like so many technologies before it. Regardless, for now I’ll do what I can to maintain and improve the quality of my own writing.